A forum for reverse engineering, OS internals and malware analysis 

Discussion on reverse-engineering and debugging.
 #13909  by R136a1
 Mon Jun 11, 2012 8:45 pm
Currently I reverse a malware which makes use of a stack value.
It takes this stack values (pointer) and compares the bytes to the "MZ" signature (MZ header). If successful it continues to check if it is a PE file (PE header).

The value of this stack address is the second after break on the Entrypoint. Note: The value of the address is the same for all executables on the running OS (OK we have ASLR on Windows 7), but I want to say that the malware is just as any other executable regarding this value.

I have checked this stack values (pointer) on Windows XP (SP3), Windows 7 (32-Bit) and Windows 7 (64-Bit), the results are as follows:

Windows XP (SP3)
The value of the second stack address points into ntdll.dll. Small note: What is this? Why does it points to this address?
Stack:
Image
CPU:
Image

Windows 7 (32/64-Bit)
The value of the second stack address points to the Process Environment Block (PEB).
Stack:
Image
Memory:
Image

Now my question: Does somebody know a configuration where this stack value points into a PE file (header), maybe on another OS (Windows 2000/Vista/...)?
 #13940  by everdox
 Wed Jun 13, 2012 4:08 am
hi,

a pointer to the peb has been pushed from RtlUserThreadStart to the PE entry since xp, and that is the same all the way through windows 7 and 8.

there are 2 ways however that it could be changed:

1. if this malware you are describing has a dll image with it, which would need to be defined in the IAT, then this means it's entry point is called prior to LdrpInitializeProcess returning, and the 3rd argument gived to dllmain (lpreserved) on msdn is actually a context structure in which EAX (the RtlUserThreadStart argument) points to the peb. So it can be changed there.

2. the same method as 1, except using a tlscallback. so no dll image would be needed.
 #13951  by R136a1
 Wed Jun 13, 2012 4:41 pm
Thanks for your information.

The malware sample neither has a custom DLL image with it nor a TLS Callback function. But I think you are right with your first assumption, since later it uses data of the DLLs resource section. It has to be a version of the malware where this "feature" was disabled.