Introduction



In this article we will look in depth at a Custom Packer used by a Malware that was recently found in the wild. This packer is interesting for several reasons. It uses several layers of packers including the well-known UPX Packer which is only used to mask the underlying custom packers.

It also uses a clever way of injecting code into a remote process and resuming its execution from there. I have included necessary screenshots with snippets of assembly language code sections along with comments, stack parameters for API calls and views of memory dump. This will help in following the article while the unpacking method is described.

An Overview



Since the unpacking method is described in depth and there are several layers, I am giving a high level overview of the algorithm at first before going in depth.

It uses a UPX packer which is used only for the purpose of masking the underlying custom packers. UPX packers as we know can be easily unpacked. The first layer of a custom packer uses a lot of code which has been placed only to increase the size of code we have to go through while reversing. With the help of few example code snippets, this has been explained. It’s used to deter reverse engineering. It stores the encrypted subroutine at a particular offset within itself. This subroutine is later decrypted and executed. In the second stage, the decrypted subroutine performs another level of unpacking. There is an encrypted malicious executable embedded inside the main image which is decrypted in two phases. After the decryption of the malicious executable, it proceeds to modify the header of the main image. It copies the various sections of the malicious executable like PE Header, .text, .rsrc, .reloc to the start of main image. It then calls the AddressOfEntry point of the malicious executable. This code will spawn a new process, svchost.exe in a suspended state. It then proceeds to inject the malicious code in svchost.exe process and resume its execution.

Unpack the UPX



This executable uses a clever way of packing. It uses a well-known packer called UPX which is detected by most automated sandboxes and packer identifiers like PEiDand ProtectorID.

So, we start by unpacking the UPX packer. As already known, UPX packers can be unpacked using the ESP + hardware breakpoint trick. So, let us unpack it using this method.

This is how the Original Entry Point of a UPX packed binary looks:

We step over the PUSHAD instruction which will save the contents of all the registers on the stack.

Once we step over PUSHAD, we will follow ESP in memory dump and set a Hardware Breakpoint at the WORD present at that memory location. The reason this is done is: once the unpacking completes, POPAD instruction will be executed that will restore the contents of registers.

As a result, this memory location will be accessed and modified. So, we set the hardware breakpoint as shown in the screenshot below:

Once we run the executable after setting the hardware breakpoint, we break at the following memory location:

Next, we set a breakpoint at 0x004170B4 to skip over the loop.

Once we step over this, we reach the Original Entry Point at 0x00402690.

In most cases, this is the unpacked executable and now you can start stepping through the code to understand the malware. So, let’s continue with that.

Identification of Unnecessary Code Sections



This is how our Original Entry Point at 0x00402690 looks like after unpacking UPX:

This looks good, so let’s continue.

After tracing the code further from OEP, we reach a CALL to the subroutine at address, 0x00401020.

In most cases, you would reach the code corresponding to malware after this. So, let’s see:

This subroutine contains a lot of code which has been placed to deter reverse engineering. For instance, if you check the section of code below:

1 2 3 MOV DWORD PTR SS:[EBP-58],F47117C3 CMPDWORD PTR SS:[EBP-58],F8EC0A77 JNZSHORT Shipment.0040108F ; this jump will always be taken

It moves a constant DWORD into a memory location, [EBP-58] and then compares it with another constant DWORD, followed by a check for whether they are unequal. Since they will always be unequal, the Jump will be taken.

Similar lines of code were observed in multiple places in the subroutine which were added only to increase the size of code that we have to go through while reversing.

Similarly, another section of code:

1 2 3 4 5 MOV DWORD PTR SS:[EBP-54],F498C7E5 MOV EDX,DWORD PTR SS:[EBP-54] IMUL EDX,DWORD PTR SS:[EBP-54] ADD EDX,DWORD PTR SS:[EBP-54] MOV DWORD PTR SS:[EBP-54],EDX

It moves a constant DWORD into [EBP-54], and then moves it to EDX, multiplies with itself, and then adds it to the result and stores back in the memory address.

