as a reverser, working for a security company ("http://www.endeavorsecurity.com"), I used to analyze a lot of shell-codes every days. most of them were caught by AMP ("https://www.endeavorsecurity.com/AMP-1.0-SNAPSHOT/") and stored in .pcap format with packet header(s) and other stuff like this that has nothing to do with actual machine code. a typical shell-code looks like this:

http://nezumi-lab.org/gif/shell_demo_01.giftypical shell-code


where is our Entry Point? how to find it fast? a common approach - just to start disassemble the code from different locations until we get the most sentence listing, but sometimes shell-code starts from an encrypted block followed by the decryptor and we just waste our time.

by accident I came upon the better way. just look for “EBh” (jmp short) opcode. it works well in most cases, brining us very close to real entry point. maybe you will get a few false positives, but not more.

it works coz almost every shell-code has “jmp short” command near to the entry point, so looking for EBh opcode is a good approach to find the entry point very fast! don’t ask me, “why EBh, man? why EBh works better than anyone elese?!” I don’t know. I just know this works. theoretically, CALL and LOOP should work as well, but… they don’t. EBh works much better helping me to reverse shell-code faster :-) it takes about 3 seconds to find Entry Point with HIEW in average.

in our case, EBh has been found at 544h offset. of course, this is _not_ the read entry point, but something very close to it. EBX is not used (it’s reinitialized by following commands), so just skip 53Ch line. two second lines opens stack frame to allocate some memory for local variables, thus 53Dh _probably_ is the real entry point. “probably” coz we can’t be sure until analyze the rest of shell-code, but in this case our suggestion is absolute correct and finding the entry point took just a second.

http://nezumi-lab.org/gif/shell_demo_2.gifEntry Point has been found




http://nezumi-lab.org/blog/?p=83