More than one year ago I started a project with Kayaker, we decided to write a tool able to show hidden callbacks. If I remember correctly the idea was born while we were putting our hands on a rootkit. In the same days I bet there were many reversers around thinking the same thing because the same tool was developed by others. As you can imagine our tool never see the light, but not because there are similar tools available online; mostly because we are two old lazy reversers!

I bet you are thinking: why the hell are you writing this stupid intro? Well, the tools I mentioned before were bugged and some months ago I discovered the same thing, they are still bugged (I don’t know if they have solved their problems right now…). Strange that no one else noticed it yet.
Anyway, we won’t complete the tool, but with this blog post I would like to tell you some notes about our investigations. At the beginning I wanted to write a detailed and complete article about the subject, but I don’t know when I’ll be able to end this project so I decided to spread out some of my notes.

It’s a sort of two minds work so credit goes to Kayaker too!

The idea is to try to retrieve hidden callbacks that has been installed via CmRegisterCallback, PsSetCreateProcessNotifyRoutine, PsSetCreateThreadNotifyRoutine and PsSetLoadImageNotifyRoutine. After that it would be good to deregister one or more of them.



Where to start?
First of all you have to understand what’s behind functions like CmRegisterCallback, and others. Then, you’ll have something to work on. I’ll start with CmRegisterCallback (from XP SP2), the function is used to register a RegistryCallback routine, and I think the XP version is the most simple one to fully undestand the principles behind the function. There are some differencies between XP and 7 versions, but I think you’ll be able to fully understand 7 structure too! Here is the disassembled function (without useless parts of course):

487E6B  push   'bcMC'                          ; Pool Tag: "CMcb"
487E70  xor    ebx, ebx
487E72  push   38h                             ; NumberOfBytes: 0x38
487E74  inc    ebx
487E75  push   ebx                             ; PoolType: PAGEDPOOL
487E76  call   ExAllocatePoolWithTag           ; ExAllocatePoolWithTag(x,x,x): allocates pool memory
487E7B  mov    esi, eax                        ; eax is the pointer to the allocated pool memory, PCM_CALLBACK_CONTEXT_BLOCK
487E7D  xor    edi, edi
487E7F  cmp    esi, edi                        ; Is PCM_CALLBACK_CONTEXT_BLOCK a NULL pointer?
487E81  jz     cmRegisterCallback_fails        ; yes: function fails...
487E87  push   esi
487E88  push   [ebp+Function]                  ; PEX_CALLBACK_FUNCTION, pointer to callback function
487E8B  call   _ExAllocateCallBack             ; allocates and fill EX_CALLBACK_ROUTINE_BLOCK structure (more on this later...)
487E90  cmp    eax, edi                        ; ExAllocateCallback success or not?
487E92  mov    [ebp+PEX_CALLBACK_ROUTINE_BLOCK], eax ; store the pointer to the allocated pool memory
487E95  jnz    short _ExAllocateCallBack_success
   ...                                         ; fill CM_CALLBACK_CONTEXT_BLOCK fields
487EDC  mov    ebx, offset CmpCallBackVector
487EE1  mov    [ebp+i], edi                    ; i = 0
487EE4 try_next_slot:
487EE4  push   edi                             ; OldBlock: NULL
487EE5  push   [ebp+PEX_CALLBACK_ROUTINE_BLOCK] ; NewBlock with information to add
487EE8  push   ebx                             ; CmpCallbackVector[i]
487EE9  call   _ExCompareExchangeCallBack   ; try to *insert* the new callback inside CmpCallBack vector
487EEE  test   al, al                       ;check the result...
487EF0  jnz    short free_slot_has_been_found    ; jump if the vector has an empty space for the new entry
487EF2  add    [ebp+i], 4                      ; i++, increase the counter
487EF6  add    ebx, 4                          ; shift to the next item of the vector to check
487EF9  cmp    [ebp+i], 190h                   ; is the end of the vector?
487F00  jb     short try_next_slot             ; no: try another one. yes: no free slot!
   ...
487F11 cmRegisterCallback_fails:
487F11  mov    eax, STATUS_INSUFFICIENT_RESOURCES
487F16 end_CmRegisterCallback:
   ...
487F1A  retn   0Ch
   ...
487F1D free_slot_has_been_found:
487F1D  mov    eax, 1
487F22  mov    ecx, offset _CmpCallBackCount   ; CmpCallBackCount: number of not NULL item inside the vector
487F27  xadd   [ecx], eax                      ; there's a new callback, it increases the number of item inside the vector
487F2A  xor    eax, eax
487F2C  jmp    short end_CmRegisterCallback




As you can see the idea behind the function is really simple!
Basically, it tries to add a new entry inside a vector named CmpCallBackVector, and when the entry is correctly inserted the registration process will end with a success.
How do I know is it using a vector? The add instruction at 0x487EF6 represents a clear clue, and the cmp at 0x487EF9 reveals the fixed length of the vector (the vector has 100 items (0×190/4…)). Now that I have this information I’m going to try to explain the entire procedure in detail. The algorithm could be divided into 5 big blocks:

1: try to allocate 0×38 bytes for a structure named CM_CALLBACK_CONTEXT_BLOCK
2: try to allocate 0x0C bytes for a structure named EX_CALLBACK_ROUTINE_BLOCK
3: fill CM_CALLBACK_CONTEXT_BLOCK fields
4: look for an empty slot, insert a sort of PEX_CALLBACK_ROUTINE_BLOCK in it and update CmpCallBackCount
5: notify success or error and exit

Point #1 is pretty simple to understand, it’s only a call to ExAllocatePoolWithTag.

To understand point #2 you have to see what’s going on behind ExAllocateCallBack procedure. Let’s start taking a look at it:

52AB35  push   'brbC'                              ; Pool Tag: Cbrb
52AB3A  push   0Ch                                 ; NumberOfBytes: 0x0C
52AB3C  push   1                                   ; PoolType: PAGED_POOL
52AB3E  call   ExAllocatePoolWithTag               ; alloc a EX_CALLBACK_ROUTINE_BLOCK structure
52AB43  test   eax, eax                            ; ExAllocatePoolWithTag success or not?
52AB45  jz     short _ExAllocateCallBack_fails
52AB47  mov    ecx, [ebp+_pex_callback_function]   ; pointer to callback function (PEX_CALLBACK_FUNCTION)
52AB4A  and    dword ptr [eax], 0                  ; 1° field: 0
52AB4D  mov    [eax+4], ecx                        ; 2° field: _pex_callback_function
52AB50  mov    ecx, [ebp+_pool_allocated_memory]   ; PCM_CALLBACK_CONTEXT_BLOCK
52AB53  mov    [eax+8], ecx                        ; 3° field: _pcm_callback_context_block
52AB56 _ExAllocateCallBack_fails:
   ...




The procedure is used to allocate and fill a special structure:

typedef struct _EX_CALLBACK_ROUTINE_BLOCK
{
EX_RUNDOWN_REF RundownProtect;
PEX_CALLBACK_FUNCTION Function;
PCM_CALLBACK_CONTEXT_BLOCK Context;
} EX_CALLBACK_ROUTINE_BLOCK, *PEX_CALLBACK_ROUTINE_BLOCK;

As you can see from the lines above the first field has been setted to 0 while the other fields are filled with two pointers: the function to register and the context containing info about the callback.

While point #3 is just a series of mov instructions used to fill CM_CALLBACK_ROUTINE_BLOCK structure, point #4 gives some usefull information to us: CmpCallBackVector has 100 elements and this part of code is used to scan the entire vector until an empty element is found. A failure leads us to a non-registration of the callback. What happens when there’s a empty slot inside the vector? The new entry will be added inside the vector. Most of the job is done by the function named ExCompareExchangeCallBack, here is the core of the function:

52AB81  mov    eax, [ebp+CmpCallbackVector]    ; vector at the current position
52AB84  mov    ebx, [eax]                      ; ebx is a PEX_CALLBACK_ROUTINE_BLOCK, the item could be NULL or not
52AB86  mov    eax, ebx
52AB88  xor    eax, [ebp+OldBlock]             ; OldBlock is NULL for a registration process
52AB8B  mov    [ebp+current_pex_callback_routine_block], ebx
52AB8E  cmp    eax, 7                          ; check used to see if the current item is NULL or not
52AB91  ja     short loc_52ABB5                ; jump if not NULL
52AB93  test   esi, esi                        ; is NewBlock NULL?
52AB95  jz     short loc_52ABA1                ; jump if it's NULL
52AB97  mov    eax, esi                        ; esi, NewBlock pointer (changed...)
52AB99  or     eax, 7                          ; PAY ATTENTION HERE: or 7 !?!
52AB9C  mov    [ebp+NewBlock], eax             ; change NewBlock pointer: NewBlock = NewBlock OR 7
52AB9F  jmp    short loc_52ABA5
   ...
52ABA5 mov    eax, [ebp+var_4]               ; here if CmpCallbackVector's item is null
52ABA8  mov    ecx, [ebp+CmpCallbackVector]    ; current empty slot
52ABAB  mov    edx, [ebp+NewBlock]             ; new pointer to insert
52ABAE  cmpxchg [ecx], edx                     ; insert the new pointer inside the empty slot!
52ABB1 cmp    eax, ebx
52ABB3 jnz    short loc_52AB81
52ABB5 and    ebx, not 7                     ; PAY ATTENTION HERE!
52ABB8 cmp    ebx, [ebp+OldBlock]            ; here if CmpCallbackVector's item is not null
52ABBB jnz    short loc_52AC19
52ABBD test   ebx, ebx
52ABBF jz     short loc_52AC15




The routine contains some more things inside, but we can stop here with the analysis because we have everything we need. If the pointer to the NewBlock to insert is not NULL and there’s an available empty slot the pointer is inserted inside the vector; after that CmpCallBackCount value will be updated (remember the snippet at the beginning of this blog entry?).

The last part of the algorithm (point #5) is a simple return with a success or insuccess value:

52AC15 mov    al, 1                          ; 1 means success, new item has been added to CmpCallbackVector
52AC17 jmp    short loc_52AC29
52AC19 test   esi, esi                      ; esi -> NewBlock
52AC1B jz     short loc_52AC27
52AC1D push   8
52AC1F pop    edx
52AC20 mov    ecx, esi
52AC22 call   ExReleaseRundownProtectionEx   ; if esi is not null something went wrong...
52AC27 xor    al, al                         ; 0 means insuccess, new item has not been added to CmpCallbackVector




Ok, I think we have a general idea about the vector; each entry contains a *sort* of pointer to a EX_CALLBACK_ROUTINE_BLOCK, and to reveal all of them you only have to scan the entire vector!

To sum up, I have 3 possible scenes:
1. CmpCallbackVector’s item is empty:
the new block will be inserted inside the vector. The added value is not the one passed to ExCompareExchangeCallBack, but it’s the value modified by a “OR 7″ logic operation.
2. CmpCallbackVector’s item is full:
it simply returns STATUS_INSUCCESS and it will try with the next item of the vector
3. Someone is working on the CmpCallbackVector’s item:
the registration process reveals an interesting behaviour, just to be sure to be the only one accessing the resource the system uses a lock mechanism. The OR and AND operations are the core of that mechanism (0x52AB99 and 0x52ABB5, commented using “PAY ATTENTION HERE!”). If the current item of the vector is not NULL the compare instruction at 0x52AB8E fails and the code flow continues from 0x52ABB5. At this point the real address of the item is extracted (stored_value AND NOT 7) and compared with NULL; it’s obviously not NULL and as you can see around 0x52AC22 the resource is released because someone else is working on it. Now you should understand why the hell the system uses to OR by 7 the value to add inside the vector.

With all this kind of information I can finally write a routine able to read all the stored callbacks:

cells = 0x64;                    // cells inside CmpCallbackVector
nMod = *(DWORD*)_sysmodBuffer;   //	_sysmodBuffer filled by "ZwQuerySystemInformation(SystemModuleInformation..."
for(i=0;i<cells;i++)
{
   // take current item from CmpCallbackVector (look at the "& ~7" operation)
   pCBRB = (PEX_CALLBACK_ROUTINE_BLOCK)((*(DWORD*)(_CmpCallbackVectorAddress + 4*i )) & ~7);
   if (pCBRB != 0)
   {
      sysmodTmp = (PSYSTEM_MODULE_INFORMATION)((DWORD)_sysmodBuffer + 4);
      j = 0;
      while (jFunction) Base + (DWORD)sysmodTmp->Size) &&
			((DWORD)pCBRB->Function) > ((DWORD)sysmodTmp->Base))
         {
            // Callback has been found
            DbgPrint("Result: %LX: %s\r\n", pCBRB->Function, sysmodTmp->ImageName);
            break;
	 }
	 // get the next module
	 sysmodTmp = (PSYSTEM_MODULE_INFORMATION)((DWORD)sysmodTmp + sizeof(SYSTEM_MODULE_INFORMATION));
	 j = j + 1;
    }
}