However, this value is not relevant to us for reversing.

Decryption of Custom Unpacking Subroutine



Proceeding in this way and skipping over sections of code that use code similar to above, we reach a CALL to VirtualAlloc with the stack parameters as shown below:

It allocates a new memory with a size of 0x1830 bytes.

It is important to note that, VirtualAlloc is a good way of locating the Original Entry Point of an executable. The reason being, while unpacking it’s common to see a CALL to VirtualAlloc which allocates a new memory region. Encrypted data is copied to this memory location and then decrypted.

If the data at this memory location is executed later on, then it means we have unpacked it or reached the original entry point (it’s possible that there is more code obfuscation later).

In our case, the call to VirtualAlloc() allocates a new memory region at base address, 0x00C50000

Tracing the code further we reach a CALL to subroutine at 0x004016F0 as shown below:

Tracing this subroutine further, we locate our first decryption routine:

The encrypted data is stored at memory address, 0x405028as shown below:

Here is a high level overview of the decryption subroutine:

It reads one DWORD at a time from the encrypted data. It modifies the DWORD by passing it to a subroutine at 0x00401A80 The DWORD modified above is passed to a second subroutine at 0x004014E0 The final modified DWORD is written to the newly allocated memory region at 0x00C50000 There is a counter which is used to keep track of the number of DWORDs read from the Encrypted Data section. A total of 0x12A DWORDs are read, modified and written to the newly allocated memory region.

Below is the code explanation with comments:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 MOV EDX,DWORD PTR SS:[EBP-C]; counter MOV EAX,DWORD PTR DS:[EDX*4+405028]; read a DWORD from the encrypted data stored at 0x0405028 MOV DWORD PTR SS:[EBP-54],EAX MOV ECX,DWORD PTR SS:[EBP-54] PUSH ECX; pass the DWORD to the subroutine CALL Shipment.00401A80 ; First DWORD modification routine ADD ESP,4 MOV DWORD PTR SS:[EBP-54],EAX; modified DWORD is stored in [EBP-54] MOV DWORD PTR SS:[EBP-58],0AB6C LEA EDX,DWORD PTR SS:[EBP-58] MOV DWORD PTR SS:[EBP-5C],EDX MOV EAX,DWORD PTR SS:[EBP-58] OR EAX,9E2F; OR 0AB6C with 9E2F MOV ECX,DWORD PTR SS:[EBP-5C] MOV EDX,DWORD PTR DS:[ECX] AND EDX,DWORD PTR SS:[EBP-58] IMUL EAX,EDX ADD EAX,DWORD PTR SS:[EBP-58] MOV DWORD PTR SS:[EBP-58],EAX MOV EAX,DWORD PTR SS:[EBP-54] PUSH EAX; pass the modified DWORD to the subroutine CALL Shipment.004014E0 ADDESP,4 MOV ECX,DWORD PTR SS:[EBP-C] MOV EDX,DWORD PTR SS:[EBP+8] XOR EAX,DWORD PTR DS:[EDX+ECX*4] MOV ECX,DWORD PTR SS:[EBP-C] MOV EDX,DWORD PTR SS:[EBP+8] MOV DWORD PTR DS:[EDX+ECX*4],EAX MOV EAX,DWORD PTR SS:[EBP-C]; get the previous value of counter ADD EAX,1; increment the counter MOV DWORD PTR SS:[EBP-C],EAX MOV ECX,DWORD PTR SS:[EBP-C] CMP ECX,DWORD PTR SS:[EBP-1C]; check if counter <= 0x12A (total size of the data to be decrypted) JB SHORT Shipment.004017F2 MOV DWORD PTR SS:[EBP-8],F4617F55 MOV EDX,DWORD PTR SS:[EBP-8] IMUL EDX,DWORD PTR SS:[EBP-8] MOV DWORD PTR SS:[EBP-20],EDX MOV ESP,EBP POP EBP RETN

Here is the first DWORD modification routine:

Here is an explanation of the code with comments:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 PUSH EBP MOV EBP,ESP SUB ESP,14 ROL DWORD PTR SS:[EBP+8],6; the encrypted DWORD is rotated left by 6 positions MOV DWORD PTR SS:[EBP-8],96 MOV DWORD PTR SS:[EBP-4],FFCE4D33 MOV EAX,DWORD PTR SS:[EBP-8] CMP EAX,DWORD PTR SS:[EBP-4] JNZ SHORT Shipment.00401AAC ; this jump will always take place ..... MOV EAX,DWORD PTR SS:[EBP+8]; the encrypted DWORD is moved back in EAX MOV ESP,EBP POP EBP RETN

The result of the first DWORD modification routine is passed to the second subroutine at: 0x004014E0



Here is the second DWORD modification routine:

Here is the code with comments:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 PUSH EBP MOV EBP,ESP SUB ESP,38 MOV DWORD PTR SS:[EBP-8],6375; this is the XOR key used to modify the DWORD MOV DWORD PTR SS:[EBP-10],FBCA85D0 MOV EAX,DWORD PTR SS:[EBP-10] AND EAX,7D; 0xFBCA85D0 AND 0x7D MOV ECX,DWORD PTR SS:[EBP-10] AND ECX,0D4; 0xFBCA85D0 AND 0x0D4 SUB EAX,ECX IMUL EAX,DWORD PTR SS:[EBP-10] MOV DWORD PTR SS:[EBP-10],EAX MOV DWORD PTR SS:[EBP-18],6D MOV EDX,DWORD PTR SS:[EBP-10] IMUL EDX,DWORD PTR SS:[EBP-18] ADD EDX,DWORD PTR SS:[EBP-18] MOV DWORD PTR SS:[EBP-18],EDX MOV EAX,DWORD PTR SS:[EBP+8]; value of the first modified DWORD XOR EAX,DWORDPTR SS:[EBP-8]; XOR the first modified DWORD with 0x6375 MOV DWORD PTR SS:[EBP+8],EAX; store it back in memory MOV DWORD PTR SS:[EBP-4],5

After returning from the second subroutine, it will write this modified DWORD in the newly allocated memory region:

Here is an explanation of the code with comments:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 ADD ESP,4 MOV ECX,DWORD PTR SS:[EBP-C] MOV EDX,DWORD PTR SS:[EBP+8] XOR EAX,DWORDPTRDS:[EDX+ECX*4] MOV ECX,DWORD PTR SS:[EBP-C] MOV EDX,DWORD PTR SS:[EBP+8] MOV DWORDPTRDS:[EDX+ECX*4],EAX MOV EAX,DWORD PTR SS:[EBP-C]; get the previous value of counter ADD EAX,1; increment the counter MOV DWORD PTR SS:[EBP-C],EAX MOV ECX,DWORD PTR SS:[EBP-C] CMP ECX,DWORD PTR SS:[EBP-1C]; check if counter <= 0x12A (total size of the data to be decrypted) JB SHORT Shipment.004017F2 MOV DWORD PTR SS:[EBP-8],F4617F55 MOV EDX,DWORD PTR SS:[EBP-8] IMUL EDX,DWORD PTR SS:[EBP-8] MOV DWORD PTR SS:[EBP-20],EDX MOV ESP,EBP POP EBP RETN

Once the decryption has completed, we have the decrypted data present at 0x00C50000 as shown below:

Now, it calls the decrypted subroutine at 0x00C50000 as shown below:

Unpacking the Custom Packer – Stage 1



Once we step into this subroutine we are the first decrypted subroutine as shown below:

Here is an explanation of the code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 NOP NOP NOP NOP NOP PUSH EBP MOV EBP, ESP SUB ESP,18 PUSH EBX PUSH ESI PUSH EDI CALL00C50013 POP EBX SUB EBX,13; EBX points to the start of decrypted subroutine, 00C50000 CALL 00C501FA; Get kernel32.dll base address and API addresses OR EAX,EAX JE 00C50143 CALL DWORDPTRDS:[EBX+491]; kernel32.GetProcessHeap MOV DWORD PTR SS:[EBP-4],EAX PUSH DWORD PTR SS:[EBP+10]; 0x5244 PUSH8 PUSH DWORD PTR SS:[EBP-4]; base address of the heap CALL DWORDPTRDS:[EBX+495]; Allocate the heap OR AX,EAX JE 00C50143 MOV DWORD PTR SS:[EBP-18],EAX

