Today I’m going to tell you something about the last malware I checked (MD5 0C17E03F41289E47EEB5D0F3F1F48C9C).

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 0×12FDF5, 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 0×12FDFC 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 0×12FDF5, 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!

A quick post today just to let you know my little adventure with password protected zip files.

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 (0×7332757C 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 put my hands on a malware linked from one of the online malware repositories (md5: 57127815d6864a495151e49c7bf7d192). From a quick glance at it I had the impression it’s an interesting malware to play with. It’s recognizable by almost all the antivirus products out there, and to have an idea about what it does I read some technical descriptions from some random antivirus pages.
In this post I won’t describe what the malicious file does, but I’ll spend few words on a specific behaviour only: CVE-2006-5758. I didn’t check all the sites, but seems like no one is reporting information about the exploit used inside this malware. It tries to exploit a GDI Local Elevation of Privilege vulnerability, patched on April 2007 (MS07-017); yes, more than one year and a half old. From what I have seen there’s only one article on the web talking about this malicious file, it’s available at cyberinsecure web page.
The article doesn’t refer to a specific malware, and I don’t know if I have the same file, but the quick description reveals almost the same characteristics of the file I’m working on:
“After remapping the memory, the malware will initialize a CPalette object. It will then search for the palette object in the shared kernel memory structure. Since the memory is now writable, it can be altered to include a pointer to a special function that will remove any existing SST hooks. Finally, a call to GetNearestPaletteIndex will indirectly cause the function to be executed. Afterwards, the palette object is restored leaving no trace of the attack.“.
I’ll use this comment to guide you through the post.

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.

In these days I wanted to fix my Reveal Imports plugin. I wrote it some months ago while I was checking a malware (click here for the full story); it’s bugged and it works on some malwares only.
The bad news is that I lost the source code… yes, it sometimes happens. It’s not the end of the world because if you were able to code a bugged program you should be able to write a new bugged one!

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

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.

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 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 :

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

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

Just a quick post today about an uncommon compression used in few malwares. Look at this snippet:

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…

In an old post I talked about a bug able to crash QuickTime on startup, here’s a QuickTime crash that occours when you close the application. The bugged code is something like:

movzx edx, ax
push edx                            ; lpData
push 1                              ; dwType
push 0                              ; Reserved
push eax                            ; lpValueName
push ebp                            ; hKey
call ds:RegSetValueExW

Do you see anything strange? Have a look at RegSetValueEx parameters, the last one is defined as:
__in_opt const BYTE *lpData
It’s a pointer to string. Pay attention to the previous instruction, movzx. The content of edx is limited to 16bits and it can cause stack buffer overflow. I don’t know anything about the value stored inside ax, but I’m not interesting in it.

The crash occours under particular conditions. Again, you have to change something inside QTPlayerSession xml file (located inside “Application Data/Apple Computer/QuickTime”). Here’s an example of a possible list stored inside the xml file:

QuickTime parses the file and create the entries inside the right registry key. The snippet I posted above will not be executed in normal condition, but it’s possible to run it cheating a little. Try modifying the file creating two equal entries:

Run QuickTime, close it and the program will crash due to a stack buffer overflow.

(Un)fortunately it’s not possible to exploit the bug, and due to the nature of the bug I don’t think it will cause problems to the users, it’s only an annoying box to close. If you have a crash like that you can try looking at the xml file…

Here is the solution I sent to crackmes.de, the crackme is easy but really enjoyable. You can find the crackme at http://www.crackmes.de/users/hmx0101/crappy_fun/

Intro
The crackme is packed with an home-made custom packer. When you run the file, the unpacking process starts and when it stops you should have the original file running on your system. This time it doesn’t happen, the crackme crashes. It’s our job to identify the reason behind the crash, and once you have fixed the file you can search for the right serial.

How to locate where the error occours
What the hell causes the crash? This is the main question, but the real problem is: how to locate where the error occours in an easy way?
You can start analysing the file from the beginning to the end, that’s the right way but it can take a lot of time. I prefer to take another way starting from the crash.

As you know, running the file you’ll obtain a crash. The error box doesn’t help me too much because it shows an error offset at 00059a5a, and looking at the original exe file I didn’t get anything useful at that address. I decided to take a look at the crash dump file generated by the OS. The file I’m referring to is named user.dmp and it’s located under Dr Watson folder. It contains the information of the last occourred crash, the one I’m interested to. To retrieve some information from the file you can load it into Windbg. The classical “!analyze -v” will reveal some hidden info (I copy&paste only some lines):

DEFAULT_BUCKET_ID:  BAD_INSTRUCTION_PTR

LAST_CONTROL_TRANSFER:  from 00405bf9 to 00059a5a

STACK_TEXT:
WARNING: Frame IP not in any known module. Following frames may be wrong.
0013ff98 00405bf9 00000000 5d4d0000 00454fe0 0x59a5a
0013ffbc 00469e0b 7c817067 00390032 00390038 CrappyFun+0x5bf9
00400000 00000000 000f0004 0000ffff 000000b8 CrappyFun+0x69e0b

FOLLOWUP_IP:
CrappyFun+5bf9
00405bf9 2c50            sub     al,50h

- DEFAULT_BUCKET_ID
the DEFAULT_BUCKET_ID field shows the general category of failures that this failure belongs to. The name of the category says it all.

- LAST_CONTROL_TRANSFER
it shows the last call on the stack. In this case, seems like the code at address 0×405Bf9 called a function at 0×59A5A

- STACK_TEXT
it shows a stack trace of the faulting component.

- FOLLOWUP_IP
When !analyze determines the instruction that has probably caused the error, it displays it in the FOLLOWUP_IP field.

I think Windbg is not able to produce a good output, seems like there are some errors inside the output generated by the debugging tool. I don’t think the error occours at 405BF9, I think it occours at the previous instruction which is something like “Call 00059a5a”. I got this idea looking at the STACK_TEXT contents.
Windbg shows the code from the original unpacked file, so if you want to inspect the code around 0×405BF9 you have to dump the exe. You can dump it when the error box appears. Here’s the unpacked snippet:

405BF2 push    0
405BF4 call    sub_405B24
405BF9 mov     ds:dword_458664, eax

405B24 jmp     ds:dword_4591E4

4591E4 dword_4591E4    dd 59A5Ah

Bingo! The error occours inside the call at 405BF4. Now I only have to find out what 0×59A5A represents. If you are using IDA you’ll see:

4591D8 dword_4591D8    dd 59A30h               ; DATA XREF: sub_405B3C
4591DC dword_4591DC    dd 59A3Eh               ; DATA XREF: sub_405B34
4591E0 dword_4591E0    dd 59A4Ch               ; DATA XREF: sub_405B2C
4591E4 dword_4591E4    dd 59A5Ah               ; DATA XREF: sub_405B24

These addresses are referenced by instructions like:

jmp ds:dword_0045xxxx

It’s pretty obvious now, these are not-resolved functions. That’s why the exe crashes.
Presumably the point to fix resides inside the procedure used to resolve the API. A good and quick way consist of using some clever breakpoints on functions like LoadLibrary/GetProcAddress; after some minutes I got the right point to patch.

This is how I solved the first point (fix the unpacked file). I think it’s the fastest way because you start looking through the loader having in mind what you are looking for.
Before giving out what to patch I’ll spend some words on the loader. I’m writing a solution and I’ll try to give you a sort of detailed analysis of the packer too.

The packer
The packer has a linear loader, it makes everything easy. The loader starts with an RDTSC trick, it’s located inside the first ten lines of code. The check is performed here:

00469C2B CMP EAX,0FFF
00469C30 JNB CrappyFu.00469E04
00469C36 CALL CrappyFu.00469C3B

If the program reveals the presence of a debugger you won’t pass through 469C36. So, if you want to continue studying the exe you firstly have to get rid of this check.

Just after the initial check you can find a decryption loop:

00469C54 MOV EBX,CrappyFu.00469C72	//	Initial address
00469C59 MOV ECX,384			//	Number of bytes to decrypt
00469C5E MOV AL,9A			//
00469C60 XOR BYTE PTR DS:[ECX+EBX],AL	//	Xor decryption
00469C63 MOV AL,BYTE PTR DS:[ECX+EBX]	//	Decrypted byte is used to decrypt the next one
00469C66 LOOPD SHORT CrappyFu.00469C60	//	Jump up for the next byte to decrypt

The packer’s code was encrypted using a xor operation. When the loop ends you have the packer’s code in front of your eyes, the first thing you should see is an anti debug trick:

00469C68 MOV EAX,DWORD PTR FS:[18]
00469C6F MOV EAX,DWORD PTR DS:[EAX+30]
00469C73 MOVZX EAX,BYTE PTR DS:[EAX+2]
00469C78 CMP EAX,1
00469C7B JE CrappyFu.00469E04

The good old IsBeingDebugged check. You should know how to pass it. It’s the second trick, and if you want to continue analyzing the exe remember to avoid it too. Moreover you’ll have to avoid the next one too:

00469CAA XOR ECX,ECX
00469CAC ADD ECX,10
00469CAF MOV EBX,77FFFFFF
00469CB4 MOV EAX,DWORD PTR FS:[EBX+88000019]	//	eax = 7FFDE000... fs:[18]
00469CBB MOV EAX,DWORD PTR DS:[EAX+ECX*2+10]	//	It's IsDebuggerPresent check!!!
00469CBF MOVZX EAX,BYTE PTR DS:[EAX+2]		//
00469CC3 NOT EAX
00469CC5 AND EAX,1
00469CC8 MOV EBX,EAX				//	ebx = 0 if you are debugging the file
00469CCA PUSH 0C3FBF6				//	Push a dword value
00469CCF CALL CrappyFu.00469CD4
00469CD4 SUB DWORD PTR SS:[ESP],33		//	Fix the return value
00469CD8 MOV ESI,ESP				//
00469CDA ADD ESI,4				//	esi -> value pushed at 469CCA
00469CDD JMP ESI				//	jump to esi

A nice antidebug trick. It’s an IsDebuggerPresent check with an unusual check. In the previous check there’s a compare between the value stored inside eax and 1; this time the check is a little bit writhed.
“PUSH 0C3FBF6″ seems like a simple push of a dword value, but if you check carefully the next instructions you’ll discover the real meaning of the dword value:

0012FFC0   F6FB      IDIV BL				//	F6 FB
0012FFC2   C3        RETN				//	C3
0012FFC3   0069 EB   ADD BYTE PTR DS:[ECX-15],CH	//	00

The author uses an idiv instruction as a final check, if you are debugging the file bl will be 0 and the idiv instruction will raise an exception. Otherwise, you wont have any error and the packer will proceed without any problems.

The next step performed by the packer is another decryption loop. This time it’s not so easy like the first one we saw at the beginning but it’s not hard to understand how it works. The decryption routine decrypts the code section. The decryption uses a dinamically allocated buffer, allocated using VirtualAlloc; since of I should know where the crash occours I’m not interested in this decryption by now. If you want to check the routine pay attention on the antidebug trick, there’s a breakpoint check.

Ok, we are at the end of the loader. The last part of the code is between 0×469E0B and 469F05 addresses. The snippet starts with:

00469E0B PUSHAD
00469E0C JMP SHORT CrappyFu.00469E12

ending with:

00469EFD PUSH 54FD0 //
00469F02 ADD DWORD PTR SS:[ESP],EBP // I guess oep is at 4054FD0
00469F05 RETN //

However, the code between these two address perform some steps:
- decrypt a lot of strings (again, xor decryption)
- retrieve addresses of API
I’m near the solution. Let’s take a look at the routine used to retrieve the addresses (I removed parts of the code):

00469E85 CMP DWORD PTR DS:[EDX],0		//	Is there another address to retrieve? EDX = 0x459118
00469E88 JE SHORT CrappyFu.00469EE3		//	No: jump out
...
00469EA7 PUSH EAX				//	eax -> current function
...
00469EC4 PUSH EBX
00469EC5 CALL ESI				//	GetProcAddress applied to the current function
...
00469EC9 TEST EAX,EAX				//	Address ok?
00469ECB JE CrappyFu.00469E04			//	Jump if error occours
00469ED1 CMP BYTE PTR DS:[EAX],0CC		//	Is there a bpx on the first byte of the current function?
00469ED4 JE CrappyFu.00469E04			//	Yes: error!
00469EDA JMP SHORT CrappyFu.00469EDE		//	No: jump... !?!
00469EDC MOV DWORD PTR DS:[EDX],EAX		//	NOT EXECUTED
00469EDE ADD EDX,4				//	Update edx
00469EE1 JMP SHORT CrappyFu.00469E85

Do you remember why the crash occours? The file crashes because there’s a problem with the value stored inside 4591E4. At 469E85 edx has the value 459118, pretty near the address of the suspicious dword. This is a big hint, I’m in front of the bugged code.
The snippet is a classical piece of code used to fix imported functions, there’s only a strange thing inside this snippet; I’m referring to code around 469EDA. What does it happen to the retrieved address? Nothing… it’s simply discarded!

How to fix it?
I decided to nop the jump instruction at 469EDA. I want to change:

00469ED4  0F84 2AFFFFFF    JE CrappyFu.00469E04
00469EDA  EB 02            JMP SHORT CrappyFu.00469EDE
00469EDC  8902             MOV DWORD PTR DS:[EDX],EAX

into:

00469ED4  0F84 2AFFFFFF    JE zai_Crap.00469E04
00469EDA  90               NOP
00469EDB  90               NOP
00469EDC  8902             MOV DWORD PTR DS:[EDX],EAX

Do you remember the initial xor decryption? This is what I have to solve:

Byte to find ^ *key* = decrypted_byte
byte_463EDB  ^ 0x89  = 0x90	    	-->	byte_463EDB = 0x19
byte_463EDA  ^ 0x90  = 0x90		-->	byte_463EDA = 0x00
byte_463ED9  ^ 0x90  = 0xFF		-->	byte_463ED9 = 0x6F

You can modify the original exe file patching the bytes between 463ED9/463EDB with 0×6F, 0×00 and 0×19 (offset 0×334D9/0×334DB). Now I have a working crackme.

Task 2: the right serial
The crackme is a Delphi application, Dede will tell you everything about the file. The serial check routine starts at 0×454C98 (TForm1_Button1Click). It gets the serial, length must be 6 chars long. The main procedure starts from 0×45475C; it’s a really long procedure. I have to say I wanted to give up, but it’s more easy than it seems. There are mainly 3 functions called many times. The functions I’m referring to are Multiply, Add and Sub; here are some snippets taken from the code:

454773 mov dl, [ebp+s_6]
454776 mov ecx, 4
45477B mov eax, 6 // Multiplier
454780 call Multiply // Execute: eax * dl

45480B pop edx
45480C call add // Execute: eax + edx

454821 pop edx
454822 call sub // Execute: eax – edx

Try stepping a little inside the procedure and you’ll surely get the main point of the routine. If yuo have Ida you don’t have to step a single line because you can understandd everything from the dead list.
The entire procedure is used to create a system of linear equations, 6 equations in 6 variables:

1 * s1 + 3 * s2 + 2 * s3 – 3 * s4 – 4 * s5 – 6 * s6 = -453
2 * s1 – 7 * s2 + 3 * s3 + 7 * s4 + 2 * s5 + 1 * s6 = 849
7 * s1 + 9 * s2 – 6 * s3 – 4 * s4 – 6 * s5 + 7 * s6 = -218
5 * s1 + 2 * s2 + 4 * s3 + 2 * s4 + 4 * s5 – 1 * s6 = 1643
3 * s1 – 1 * s2 + 1 * s3 – 1 * s4 + 1 * s5 – 1 * s6 = 192
8 * s1 – 2 * s2 + 1 * s3 + 1 * s4 – 4 * s5 + 1 * s6 = 134

where s1..s6 are the 6 chars from the serial. The final check is done calling 6 functions sequentially. Each function performs 1 check. First function checks 1° equation (it must be equal to -453), 2° function checks 2° equation (it must be equal to 849) and so on…
I think you can easily find out how the checks are done.

Is it possible to solve the system?
Rank is 6, there’s only 1 solution. When I was at uni I was able to solve such systems in a short time, but now I’m a bit rusty. I could use the elementary method: substitution… I preferred to use an automatic engine. The result is:
s1 = 70 : F
s2 = 97 : a
s3 = 105 : i
s4 = 114 : r
s5 = 121 : y
s6 = 33 : !

The right serial is Fairy!

This is a sort of continuation of the previous post, the one about malware able to infect right-handed only.
It’s a Msn malware, one of the recent one (as far as I remember I got it from Malware Domain List). I think there’s often something interesting inside a malware, no matter what it does and this is a perfect example!

The malware is not really interesting per se, but it has something I’ve never noticed before. It’s not a cool and dangerous new technique, but a coding behaviour. Look at the graph overview:

The image represents the content of a malware procedure. Nothing strange per se, except the fact that it contains 657 instructions in it, too many for a simple malware. It’s a big routine and I was surprised at first because you can do a lot of things with so many instructions. I started analysing the code, nothing is passed to the routine and nothing is returned back to the original caller. I tought it should be an important part of the malware, but I was disappointed by the real content of the routine. After few seconds I realized what’s really going on: 657 lines of code for doing something that normally would require around 50 lines…
The function contains a block of 17 instructions repeated 38 times. When I’m facing things like that I always have a little discussion with my brain. The questions are:
- why do you need to repeat each block 38 times?
- can’t you just use a while statement?
- is this a sort of anti-disassembling trick?
- can you produce such a procedure setting up some specific compiler’s options?

The repeated block contains the instruction below:

00402175    push 9                       ; Length of the string to decrypt
00402177    push offset ntdll_dll        ; String to decrypt
0040217C    push offset aM4l0x123456789  ; key: "M4L0X123456789"
00402181    call sub_401050              ; decrypt "ntdll.dll"
00402186    add  esp, 0Ch
00402189    mov  edi, eax
0040218B    mov  edx, offset ntdll_dll
00402190    or   ecx, 0FFFFFFFFh
00402193    xor  eax, eax
00402195    repne scasb
00402197    not  ecx
00402199    sub  edi, ecx
0040219B    mov  esi, edi
0040219D    mov  eax, ecx
0040219F    mov  edi, edx
004021A1    shr  ecx, 2
004021A4    rep movsd
004021A6    mov  ecx, eax
004021A8    and  ecx, 3
004021AB    rep movsb

It’s only a decryption routine, nothing more. The string is decrypted by the “call 401050″, the rest of the code simply moves the string in the right buffer.
Ok, let’s try answering the initial questions.

According to some PE scanners the exe file was produced by Microsoft Visual C++ 6.0 SPx.
It’s possible to code the big procedure just using a loop (while, for, do-while) containing the snippet above. I don’t think the author used one of these statements because as far as I know it’s not possible to tell the compiler to explode a cycle into a sequence of blocks. At this point I have to options:
- he wrote the same block for 38 times
- he defined a macro with the block’s instructions repeating the macro for 38 times
I won’t code something like that, but the macro option seems to be the most probable choice.
Is it an anti-disassembling trick? My answer is no because it’s really easy to read such a code. You don’t have to deal with variables used inside a for/while; to understand what’s going on you only have to compare three or four blocks.
I don’t have a valid answer to the doubt I had at first….

Trying to find out some more info I studied the rest of the code. I was quite surprised to see another funny diagram.

This time the image represents the content of the procedure used to retrieve the address of the API functions. Again, no while/for/do-while statement. The rectangle on the upper part of the image it’s a sequence of calls to GetProcAddress, and the code below it’s just a sequence of checks on the addresses obtained by GetProcAddress.
It’s a series of:

address = GetProcAddress(hDLL, "function_name");

followed by a series of:

if (!address) goto _error;

Apart the non-use of a loop there’s something more this time, something that I think reveals an unusual coding style; tha author checks errors at the end of the procedure. I always prefer to check return values as soon as I can, it’s not a rule but it’s something that help you to avoid oversight and potential errors… The procedure has a little bug/oversight at the end, the author forgot to close an opened handle. Just a coincidence?

Anyway, two procedures without a single loop. Seems like the author didn’t use any kind of loop for choice. In case you still have some doubts here’s another cool pictures for you:

The routine inside the picture contains the code used to check if the API(s) are patched or not. The check is done comparing the first byte with 0xE8 and 0xE9 (call and jump). If the functions are not patched the malware goes on, otherwise it ends. As you can see no loops are used.

In summary: it’s not jungle code, it’s not an anti-disasm code and it’s not a specific compiler setting. I think it’s only a personal choice, but I would really like to know why the author used this particular style.
Do you have any suggestions?

Beyond the coding style, the malware has some more strange things. As pointed out by *asaperlo*, the code contains a bugged RC4 implementation (Look at the comments of the previous blog post).
It also has a virtual machine check. The idea is pretty simple, the malware checks the nick of the current user. If the nick is “sandbox” or “vmware” you are under a virtual machine…
This malware spawns another one (it’s encrypted inside the file), it might be material for another post.

That’s a funny coded malware for sure!

I’m not kidding, the title is right.

Among all the windows settings there’s one made for left handed people. The option I’m referring to is located under the Mouse control panel, labelled “Switch primary and secondary buttons”. It lets you exchange the functions performed by the right and left mouse button. Don’t know if this setting is usefull or not, most of the left handed friends I have are still using the mouse like a right handed. Maybe they don’t even know the existence of such an option. Anyway, look at this code:

It’s a simple query on a registry key named SwapMouseButtons.
result_value is sent back to the caller, and the caller checks the value. If the value is equal to 0×30 (right handed) the malware goes on running the rest of the code, but if the value is 0×31 (left handed) the malware ends immediately. All the nasty things performed by the malware are executed after this check, it means that a left handed won’t get infected!

I’ve seen some malwares using SwapMouseButton function in the past, but never something like that. I bet the author is left handed and he wrote the check just to be sure to avoid a possible infection… I can’t think of anything else. Quite funny!!!