It’s important to scan all the cells inside the vector! One of the tool available on the web fails to retrieve callbacks stored after an empty element of the vector.

Well, the only thing to reveal about the code above is CmpCallbackVectorAddress, the address of CmpCallBackVector. How can I locate the exact address of CmpCallBackVector? Imho, that’s the hardest part of the entire process!



How to find CmpCallbackVector address
To develop a tool for a specific OS is pretty easy because the vector’s address is hardcoded; it would be nice to discover an OS independent technique.
I think the most used approach is a byte-search based on a specific sequence of bytes; it’s a nice idea but I don’t want to list every OS version known to man inside my source code. We (I and kayaker) spent a lot of time over this point, we both wanted to develop something that is not totally related to a specific OS version; something that doesn’t require a series of “if OS == xxx” statements inside the code. It’s quite impossible to write a non OS dependent code but I believe it’s possible to remove some OS checks from the code.

We finally came up with two ideas, a practical and a theoretical idea. I hate theory and mine is the practical solution of course. I think both ideas are valid and just to be sure to find the right vector’s address we decided to combine them inside a hypothetical tool, four eyes are always better than two!



The practical approach
My idea is really simple, since of the vector’s address is hardcoded you’ll surely have it in two different parts of the code:

PAGE:005392D0   BB 20 05 48 00   mov    ebx, offset _CmpCallBackVector
.data:00480520                   _CmpCallBackVector db    0




The address is inside two sections, PAGE and data. An *xref-search* is the core of the idea! It’s pretty stupid indeed, but from what I’ve seen so far it works!
The pseudo code of my xref search is explained here, basically it scans the entire PAGE section trying to locate the right address:

callbackAddress = CmUnregisterCallback address in memory
pagePointer = pointer_to_PAGE_section
while (pagePointer < pointer_to_PAGE_section + size_of_PAGE_section)
{
   value = get dword pointed by pagePointer
   if (value is inside DATA section)
      if ((pagePointer > callbackAddress) && (pagePointer < callbackAddress + range))
      {
         CmpCallbackVector = value
	 exit!
      }
   pagePointer++
}




As you can imagine a simple xref-search is unable to find out the right value, you need one more check. That’s why I added the line:

if ((pagePointer > callbackAddress) && (pagePointer < callbackAddress + range))




where callbackAddress is the address of CmUnregisterCallback. What does it mean? Well, ‘pagePointer’ should be inside the first “range” bytes of CmUnregisterCallback function. If both “if” statements are satisfied I’m pretty sure about the vector’s address value.

There are still 2 points to clarify:
- what's range variable?
- why CmUnregisterCallback?

range is just a numerical value and you'll only have to decide a value to assign to it. Under XP the first bytes of the CmUnregisterCallback function are:

PAGE:005392C3 8B FF           mov    edi, edi
PAGE:005392C5 55              push   ebp
PAGE:005392C6 8B EC           mov    ebp, esp
PAGE:005392C8 51              push   ecx
PAGE:005392C9 83 65 FC 00     and    [ebp+var_4], 0
PAGE:005392CD 53              push   ebx
PAGE:005392CE 56              push   esi
PAGE:005392CF 57              push   edi
PAGE:005392D0 BB 20 05 48 00  mov    ebx, offset _CmpCallBackVector




In this specific case 16 could be a possible value… What about the other OSs? Well, as I said before I think it's hard to write a universal piece of code, but as far as I have seen it's possible to adjust the "range" to cover some more OSs. I don't have Vista and 7 running on my system and I'm working on the dead list only, but I think 148 could be a nice value to set and it should cover all the OSs. If you are still reading and you have Vista or 7, can you confirm that?
One more thing about the search pattern: I use CmUnregisterCallback because (inspecting all the OSs) CmRegisterCallback doesn't always store the CmpCallbackVector value inside the main routine, but it hides it under some calls. i.e. look at CmRegisterCallback from 7:

PAGE:0065712A mov  edi, edi
PAGE:0065712C push ebp
PAGE:0065712D mov  ebp, esp
PAGE:0065712F push [ebp+Cookie]
PAGE:00657132 mov  eax, offset stru_4FFDF0
PAGE:00657137 push 1
PAGE:00657139 push [ebp+Context]
PAGE:0065713C push [ebp+Function]
PAGE:0065713F call sub_657153                 ; It's everything inside this call!!!
PAGE:00657144 pop  ebp
PAGE:00657145 retn 0Ch




It’s much more complex to attack a procedure with sub-routines, don't you think? That's why I did opt for CmUnregisterCallback.



What about the PsSet* functions?
At the beginning of this blog post I mentioned some more functions, it's time to spend some words for them too.

The functions are:
PsSetCreateProcessNotifyRoutine
PsSetCreateThreadNotifyRoutine
PsSetLoadImageNotifyRoutine

There are some similarities between CmRegisterCallback and the new three functions: they all register something, they all use a vector to store the information, and they all use the same function! YES, to register a function they use the same scheme:

1. get the address of a specific vector
2. try to insert the new item inside the vector calling ExCompareExchangeCallBack

Just to clarify everything look at this snippet, taken from PsSetCreateThreadNotifyRoutine:

4ED7C4  mov    esi, offset _threadVector   ; the vector
4ED7C9  push   0
4ED7CB  push   ebx
4ED7CC  push   esi
4ED7CD  call   _ExCompareExchangeCallBack   ; the function
4ED7D2  test   al, al
4ED7D4  jnz    short loc_4ED7F3
4ED7D6  add    edi, 4
4ED7D9  add    esi, 4
4ED7DC  cmp    edi, 20h   ; the check over the number of items inside the vector
4ED7DF  jb     short loc_4ED7C9