We will step into the first subroutine at 0x00C501FA which is used to get the address of different APIs:

Here is explanation of the code with comments:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 PUSH EBP MOV EBP, ESP SUB ESP,4 CALL00C502BF; Get base address of kernel32.dll MOV DWORD PTR SS:[EBP-4],EAX PUSH EAX; Base address of kernel32.dll CALL00C5030E; Get address of GetProcAddress MOV DWORDPTRDS:[EBX+48D],EAX; Store this address in memory LEA EAX,DWORDPTRDS:[EBX+426]; Pointer to LoadLibrary PUSH EAX PUSH DWORD PTR SS:[EBP-4] CALL DWORDPTRDS:[EBX+48D]; Get Address of LoadLibrary MOV DWORDPTRDS:[EBX+489],EAX LEA EAX,DWORDPTRDS:[EBX+442]; Pointer to HeapAlloc in the image PUSH EAX PUSH DWORD PTR SS:[EBP-4] CALL DWORDPTRDS:[EBX+48D]; GetAddress of HeapAlloc .... MOV DWORDPTRDS:[EBX+491],EAX MOV EAX,1 JMP SHORT00C502BD XOR EAX,EAX LEAVE RETN

It uses the subroutine at 0x00C502BF to get the base address of kernel32.dll by parsing the PEB structure. This is a common method used by shellcodes and various malwares to dynamically find the base address of kernel32.dll:

The next subroutine at address, 00C5030Eis used to get the address of GetProcAddress API which will later be used to get the address of different APIs.

It proceeds to find the address of different APIs using GetProcAddress as shown below:

All these function pointers are stored in memory, as shown below:

Now that it has retrieved the pointers to some APIs, it starts with another decryption routine.

The code of malicious executable is located at memory address, 0x004054D0

First, let’s take a look at this encrypted data:

If you look at this encrypted data, you will observe a pattern. After every DWORD, we have the WORDs 0x0050 or 0x0051 corresponding to ASCII values P. or Q.respectively.

Now, let’s check the decryption routine. It is mentioned below with comments:

1 2 3 4 5 6 7 8 9 10 MOV ESI,DWORD PTR SS:[EBP+C]; points to encrypted data (0x004054d0) MOV EDI,DWORD PTR SS:[EBP-18]; points to the newly allocated heap MOV ECX,DWORD PTR SS:[EBP+10]; size of the encrypted data ADD ESI,2; skip the WORDs 0x0050 or 0x0051 LODS DWORDPTRDS:[ESI]; read the encrypted DWORD into EAx ROL EAX,6; rotate left by 6 XOR EAX,DWORD PTR SS:[EBP+14]; XOR with 0x278C STOS DWORDPTRES:[EDI]; store the result in destination SUB ECX,6; decrement counter by 6 (4 for the DWORD and 2 to skip over the WORDs, 0x0050 or 0x0051) JNZ SHORT00C5004

This subroutine is easy to understand. It reads a DWORD from the encrypted data, rotates it left by 6 bit positions and XORs it with the XOR key 0x278C.

The resulting data is stored at the newly allocated heap at address, 0x0018F520:

As can be seen in the screenshot above, it is the MZ header of the malicious executable. However, it is not completely decrypted.

Unpacking the Custom Packer – Stage 2



Once the first decryption routine has completed, it proceeds to allocate a new heap, which will be used to store the final decrypted malicious executable:

1 2 3 4 5 6 7 8 9 10 PUSH DWORD PTR SS:[EBP+18]; 0x8C00 PUSH 8 PUSH DWORD PTR SS:[EBP-4] CALL DWORDPTRDS:[EBX+495]; Allocate a new Heap OR EAX,EAX JE 00C50143 MOV DWORD PTR SS:[EBP-14],EAX PUSH DWORD PTR SS:[EBP-14]; pointer to newly allocated heap PUSH DWORD PTR SS:[EBP-18]; pointer to first stage of decrypted data CALL 00C5036E; second decryption routine

Let’s check the second decryption routine at address, 0x00C5036E:

Here is an explanation of the code with comments:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 PUSHAD MOV ESI,DWORD PTR SS:[ESP+24]; source points to first stage of decryption MOV EDI,DWORD PTR SS:[ESP+28]; points to newly allocated heap CLD MOV DL,80 XOR EBX,EBX MOVS BYTEPTRES:[EDI],BYTEPTRDS:[ESI]; move one byte from source to destination MOV BL,2 CALL 00C503F1 JNB SHORT00C5037C XOR ECX,ECX CALL 00C503F1 JNB SHORT00C503AB XOR EAX,EAX CALL00C503F1 JNB SHORT00C503BB MOV BL,2 INC ECX MOV AL,10 CALL00C503F1 ADC AL,AL JNB SHORT00C5039D JNZ SHORT00C503E7 STOS BYTEPTRES:[EDI] JMP SHORT00C5037F CALL00C503FD SUB ECX,EBX JNZ SHORT00C503C4 CALL00C503FB JMP SHORT00C503E3 LODS BYTEPTRDS:[ESI]; move the byte from source into EAX SHR EAX,1; shift right the value in EAX by one position JE SHORT00C5040D exit the decryption routine ifthis value inEAX is 0 ADC ECX,ECX JMP SHORT00C503E0 XCHG EAX,ECX

After this subroutine has completed, we will have the decrypted malicious executable at address, 0x00194780

This decrypted malicious executable is located at the address, 0x00194780

Self-Modification of Main Image Header



It is followed by a call to VirtualProtect to modify the protection of the first 0xC000bytes at 0x400000 (ImageBaseAddress) to 0x40 which corresponds to PAGE_EXECUTE_READWRITE as shown below:

The stack parameters are:

Now it sets the first 0xC000 bytes at the ImageBaseAddress to null bytes (0x00). This is done because it will be overwritten with the contents of the decrypted malicious executable.

1 2 3 4 XOR AL,AL; AL stores the nullbyte MOV EDI,DWORD PTR SS:[EBP+8]; EDI points to the ImageBaseAddress, 0x400000 MOV ECX,DWORD PTR SS:[EBP-8]; 0xC000 REP STOS BYTE PTR ES:[EDI]; repeatedly store 0xC000 null bytes at 0x400000

After this, it will copy the sections of the decrypted executable to the ImageBaseAddress one by one (PE header, .text, .rsrc, .reloc and so on):

1 2 PUSH DWORD PTR SS:[EBP-14]; pointer to new decrypted image CALL 00C5016F

Using the below Subroutine, it will get the SizeOfHeaders of the decrypted executable.

1 2 3 4 5 6 7 8 PUSH EBP MOV EBP, ESP MOV EAX,DWORD PTR SS:[EBP+8] MOV EAX,DWORDPTRDS:[EAX+3C] ADD EAX,DWORD PTR SS:[EBP+8]; pointer to PE header of new decrypted image MOV EAX,DWORDPTRDS:[EAX+54]; SizeOfHeaders, 0x400 LEAVE RETN4

It then proceeds to copy the PE header from the decrypted executable to the ImageBaseAddress:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 PUSH EAX; 0x400 PUSH DWORD PTR SS:[EBP-14]; pointer to decrypted image PUSH DWORD PTR SS:[EBP+8]; pointer to base address of image of main module CALL 00C50157 PUSH EBP MOV EBP, ESP PUSH ECX PUSH ESI PUSH EDI MOV ECX,DWORD PTR SS:[EBP+10] MOV EDI,DWORD PTR SS:[EBP+8] MOV ESI,DWORD PTR SS:[EBP+C] REP MOVS BYTE PTR ES:[EDI],BYTE PTR DS:[ESI]; copy 0x400 bytes from decrypted executable to Image Base Address POP EDI POP ESI POP ECX LEAVE RETN0C

