When I tried to disassemble it, the header segment was shown as code:
HEADER:00400000 4D dec ebp HEADER:00400001 5A pop edx HEADER:00400002 90 nop HEADER:00400003 EB 01 jmp short loc_400006
Let's review what we know about the PE-Header:
A PE-Header begins with a struct IMAGE_DOS_HEADER with the following fields:
e_magic (5A4Dh) e_cblp e_cp e_crlc e_cparhdr e_minalloc e_maxalloc e_ss e_sp e_csum e_ip e_cs e_lfarlc e_ovno e_res e_oemid e_oeminfo e_res2 e_lfanew
The e_lfnanew fields tells us the offset of the PE-Signature (0x00004550), after this comes the structure IMAGE_FILE_HEADER, and then the structure IMAGE_OPTIONAL_HEADER.
IMAGE_OPTIONAL_HEADER begins the following fields:
Magic MajorLinkerVersion MinorLinkerVersion SizeOfCode SizeOfInitializedData SizeOfUninitializedData AddressOfEntryPoint
The AddressOfEntryPoint tells us the offset of the binary entry point.
With this in mind I followed the usual procedure of defining the structures of a PE Header, however, when defining the DOS_IMAGE_HEADER this was the result:
HEADER:00400000 __ImageBase dw 5A4Dh ; e_magic HEADER:00400000 dw 0EB90h ; e_cblp HEADER:00400000 dw 1 ; e_cp HEADER:00400000 dw 0E952h ; e_crlc HEADER:00400000 dw 189h ; e_cparhdr HEADER:00400000 dw 0 ; e_minalloc HEADER:00400000 dw 4550h ; e_maxalloc HEADER:00400000 dw 0 ; e_ss HEADER:00400000 dw 14Ch ; e_sp HEADER:00400000 dw 2 ; e_csum HEADER:00400000 dw 0 ; e_ip HEADER:00400000 dw 0 ; e_cs HEADER:00400000 dw 0 ; e_lfarlc HEADER:00400000 dw 0 ; e_ovno HEADER:00400000 dw 2 dup(0), 0E0h, 30Fh ; e_res HEADER:00400000 dw 10Bh ; e_oemid HEADER:00400000 dw 0 ; e_oeminfo HEADER:00400000 dw 0Ah dup(0) ; e_res2 HEADER:00400000 dd 0Ch ; e_lfanew HEADER:00400040 db 0
As you can see the signature would be the value of e_maxalloc, and the offset e_lfanew points us to the contents of the IMAGE_DOS_HEADER (0x400000C), which means that the IMAGE_DOS_HEADER would be overlaping the IMAGE_FILE_HEADER structure.
Since I wasn't very sure of what was happening here, ran the bot through PEiD, and it showed the bot as being packed with "SimplePack 1.11 Method 2 -> bagie[TMX]", so I decided to find an unpackme packed with this method and found one that had been packed with SimplePack 1.2, even though it was not the same version, it should give me some idea of what was going on here.
Let's have a look at this unpackme then.
My guess was that the header had been changed by the packer, and that even if the structures had been messed with, if I followed the offsets blindy, I should be able to reach the original entry point of the program.
So, if I started at the PE-Signature address, and added 0x4 + 0x14 + 0x10 that should be the offset of the original entry point, which in this case was 0.
HEADER:00400000 4D dec ebp HEADER:00400001 5A pop edx HEADER:00400002 90 nop HEADER:00400003 EB 01 jmp short loc_400006
If we set a breakpoint at 0x00400000 the debugger will fail to start the program (my guess is that the opcode will be changed to 0xCC - from what I've read about debuggers here - and the "magic" field of the structure will be changed, and the binary won't be loaded), but we can set a breakpoint at the jump instruction, and the debugger stops there.
This is what I've found thus far. I will continue to reverse the unpackme until I am less clueless about what is going on with this packer and then I will proceed with bot1.exe analysis.
-
the info I gathered about the PE Header came from LUEVELSMEYER's tutorial on PE I heard about here http://win32assembly.online.fr/pe-tut1.html
-
No comments:
Post a Comment