The only different thing is the length of the vector:
_callbackVector: 0×64 slots
_processVector: 0×8 slots
_threadVector: 0×8 slots
_imageVector: 0×8 slots

Well, you can use all the info I gave you about CmRegisterCallback for these three functions too! I think you'll be able to retrieve all the hidden callbacks, and -just in case- unregister a callback. There are so many ways from the dirty one (put NULL inside the vector's slot) to the right one (calling the right unregister function)… you only have to decide!

To obtain the exe you have to simply click on a link which is show inside a chat request from a friend of you (the infected friend). The message I got is:
“Foto :D http://apps.facebook.com/peoplephotos/photo.php?=id_number”
where “foto” is the italian translation of “photo”, and id_number is your Facebook id (I removed mine).

The link is not working anymore on Facebook but I think they have some more available links to use… anyway, the interesting part of the malware is the use of a technique called Dynamic forking. It’s an old technique used sometimes inside packers and stuff like that, but as far as I have seen (and according to some friends) it’s a rarity to see it inside a malware. There’s an article explaining everything about the method right here: http://www.security.org.sg/code/loadexe.html (it’s dated April 2004!).
Is it really so interesting? Yes indeed, mainly because it’s not so easy to catch and debug the second exe on the fly. Not to mention you can’t dump it in an easy way. Is it impossible to study the exe? Not really… there’s always a simple way to do such things.

The “dynamic forking” method is all inside a call starting at 0x4013A0 address:

...
4013CE push CREATE_SUSPENDED
...
4013D3 push edx ; CommandLine = "PATH OF THE MALWARE\facebook-pic000163927.exe"
...
4013DB call _CreateProcessA ; it runs itself
...
401414 push ecx
401415 push edx
401416 mov _GetThreadContext, eax
40141B call eax
...
401432 push 4 ; number of bytes to read
...
401440 mov _ReadProcessMemory, eax
401445 call eax ; read BaseAddress from CONTEXT structure, it's 0x400000
...
401459 push edx ; BaseAddress: 0x400000
40145A push ecx ; process handle
40145B mov _ZwUnmapViewOfSection, eax
401460 call eax ; unmap!

It follows the article step by step, the last call is the most important one because it’s used to unmap the entire view of the section that contains BaseAddress. After that, the next part of the procedure is used to fill part of the unmapped section:

401462 mov esi, [ebp+decompressedBuffer] ; take care of ESI value!!!
401465 mov edi, [esi+3Ch]
401468 mov edx, [edi+esi+54h] ; SizeOfHeaders
40146C add edi, esi ; edi -> "PE"
40146E mov [ebp+decompressedBuffer], edx
...
40148A mov _VirtualAllocEx, eax
...
40149A push ecx ; size: 0x2FC000
40149B mov ecx, [ebp+var_1C]
40149E push edx ; 0x400000
40149F push ecx ; hprocess
4014A0 call eax ; VirtualAllocEx
...
4014D2 push 0
4014D4 push edx ; 0x400: number of bytes to write
4014D5 mov edx, [ebp+var_1C]
4014D8 push esi ; decompressedBuffer
4014D9 push ecx ; 0x400000
4014DA push edx
4014DB mov _WriteProcessMemory, eax
4014E0 call eax ; replace the header of the *new* process
... ; replace the rest of the *new* process's code

It allocs the necessary space for the *new* process (0x2FC000 represent the SizeOfImage of the real malware), and it replaces the old process code with the new one which is taken from a buffer pointed by ESI (look at 0×401462). This buffer is really important, I’ll tell you later why. Now, the final part of the procedure:

40158D mov [ebp+var_280], eax ; change oep of the file from 0x4017D3 to 0x40C4FF
...
4015A4 push ecx
4015A5 push edx
4015A6 mov _SetThreadContext, eax
4015AB call eax ; SetThreadContext
...
4015BE mov _ResumeThread, eax
4015C3 call eax ; ResumeThread

Pretty simple, it changes the entry point and it runs the process from the new location.

At this point I’m not able to debug the new process with a debugger like Ollydbg, I’m not even able to dump the new process… and the question is: how can I solve the problem? The dynamic forking is a powerfull method but there’s a big flaw in it, you always know how to dump the real malware: in this case decompressedBuffer is the answer! The buffer contains all the new code, and you only have to understand where the hell it was stored:

401383 push ecx ; finaluncompressedsize
401384 push ebp ; compressedbuffersize
401385 push edx ; compressedbuffer
401386 push edi ; uncompressedbuffersize
401387 push esi ; uncompressed buffer
401388 push COMPRESSION_FORMAT_LZNT1
40138A mov RtlDecompressBuffer, eax
40138F call eax

The malware uses lznt1 compression algo to reveal the real code. When the decompression ends you only have to dump 0×11200 bytes starting from UncompressedBuffer address and voilà! Now you can easily check the real malware!

Well, something unusual is always better than the usual boring thing…

I have to admit I’m a facebook fan, it’s really funny! I don’t spend my spare time on it, but from time to time I like to exchange some words with good old friends. Some days ago I did receive a lot of questions about the chat feature, many people are worried because the developers removed the “clear history chat” option. And now? How can they hide their secrets? Well, a little inspection inside the javascript code reveals the solution to this problem.

The function to call is named clearHistory. To clear the history you only have to put this line inside the address bar of your browser:

javascript:chatDisplay.tabs[id_person].clearHistory();

where id_person is the id of the person you were chatting with.

Good luck and good secrets to everyone! :P

For those who has not read the article I present a quick sum up of the technique, focusing on the necessary steps only:
1. allocate the necessary bytes required to store all the bytes of the dll
2. copy the original dll bytes inside the new allocated memory buffer
3. perform base relocation adjusting the necessary references
4. call DllEntryPoint directly from the new allocated buffer
5. when you don’t need the dll anymore it frees the allocated buffer

The error occours when the buffer is completely deallocated. The technique seems to be right but the question arises: why the hell someone needs to access an address inside a deallocated memory?