It proceeds in this way to copy the .text, .rsrc and .reloc sections one by one to the Image Base Address:

Copy 0x8400 bytes of .text section from the decrypted image to 0x401000 Copy 0x200 bytes of .rsrc section from the decrypted image to 0x40A000 copy 0x200 bytes of .reloc section from the decrypted image to 0x40B000

Decrypted Malicious Executable



It then calls the AddressOfEntryPoint of the malicious executable:

1 2 3 4 MOV EAX,DWORD PTR SS:[EBP-10]; pointer to PE header MOV EAX,DWORDPTRDS:[EAX+28]; address of entry point ADD EAX,DWORD PTR SS:[EBP+8] CALL EAX; 0x408D60

Let’s now trace the code inside the malicious executable:

This section of code will first retrieve the addresses of following APIs:

NtQueryInformationProcess



ZwReadVirtualMemory



ZwMapViewofSection



NtCreateSection



ZwResumeThread



It then proceeds to create a new process called svchost.exe in Suspended State (Process Creation Flag is set to 0x4):

Stack parameters:

Code Injection into New Process



This virus uses an interesting way to inject the malicious code in the newly created process and later resume the execution of it. Unlike most malwares which make use of WriteProcessMemory() to inject the code in the Process Address Space of a remote process, it does not call WriteProcessMemory() at all.

It also helps in bypassing certain security mechanisms where system drivers detect the code injection by monitoring WriteProcessMemory API invocations in user mode.

Once the new process is created, it queries the remote process to retrieve Process Information by calling ZwQueryInformationProcess API as shown below:

The stack parameters are:

The output will be stored at the memory address 0x0012FD9C. It uses this to get the Process Environment Block address of the remote process as shown below:

In this case, PEB of svchost.exe is at the address, 0x7FFDA000

It then proceeds to find the ImageBaseAddress of svchost.exe by reading the value at offset 0x8 in PEB

1 2 3 4 5 6 7 8 9 10 11 12 13 14 MOV DWORD PTR SS:[EBP-AC],EAX MOV EDX,DWORD PTR SS:[EBP-14]; pointer to PEB base address of new process ADD EDX,8; PEB + 8 has the ImageBaseAddress of svchost.exe MOV DWORD PTR SS:[EBP-DC],EDX LEA EAX,DWORD PTR SS:[EBP-9C] PUSH EAX PUSH 4 LEA ECX,DWORD PTR SS:[EBP-8C] PUSH ECX MOV EDX,DWORD PTR SS:[EBP-DC] PUSH EDX MOV EAX,DWORD PTR SS:[EBP-A8] PUSH EAX CALL DWORD PTR SS:[EBP-B4]; ZwReadVirtualMemory

Stack parameters:

It reads 0x4 bytes from the address 0x7FFDA008 in the process address space of the svchost.exe process and stores it at 0x0012FD28 as shown below:

The ImageBaseAddress of svchost.exe is 0x10000000



It then proceeds to create a new section within itself using ZwCreateSection API:

Stack parameters:

The handle of the new section is stored at the address 0x0012FD94:

After this, it calls ZwMapViewOfSection to map the newly created section (handle, 0x150) in itself.

Stack parameters:

The base address of the mapped view of Section is stored at 0x0012FD30:

The address of the mapped view of section is: 0x00A20000. The size of mapped view is 0x7CA0.

It then proceeds to copy 0x7CA0 bytes from 0x004010B0 to the mapped view at 0x00A20000:

1 2 3 4 5 6 7 8 9 10 11 12 13 MOV EDX,DWORD PTR SS:[EBP-7C] ADD EDX,1 MOV DWORD PTR SS:[EBP-7C],EDX MOV EAX,DWORD PTR SS:[EBP-7C] CMP EAX,DWORD PTR SS:[EBP-2C]; check if counter <= 0x7CA0 JNBSHORT Shipment.00408F88 MOV ECX,Shipment.004010B0 ADD ECX,DWORD PTR SS:[EBP-7C] MOV EDX,DWORD PTR SS:[EBP-84] ADD EDX,DWORD PTR SS:[EBP-7C] MOV AL,BYTEPTRDS:[ECX]; read one byte at a time from 0x004010B0 MOV BYTEPTRDS:[EDX],AL; store it in the view JMP SHORT Shipment.00408F60

Once this is done, the mapped view contains the code of malicious subroutine:

It uses another call to ZwMapViewofSection to map its section (that has the code of malicious subroutine) into svchost.exe process:

Stack parameters:

Here, 0x150 is the handle of the section object and 0x154 is the handle of svchost.exe process.

The base address of the newly mapped view will be present at 0x0012FD30:

Our malicious subroutine has been mapped at the address 0x000C0000 in svchost.exe process address space.

In this way, even without using a call to WriteProcessMemory it was able to inject the code of malicious subroutine in process address space of svchost.exe.

It then calls VirtualAlloc to allocate memory in its own Process Address Space:

Stack parameters:

The new memory region is allocated at address, 0x00C60000

Modification of Original Entry Point in Remote Process



It proceeds with a call to ZwReadVirtualMemory to read the PE Header of svchost.exe process and store it at the newly allocated memory region, 0x00C60000

Stack parameters:

Once it has the PE Header of svchost.exe at address, 0x00C60000, it parses that to find the size of Image of svchost.exe process:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 MOV DWORD PTR SS:[EBP-AC],EAX MOV ECX,DWORD PTR SS:[EBP-80] MOV EDX,DWORD PTR SS:[EBP-80] ADD EDX,DWORDPTRDS:[ECX+3C]; EDX points to PE Header of svchost.exe MOV DWORD PTR SS:[EBP-88],EDX MOV EAX,DWORD PTR SS:[EBP-88] MOV ECX,DWORDPTRDS:[EAX+50]; At offset 0x50 in the PE Header we have the SizeOfImage. MOV DWORD PTR SS:[EBP-30],ECX MOV EDX,DWORD PTR SS:[EBP-88] MOV EAX,DWORDPTRDS:[EDX+28]; AddressOfEntry point of svchost.exe MOV DWORD PTR SS:[EBP-B8],EAX LEA ECX,DWORD PTR SS:[EBP-9C] PUSH ECX MOV EDX,DWORD PTR SS:[EBP-30] PUSH EDX MOV EAX,DWORD PTR SS:[EBP-80] PUSH EAX MOV ECX,DWORD PTR SS:[EBP-8C] PUSH ECX MOV EDX,DWORD PTR SS:[EBP-A8] PUSH EDX CALL DWORD PTR SS:[EBP-B4];ntdll.ZwReadVirtualMemory

Stack parameters:

It reads 0x6000 bytes (SizeOfImage of svchost.exe) from the ImageBaseAddress of svchost.exe and stores at 0x00C60000 in its Process Address Space.

The original entry point was located previously and stored in [EBP-88]. The RVA of AddressOfEntryPoint of svchost.exe is 0x2509.

Let’s look at the disassembly of the code at Original Entry Point in svchost.exe at present:

It is important to note here. Most malwares in the recent past used GetThreadContext() and SetThreadContext() to modify the Original Entry Point of the Primary Thread which will be executed in the remote process to trigger the malicious code execution. In this case, it does not use calls to GetThreadContext()and SetThreadContext() APIs to modify the Original Entry Point at all.

It then proceeds to modify the code at original entry point using the code below:

Here is the explanation of the code with comments:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 MOV DWORD PTR SS:[EBP-AC],EAX MOV ECX,DWORD PTR SS:[EBP-80] ADD ECX,DWORD PTR SS:[EBP-B8]; Original Entry Point of svchost.exe MOV BYTE PTR DS:[ECX],90; opcode of NOP MOV EDX,DWORD PTR SS:[EBP-80] ADD EDX,DWORD PTR SS:[EBP-B8] MOV BYTE PTR DS:[EDX+1],68; opcode of PUSH Memory Address MOV EAX,DWORD PTR SS:[EBP-80] ADD EAX,DWORD PTR SS:[EBP-B8] MOV ECX,DWORD PTR SS:[EBP-28] MOV DWORDPTRDS:[EAX+2],ECX; pointer to code of subroutine which was already mapped into new process MOV EDX,DWORD PTR SS:[EBP-80] ADD EDX,DWORD PTR SS:[EBP-B8] MOV BYTE PTR DS:[EDX+6],0C3; opcode of RET MOV DWORD PTR SS:[EBP-7C],0 JMP SHORT Shipment.00409131

After modification, the disassembly of the code at the Original Entry Point looks like shown below:

As can be seen, the OEP is modified so that it jumps to the subroutine at address 0x0C0000 and executes it. 0xC0000 is the location at which the malicious subroutine was injected previously in svchost.exe process.

It then makes another call to ZwCreateSection to create a new section within itself with the section handle, 0xEC.

Then it calls ZwMapViewOfSection and maps this newly created section at the address, 0x00A30000.

Once this is done, it will copy the bytes from the previously modified PE header of svchost.exe to this location.

It then calls ZwMapViewOfSection once again to map the bytes at 0x00A30000 to the ImageBaseAddress of svchost.exe process as shown below:

Stack parameters:

Now, the modified PE header has been written to the process address space of svchost.exe

It then calls ZwResumeThread to resume the execution of primary thread in svchost.exe.

This Primary Thread executes from the Original Entry Point of svchost.exe. Since that was modified previously to redirect the execution to malicious injected subroutine, it proceeds to successfully execute the malicious code within the context of svchost.exe

Debugging the Remote Process



Once it calls ZwResumeThread the execution of malicious subroutine is resumed in the context of svchost.exe process. To be able to debug it we need to modify the Original Entry Point before the code is injected in svchost.exe process.

This is how the code can be patched.

Please note that the memory addresses in the steps below may differ from the analysis done before because this was a new debugging session. The algorithm remains the same.

It calls VirtualAlloc()to allocate a new memory region at 0x00C90000 It calls ZwReadVirtualMemory to read 0x1000 bytes from the svchost.exe process into the newly allocated memory region. It then calls ZwReadVirtualMemory again to read SizeOfImage (0x6000) bytes from svchost.exe process into the newly allocated memory region at 0x00C90000. It then creates a new section within itself by calling ZwCreateSection. It maps the view of the newly created section by calling ZwMapViewOfSection which is mapped at the base address 0x01190000. It then proceeds to modify the Original Entry Point in the newly allocated memory region. After this, it copies 0x6000 bytes from the newly allocated memory region at 0x00C90000 to the mapped view at 0x01190000 We need to patch the bytes in the mapped view which will be mapped to the Original Entry Point in remote process. In our case, it will be the bytes at 0x01192509. At present we have at address, 0x01192509 1 2 3 01192509 90 NOP 0119250A 68 00000C00 PUSH 0C0000 0119250F C3 RETN We will patch with EB FE which is a short relative cyclic jump as shown below: It again calls ZwMapViewOfSection to map the section object to the remote process. It then resumes the thread in remote process by calling ZwResumeThread.The original entry point in remote process will be 0x01002509. Since we patched the bytes before, the code execution will pause at the Original Entry Point. We will now be able to attach our Debugger to svchost.exe process. Let us now patch the bytes at the Original Entry Point in remote process and restore them: After patching, we set a breakpoint at the OEP and run, so that we break at the OEP: Now we can proceed with debugging the malicious subroutine in svchost.exe process.

Conclusion



After reading this article you should be able to unpack malwares which use a similar technique to pack their code and prevent debugging.

It also allows us to see the new ways in which malware authors are trying to bypass the AV and prevent analysis of malwares.

Original Post: http://resources.infosecinstitute.com/deep-dive-into-a-custom-malware-packer/