An old blog entry I forgot to import from my blog at Wordpress...


Here are the first lines of a malware I was looking at some days ago (MD5: DA4B7EF93C588AD799F1A1C5AFB6CFAD). The malware is packed, I think with an home made packer; 40107C is the entry point, the first line of the loader’s code. The code is filled with useless instructions, nothing hard but if you want to study the entire loader you have to pay attention on every single lines of code. This time I’m not interested in the loader itself, but I’ll focus my attention on a strange behaviour, something I have never noticed before. The malware crashes at 4010AC on XP sp3 machine but it works fine on XP with service pack 1 or 2.

The comments are taken from a XP sp1 debugging session. At the end of the snippet eax points to ExitThread’s parameter, the one inside BaseProcessStart. There’s nothing interesting in these few lines of code, but it’s always better to open your eyes when there are hardcoded values around. I’m referring to value 0×12FF00 (hardcoded is not totally right but the sense is the same). It’s not obvious but this piece of code could not work on every single machine. Seems like the author was sure about the initial stack address value. I don’t know when the malware was written, but this piece of code crashes on XP machine with Service Pack 3. Maybe the malware was written before the final release of the latest service pack, I dont know. Here is the same code tested on a machine running XP sp3 :

The initial stack address is not the same, this time it’s 0×13FFC4. The malware was expecting to see 0×12FFC4, but the value it was looking for is stored inside 0×13FFC4 address.

Who decide which kind of value should be assigned to esp? 12FFC4 or 13FFC4?
My investigation started from kernel32.CreateProcessInternalW function. All the code refers to a XP sp3 machine, but sp1 code is almost equal.

This is where the new process’s context will be initialized. This is only an initialization, you won’t see the final values (values at EP of the new process) of each register, but it’s enough to understand why the esp values are not equal.
There are two functions in the snippet above, BaseCreateStack is used to create a stack for the process to run. BaseInitializeContext, as suggested by the name, initializes the context structure using some values obtained by the previous function. Let’s start with the first one: BaseCreateStack.
Firstly, it checks two values: MaximumStackSize and StackSize. Both of them are loaded from the process to run using NtQuerySection. Among all the information of a PE header there are two fields named SizeOfStackReserve and SizeOfStackCommit that are taken and saved by the system as MaximumStackSize and StackSize. Msdn has a description of the fields:
SizeOfStackReserve: the number of bytes to reserve for the stack. Only the memory specified by the SizeOfStackCommit member is committed at load time; the rest is made available one page at a time until this reserve size is reached.
SizeOfStackCommit: the number of bytes to commit for the stack.
Ok, now the system is going to check if they are valid or not:

If MaximumStackSize has a not zero value the flow goes on otherwise it’s necessary to set a value to this variable. Which is this value? It’s the one taken from the process’s PE header pointed by PEB->ImageBaseAddress.
Ok, now it’s time for a check over the other variable; the check is pretty similar to the previous one:

If StackSize is zero the content of the variable is filled with the value taken some lines above at 7C8102EE: SizeOfStackCommit. It’s almost the same check I described for MaximumStackSize.
If the values are not zero, the system checks them again, just to be sure they are valid:

StackSize must be minor than MaximumStackSize, if it doesn’t happen the system raise up MaximumStackSize. Now that the initial check is complete the function proceeds working on some alignment stuff, not so interesting per se. I can pass over this part reaching an interesting snippet:

The system reserves the right address space for the stack. It reserves MaximumStackSize bytes starting from an address chosen by the system; the address is the first available address inside the virtual space. The chosen address is stored inside BaseAddress and it’s used to update the content of InitialTeb->StackAllocationBase field:


The stack is created, there are 3 fields to set and for now the system updates the bottom of the stack only.

InitialTeb->StackBase = BaseAddress + MaximumStackSize
The system sets up the stack area by giving the upper and lower bound. The initial stack value is StackBase and it will decrease everytime a push/call/.. occours.
The procedure goes on committing the initial area of the stack, and after that BaseInitializeContext fixes the righ values for the registers (including esp). No need to continue stepping the code, I have a lot information now, and I might come to a conclusion.

PE fields:
SizeOfStackReserve: 0×100000
SizeOfStackCommit: 0×1000

Under XP sp3:
AllocateStackBase = 0×40000
MaximumStackSize = 0×100000
StackBase = 0×140000

Under XP sp1/sp2:
AllocateStackBase = 0×30000
MaximumStackSize = 0×100000
StackBase = 0×130000

It’s impossible for sp_1/2 to have an esp value like 0×13FFC4 because the upper bound (StackBase) is 0×130000. StackBase was obtained by the operation “AllocateStackBase + MaximumStackSize” (AllocateStackBase is the same as BaseAddress value). MaximumStackSize was taken from the malware’s header, and AllocateStackBase was initialized from NtAllocateVirtualMemory call.
Seems like the solution to the puzzle comes from NtAllocateVirtualMemory. The function is called using zero as BaseAddress parameter; as I said before it means that the system decides to assign the first free virtual location which is obviously 0×40000 under sp_3 and 0×30000 under sp_1/2. From my sp_3 machine, trying to browse the memory I noticed a 0×1000 bytes allocated starting from 0×3000, there’s no trace about this memory area in old XP service packs… What did they change in XP sp3? Well, I’m ready for a vacation in Holland for now. I’ll try to reply when I’ll be back in two weeks. If the answer is obvious and/or you know why… feel free to comment your idea

Is it possible to solve the problem?
Well, it’s insane to fix a malware just to be sure to run it under an XP sp3 machine. Anyway it’s not hard to make it runnable, you can simply change SizeOfStackReserve and/or SizeOfStackCommit directly from the PE header. I tried changing SizeOfStackReserve from 0×100000 to 0xF0000 and I got a runnable file. I don’t know how safe is to change such parameters…
All the tests were done on my personal machines, I would like to know if your sp3 machine (or any other OS) has the same initial stack value.

Hey ZaiRoN,

Interesting research as usual. I was rereading this and realized I had just seen something very similar, code relying on the initial stack pointer (or at least the contents of) to operate.

In fact, it was in the "lil malware unpacking contest" malware that evaluator had posted

http://www.woodmann.com/forum/showthread.php?t=12201

I mentioned in that thread that it was necessary for the PE to have been loaded through the normal kernel32!BaseProcessStart execution path (as opposed to a custom loader), because the correct stack return value was required in the code.


Here is the final step of PE loading in kernel32!BaseProcessStart. When the Entry Point of the PE is called by
7C816D4C call dword ptr [ebp+8]
the initial stack pointer will be 12FFC4 (for XPsp2), which is as Zairon noted here. The contents of that stack pointer will be the return address 7C816D4F.

Take note of the 3 nops (90h), they will come into play later. In a very convoluted way, the malware checks if one of these nops is found through the stack pointer.




Taking a look at the malware code




Checking the Call ECX, at the end of it all we simply have that return value to BaseProcessStart placed into EBP.




Continuing with the original code after returning from the Call ECX, everything is pretty much useless obfuscated code until we start manipulating ESI at 004011A8.

EBP at this point is the return address in BaseProcessStart
:7C816D4F push eax




So basically, all this code just checks if a NOP is found at the 4th instruction after the stack return address, if not it exits (actually crashes with an invalid Exit Code). Perhaps it is a check for a loader, or possibly an OS version check, since it will seemingly fail on XPsp3 (because it uses a hardcoded 120004h) for the same reasons as described by Zairon.

Kayaker