The problem is not strictly related with Joachim’s code itself, it’s an error caused by the use of user32.dll! At the moment I haven’t tried all the system dll, but if you understand the problem I’m pretty sure you’ll be able to solve it with another dll involved.

I have all the source code in front of me but when the problem is not totally related with it I prefer to use a debugger approach.

When the exception occours your debugger breaks here:

7C91E464 MOV EAX,DWORD PTR FS:[18] ; TEB
7C91E46A MOV EAX,DWORD PTR DS:[EAX+30] ; PEB
7C91E46D MOV EAX,DWORD PTR DS:[EAX+2C] ; PEB.KernelCallbackTable
7C91E470 CALL DWORD PTR DS:[EAX+EDX*4] ; call dword ptr [0xB72A10], access violation occours here!

The address (0xB72A10) is inside the allocated buffer, it’s obviously an entry of a vector. EAX represents the starting address of the vector and EDX is an index, each dword is an element of the vector. Starting address is 0xB72970, I only have to understand what’s behind that address.

Load user32.dll inside IDA and look at the vector, the xref will bring you inside DllEntryPoint:

7E39B3F6 mov eax, large fs:18h ; TEB
7E39B3FC mov eax, [eax+30h] ; PEB
7E39B3FF mov eax, [eax+18h] ; PEB.ProcessHeap
7E39B402 mov hHeap, eax
7E39B407 mov eax, large fs:18h
7E39B40D mov eax, [eax+30h]
7E39B410 mov dword ptr [eax+2Ch], offset off_7E392970 ; PEB.KernelCallbackTable

Can you see where the problem is? No!?! Ok, take a look at the same code that has been copied inside the allocated buffer (base relocation performed!):

00B7B3F6 MOV EAX,DWORD PTR FS:[18]
00B7B3FC MOV EAX,DWORD PTR DS:[EAX+30]
00B7B3FF MOV EAX,DWORD PTR DS:[EAX+18]
00B7B402 MOV DWORD PTR DS:[BD1224],EAX
00B7B407 MOV EAX,DWORD PTR FS:[18]
00B7B40D MOV EAX,DWORD PTR DS:[EAX+30]
00B7B410 MOV DWORD PTR DS:[EAX+2C],0B72970 <-- look here!!!

At the beginning of user32.dll there’s a particular initialization, it involves the heap and the KernelCallbackTable address. Both values are changed according to the new image base address but they will not be changed back to the old values.
If you don’t want an access violation inside your program you’ll have to restore the old values, nothing else…

The conclusion is simple, the code is perfectly right but it may be prone to this kind of weird conceptual bug… pay attention when you load a system dll!

The exe file imports few functions only, but the malware calls a lot of APIs. The author uses a special trick to call an API function, he creates a sort of bridge between the first instruction and the rest of the code of the function itself. The first instruction is executed directly from the stack, then a jmp instruction (the bridge) will lead you to the second instruction (and the rest of the code) of the function. I think I’ve already seen the trick somewhere but unfortunately I don’t remember where… maybe a specific packer or just something similar, I don’t know. If you have seen this trick before just drop me a comment, thx!

The malware is packed, but inside the unpacked file there’s something strange:

The exe is full of calls to NULL value. I’m pretty sure that it’s not an error occorred during the unpacking process; there’s something at the beginning of the exe able to fix the addresses. I started my analysis from the first lines of the unpacked file.

The Import Table is really small but spying inside the strings window I found a lot of common API strings. There’s a big list of functions, and they are divided into some groups; one group containing kernel32 functions, another one with user32 and so on. Working a little with some cross references I got the point I was looking for. It’s time to describe how the malware changes all the “call NULL” instructions.

First of all the malware gains access to kernel32 base address:

4013D5    mov  edi, large fs:30h  ; PEB
4013DC    mov  edi, [edi+0Ch]     ; PEB+0x00c   Ldr : Ptr32 _PEB_LDR_DATA
4013DF    mov  edi, [edi+0Ch]     ; +0x00c InLoadOrderModuleList : _LIST_ENTRY
4013E2    jmp  short loc_401404

4013E4 check_current_module:
4013E4    mov  eax, edi    ; eax points to current _LDR_MODULE structure
4013E6    add  eax, 2Ch
4013E9    push [ebp+arg_0]        ; unicode "kernel32.dll"
4013EC    push dword ptr [eax+4]  ; current module name inside InLoadOrderModuleList
4013EF    call Compare_UNICODE_Strings
4013F4    or   eax, eax
4013F6    jnz  short strings_are_not_equal
4013F8    mov  eax, edi           ; LDR_MODULE of the module I was looking for
4013FA    mov  eax, [eax+18h]     ; He gets the BaseAddress!!!
4013FD    pop  edi
4013FE    leave
4013FF    retn 4

401402 strings_are_not_equal:
401402    mov  edi, [edi]        ; jump to next module structure
401404 loc_401404:
401404    cmp  dword ptr [edi+18h], 0          ; Is BaseAddress 0?
401408    jnz  short check_current_module
40140A    xor  eax, eax
40140C    pop  edi
40140D    leave
40140E    retn 4

Quite common way, but quite uncommon inside a malware… at least from my not so experienced perspective. Anyway, once it has the right BaseAddress tha malware starts bridge-ing all the necessary functions.

It’s everything inside this call. It takes four parameters, we can ignore the first one pushed into the stack. What about the others?
- eax represents the BaseAddress of a module, in this case ntdll
- 404040 points to a sequence of strings, in this case the first one is “RtlZeroMemory”
- 406000 represents an address inside the malware
The procedure is called each time the malware needs to bridge a group of functions, all of them belong to a specific module. In this specific case it works with ntdll’s functions. The list of the functions starts from 0×404040 address:

The routine contains a loop running until all the functions inside the current group are not all bridged. Here is how the first function is bridged (the sub routine starts at 0×401411):

1. It takes VirtualAlloc starting address via Kernel32′s ExportTable
2. It gets the number of bytes of the first instruction of VirtualAlloc. On my XP machine VirtualAlloc starts with a two byte length instruction “MOV EDI, EDI”
3. It subtracts 7 from ESP value. 7 is obtained adding 5 (a fixed value) to the number of bytes of VirtualAlloc first instruction (2+5=7)
4. It copies the first two bytes of VirtualAlloc’s code inside the word pointed by the new stack pointer value
5. If the length of the first instruction is one byte only the malware checks for a possible active breakpoint comparing the byte with 0xCC value; quite useless check at this point…
6. It sets the byte pointed by ESP+2 to 0xE9
7. It fills the final 4 of 7 bytes obtaining:

You have the first instruction of VirtualAlloc at 0x12FDF5, then the jump instruction will lead you directly at the second instruction of VirtualAlloc. Now you understand why it decreases ESP value by 7, two bytes for the first instruction and 5 for the jump. Starting from 0x12FDFC you have the old untouched stack.
8. It gets the length of the first instruction of the function to bridge. In this specific case the name of the function is RtlZeroMemory and the length is 1
9. It adds 5 to the obtained value
10. It calls VirtualAlloc passing trought the stack. It calls 0x12FDF5, and it allocs 6 bytes. 6 is the value that comes from point #9 (5+1=6)
11. It copies the first instruction of RtlZeroMemory inside the allocated memory space
12. An anti breakpoint check occours this time because the first instruction is one byte only
13. It sets the second byte inside the allocated memory space to 0xE9 (again, a jmp instruction)
14. It fills the rest of the bytes:

Here is the bridge! It’s like what happened to VirtualAlloc, the allocated memory space contains the first instruction of RtlZeroMemory and a jump to the rest of the code
15. It restores the original stack pointer value simply adding 7 to the current ESP value
16. It returns the starting address of the allocated memory space (in this case 0×320000)

To sum up, the routine bridges the function and returns a memory address. The address will be saved starting from 0×406000 which is another parameter passed to the routine. If you don’t remind all the parameters you can take a look some lines above.
So, starting from 0×406000 you’ll have a series of dwords, each one containing a pointer to a memory allocated space; these are the values used to replace all the NULL calls. Now I finally know why after the unpacking process I still had a series of “call NULL” instructions.

Is it really necessary to bridge everything?
Yes if the author wants to fool an automatic analysis. I don’t know if the trick works or not, but it’s the only reasonable thing I can think of.
On the other hand, he can’t stop a complete human analysis because once you know how it works it’s pretty easy to convert all the “call NULL” instructions into the right ones; a simple idc script will solve the puzzle.

It’s a nice piece of malware to analyse btw, it has some interesting routines inside!

What do you use to extract .zip files? I’m pretty sure almost all the readers out there are using an external software like Winzip. I prefer to use 7-Zip, but Windows can extract zip archieve too. I use the Windows internal extractor when I’m running XP under a virtual machine. Some days ago I became aware of a strange behaviour extracting a series of protected zip files in sequence: the system doesn’t ask for the password.

I was extracting some malwares in sequence, all of them downloaded from the same site and all of them with the same password. I was asked to write the password for the first opened file only. Knowing that it’s possible to guess why it does happen. The light didn’t appear over my head and I spent some time looking at zipfldr.dll (the system uses this dll to handle zip protected files). Anyway, do you have a reasonable answer?

Well, to answer the question is pretty easy because the zip password remains in memory. What does it mean?
When you extract one or more file from a zip protected archieve a dialog appears asking you to insert the right password. You put the right password inside the box and all the files are extracted. When you perform the same operation with a new zip file the system repeats the same operations, but it firstly tries to use the old password with the new archieve. If the password is wrong the dialog box appears otherwise it uses the password which is stored somewhere inside the dll (0x7332757C under XP-sp1/sp3). The code inside the dll doesn’t delete the password when the file(s) is fully extracted.

Is it somehow dangerous?
As I said before only few are using the internal extractor so I think it’s not such a dangerous behaviour. However, it’s possible to steal zip password accessing a public computer. The path of the last opened zip file remains in memory too (not inside a static address value btw) and a quick scan of the memory could be enough to retrieve a valid file/password combination.

I wasn’t able to identify the packer used to protect the malware, it’s not such a problem indeed because the exe file is debug-able and it’s not hard to step through the code. You can try rebuilding the file, but in general I prefer to work on untouched files so my best choice it’s a simple dump. After that, in order to view all runtime retrieved functions I use my Ida plugin named Reveal Imports. In this way you can easily navigate through the disasmed file. Looking at the revealed imports I noticed some weird functions:

Quite unusual functions for a malware. The first thing to do is to check if they are used or not. These functions are called by the malware, and now I have to understand why. From my non professional experience with malwares in general, I know that most of the time the unusual code you see inside a malware comes from a source code available online. Google is a good friend, and a simple search reveals something interesting at milw0rm.
It’s the source code of the exploit that is used inside the malware (not the source of the malware!). I think it’s quite useful for newbies to disasm a routine having an eye on the source code, this malware represents a good exercize.

After remapping the memory…
The *exploit* routine starts at 40293E, and there’s an interesting loop at the beginning of the routine:

40296C search_right_handle:
40296C    cmp  [ebp+hFileMappingObject], 0FFFFh   ; hFileMappingObject is initially 0
402973    jnb  short loc_4029C1
402975    xor  eax, eax
402977    mov  [ebp+var_28], eax
40297A    push eax                             ; dwNumberOfBytesToMap
40297B    push eax                             ; dwFileOffsetLow
40297C    push eax                             ; dwFileOffsetHigh
40297D    push FILE_MAP_ALL_ACCESS             ; dwDesiredAccess
402982    push [ebp+hFileMappingObject]        ; hFileMappingObject
402985    call ds:MapViewOfFile
40298B    mov  [ebp+lpBaseAddress], eax
40298E    test eax, eax
402990    jz   short MapView_fails
402992    lea  ecx, [ebp+var_2C]
402995    push 0                          ; ResultLength
402997    push 10h                        ; SectionInformationLength
402999    push ecx                        ; SectionInformation
40299A    push 0                          ; SectionInformationClass
40299C    push [ebp+hFileMappingObject]   ; SectionHandle
40299F    call NtQuerySection             ; Retrieves information about the section object
4029A5    cmp  [ebp+var_28], SEC_COMMIT
4029AC    jz   short section_found
4029AE    push [ebp+lpBaseAddress]        ; lpBaseAddress
4029B1    call ds:UnmapViewOfFile         ; Wrong handle, unmap!
4029B7    xor  eax, eax
4029B9    mov  [ebp+lpBaseAddress], eax
4029BC
4029BC MapView_fails:
4029BC    inc  [ebp+hFileMappingObject]   ; Increments hFileMappingObject
4029BF    jmp  short search_right_handle

It repeatedly calls MapViewOfFile function using handle from 0 to 0xFFFF. If it finds the right handle it goes on with the rest of the code. As you can see from the snippet the malware restores the state of a wrong mapped view calling UnMapViewOfFile. That’s because it needs one and only one specific kind of section. It’s the first important step to complete.
On my XP machine the malware locates the right mapped view at 0xC30000, if you look at Ollydbg’s “Memory map” window you’ll see it only after MapViewOfFile was called; you should know why.

…the malware will initialize a CPalette object…

4029CC call RtlAllocateHeap_bridge   ; Allocates memory space
4029D1 test eax, eax
4029D3 jz   loc_402AA4
4029D9 mov  [ebp+var_14], eax
4029DC mov  word ptr [eax+2], 1    ; palNumEntries
4029E2 mov  word ptr [eax], 300h   ; palVersion
4029E7 push eax                    ; Logical palette
4029E8 call CreatePalette          ; Creates a logical palette

Pretty easy to understand.

…It will then search for the palette object in the shared memory structure…
The mapped view is then used by the malware inside a new loop. The malware looks for a PGDI_TABLE_ENTRY through the new memory space:

402A04 search_object:
402A04    mov  eax, [ebp+lpBaseAddress]
402A07    add  eax, [ebp+var_24]
402A0A    cmp  [ebp+GDI_Structure], eax         ; Is it inside the mapped memory?
402A0D    jnb  short loc_402A37
402A0F    mov  eax, [ebp+GDI_Structure]
402A12    xor  ecx, ecx
402A14    mov  cx, [eax+4]
402A18    mov  edx, [ebp+Pid]                   ; pGdiEntry->ProcessID
402A1B    cmp  ecx, edx
402A1D    jnz  short try_next_structure
402A1F    xor  ecx, ecx
402A21    mov  cx, [eax+0Ah]                    ; pGdiEntry->nType
402A25    cmp  ecx, 8                           ; PAL_TYPE
402A28    jnz  short try_next_structure
402A2A    mov  eax, [eax]                       ; pGdiEntry->pKernelInfo
402A2C    mov  [ebp+original_KernelInfo], eax   ; Saves the original value
402A2F    jmp  short loc_402A37
402A31 try_next_structure:
402A31    add  [ebp+GDI_Structure], 10h         ; Moves on the next structure to check
402A35    jmp  short search_object

It saves the original value of KernleInfo field which contains a pointer to something stored at ring0. You can imagine why it’s saving that value.. it will replace the address with something else for sure.

…it can be altered to include a pointer to a special function…

402A3E call _RtlAllocateHeap_bridge
   ...
402A4E push [ebp+hO]
402A51 pop  dword ptr [eax]              ; Stores handle obtained calling CreatePalette
402A53 mov  dword ptr [eax+14h], 1
402A5A push [ebp+hook_hidden_function]   ; push 402AC0
402A5D pop  dword ptr [eax+3Ch]          ; Stores the real function to call
   ...
402A6B mov  eax, [ebp+GDI_Structure]     ; Address of the original structure to replace
402A6E push [ebp+fake_structure]         ; Push the fake structure address
402A71 pop  dword ptr [eax]              ; To tamper!

It replaces the original data with something else. It’s more or less always the same trick, you exchange the old value with a new preferred one!

…Finally, a call to GetNearestPaletteIndex will indirectly cause the function to be executed…
The next call to GetNearestPaletteIndex will call what I have named hook_hidden_function, the hidden dangerous routine. To understand how the trick works you have to look inside win32k.sys, here’s part of GetNearestPaletteIndex:

00402A73 push 0
00402A75 push [ebp+hO]
00402A78 call GetNearestPaletteIndex
   ...
BF94B4AF mov  esi, [ebp+8]          ; esi -> fake structure created between 402A4E and 402A6E
   ...
BF94B4E0 call dword ptr [esi+3Ch]   ; esi+3C points to hook_hidden_function!!!

The malware will call the hidden function, you ignore it until you’ll realize that the machine is compromised. Nice trick indeed.

The malware seems to have some more interesting features, I hope to write something else about it in the next days.

The idea of the new plugin is the same: it reveals imports of a dumped process loaded inside Ida.

In general, for a non rebuilded dump you’ll have some problems guessing what kind of code will you face after “jmp 7C810DA6″ instruction. The plugin will come in handy when you need to analyze a dump without rebuilding the file using an external tool (i.e. Import Reconstructor).

To use the plugin is pretty easy, start saving it inside IDA plugin directory. Load the file in Ida, move the cursor inside the section containing the code you want to check and hit ALT+z to reveal hidden imports. If there’s something to reveal a window will appear showing the result.

It’s the first release and it’s far from being perfect. Anyway, if you like the plugin idea you can help me telling every kind of bug/problem/strange behaviour it has. This time I’ll try to fix/improve it.

Download

40107C ADD ECX,DWORD PTR SS:[ESP]   ; useless
40107F MOV ESI,-70                  ; useless
401084 ADD EDI,EAX                  ; useless
401086 MOV ECX,2AFFC5C8             ; useless
40108B ROL ECX,1                    ; useless
40108E ROR EDX,15                   ; useless
401091 MOV EDI,ESP                  ; edi = 12FFC4
401093 MOV EDX,FE000001             ; edx = 0xFE000001
401098 ROL EDX,7                    ; edx = 0xFF
40109B SUB EAX,EBX                  ; useless
40109D AND EDI,EDX                  ; edi = 0x12FFC4 && 0xFF = 0xC4
40109F MOV EDX,25FE0                ; edx = 0x25FE0
4010A4 ROL EDX,3                    ; edx = 0x12FF00
4010A7 ADD EDX,EDI                  ; edx = 0x12FFC4
4010A9 SAL ECX,11                   ; useless
4010AC MOV EAX,DWORD PTR DS:[EDX]   ; eax = 0x77E5EB69

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 0x12FF00 (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 :

401091 MOV EDI,ESP                  ; edi = 13FFC4
401093 MOV EDX,FE000001             ; edx = 0xFE000001
401098 ROL EDX,7                    ; edx = 0xFF
40109D AND EDI,EDX                  ; edi = 0x13FFC4 && 0xFF = 0xC4
40109F MOV EDX,25FE0                ; edx = 0x25FE0
4010A4 ROL EDX,3                    ; edx = 0x12FF00
4010A7 ADD EDX,EDI                  ; edx = 0x12FFC4
4010AC MOV EAX,DWORD PTR DS:[EDX]   ; CRASH!!!

The initial stack address is not the same, this time it’s 0x13FFC4. The malware was expecting to see 0x12FFC4, but the value it was looking for is stored inside 0x13FFC4 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.

7C819DE1  mov  eax, [ebp+MaximumStackSize]
7C819DE7  lea  ecx, [ebp+InitialTEB]
7C819DED  push ecx                          ; InitialTEB
7C819DEE  push eax                          ; MaximumStackSize
7C819DEF  push [ebp+StackSize]              ; StackSize
7C819DF5  push [ebp+hProcess]               ; hProcess
7C819DFB  call _BaseCreateStack@16          ; BaseCreateStack(x,x,x,x)
7C819E00  mov  [ebp+var_9EC], eax           ; eax = 0 means SUCCESS
7C819E06  cmp  eax, ebx                     ; ebx = 0
7C819E08  jl   _BaseSetLastNTError          ; Jump to error check
7C819E0E  push ebx                          ; NULL
7C819E0F  push [ebp+InitialSP]              ; Stack pointer
7C819E15  push [ebp+InitialPC]              ; Program counter
7C819E1B  push [ebp+Parameter]              ; Parameter
7C819E21  lea  eax, [ebp+Context]
7C819E27  push eax                          ; Context
7C819E28  call _BaseInitializeContext@20    ; BaseInitializeContext(x,x,x,x,x)

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:

7C8102B5 mov  eax, large fs:18h               ; eax = TEB
7C8102BB mov  ecx, [eax+30h]                  ; ecx = PEB
...
7C8102D2 push dword ptr [ecx+8]               ;  PEB->ImageBaseAddress
...
7C8102DB call ds:__imp__RtlImageNtHeader@4    ; RtlImageNtHeader(x)
7C8102E1 test eax, eax
7C8102E3 jz   failure
7C8102E9 mov  ecx, [ebp+MaximumStackSize]
7C8102EC test ecx, ecx                      ; is MaximumStackSize zero?
7C8102EE mov  edx, [eax+IMAGE_NT_HEADERS.OptionalHeader.SizeOfStackCommit]
7C8102F1 jnz  short MaximumStackSize_not_zero
7C8102F3 mov  ecx, [eax+IMAGE_NT_HEADERS.OptionalHeader.SizeOfStackReserve]
7C8102F6 mov  [ebp+MaximumStackSize], ecx

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:

7C8102F9 MaximumStackSize_not_zero:
7C8102F9 mov  eax, [ebp+StackSize]
7C8102FC test eax, eax                ; Is StackSize zero?
7C8102FE push edi
7C8102FF mov  edi, 0FFF00000h
7C810304 jnz  StackSize_not_zero
7C81030A mov  eax, edx
...

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:

7C80AFC2 cmp  eax, ecx             ; compare between StackSize and MaximumStackSize
7C80AFC4 jb   loc_7C81030C
7C80AFCA lea  ecx, [eax+0FFFFFh]           ;
7C80AFD0 and  ecx, edi                     ; fix MaximumStackSize
7C80AFD2 mov  [ebp+MaximumStackSize], ecx  ;
7C80AFD5 jmp  loc_7C81030C

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:

7C81036F mov  ebx, ds:__imp__NtAllocateVirtualMemory@24 ; NtAllocateVirtualMemory(x,x,x,x,x,x)

...
7C81037A push PAGE_READWRITE                  ; Protect: PAGE_READ_WRITE
...
7C810380 push MEM_RESERVE                     ; AllocationType: MEM_RESERVE
7C810385 lea  eax, [ebp+MaximumStackSize]
7C810388 push eax                             ; RegionSize = MaximumStackSize
7C810389 push 0                               ; ZeroBits = 0
7C81038B lea  eax, [ebp+_BaseAddress]
7C81038E push eax                             ; BaseAddress = 0;
7C81038F push [ebp+hProcess]                  ; ProcessHandle
7C810392 mov  [ebp+MaximumStackSize], ecx
7C810395 call ebx                             ; NtAllocateVirtualMemory

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:

7C81039F mov  edi, [ebp+InitialTEB]
7C8103A2 mov  ecx, [ebp+_BaseAddress]
7C8103A5 mov  eax, [ebp+MaximumStackSize]
7C8103A8 and  [edi+INITIAL_TEB.PreviousStackBase], 0
7C8103AB and  [edi+INITIAL_TEB.PreviousStackLimit], 0
7C8103AF mov  [edi+INITIAL_TEB.AllocateStackBase], ecx

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

7C8103B2 add  ecx, eax
7C8103B4 mov  [edi+INITIAL_TEB.StackBase], ecx

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 0x13FFC4 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.

The malware uses two uncommon functions RtlGetCompressionWorkSpaceSize and RtlDecompressBuffer. The functions are documented on MSDN, but the pages start with “[This is preliminary documentation and subject to change.]“. Searching through the net I found an old article by Alex Ionescu dated 2003, the article is titled “Native API Compression and Introduction to NT Design” and it’s available at his page. At that time the functions were undocumented, but he did explain how they works; the funny thing is that after 5 years MSDN is not sure about the description of the two functions…

Anyway, the function are mostly used to decompress a file (which is hidden inside the original exe). It’s pretty easy to use these functions, and with few lines of code you can have your compression engine. It’s always hard to understand the content of an encrypted/compressed series of bytes, but not this time because it’s easy to recognize a compressed exe just looking at the bytes.

As you can see there are some recognizable keywords: MZ, Rich, text, data. It’s enough to understand we are probably in front of an exe file. I wouldn’t hide an exe using this kind of compression…