When talking about new concepts, its always best to demonstrate them on something everyone is familiar with. In our case that's of-course UPX with which we are fairly familiar. It almost feels like we write one UPX unpacker each week, doesn't it?

Today we are presenting an optimization concept that enables us to unpack everything in a single go. Now, when talking about file unpacking we always unpack everything in one go, but we never unpack both the main executable module and all of its packed dependencies in a single run. Normally, you wold do this by batching through individual files.  But from a speed perspective, the best optimization imaginable comes from unpacking the main module and all of its dependencies at once. Since TitanEngine wasn't really designed to do that out-of-the-box, it needs just a little bit of help to pull it off.

The problem is the existence of multiple relocation tables, and more importantly multiple import tables. Since TitanEngine was designed to unpack files one at the time, we must do some additional coding around these boundaries to achieve our goal. Compared to a traditional TitanEngine dynamic unpacker, the only difference is the need to collect import table data for modules in one place, and use that data for any module that has reached its entry point jump. The UPX is a special case because it always imports packed file dependencies through the import table. This is, of course, a static way of importing libraries but our approach must be flexible enough to cover both dynamic and static importing.

To achieve our goal we have to scan the main module and all loaded libraries and try to find  the appropriate patterns. Once the patterns are found, we set breakpoints and store info about them so we know which module triggered which callback event. Normally we have three callbacks for UPX unpackers (LoadLibrary, GetProcAddress and EP jump) but since we are doing transverse unpacking we need one more: the load library event custom handler, which determines whether the loaded dependencies are packed with UPX by trying to find the neccessary breakpoint patterns. Even though it is impossible to have more than one module loading at a time, we still need to store the import data because the import tables for the main executable and dependencies might overlap if the modules are loaded dynamically. Once stored, the import info for each module is retrieved when it hits its entry point callback. Relocations aren't really a problem since there is just one module loading at a time, so we can use our "snapshot and compare" model, provided that modules load on non-default image bases. This can be done in numerous ways - one of the easiest is to compile the sample files so that they do that by default (which is considered cheating in the unpacking game), alternatively, we can pre-allocate the memory so that the modules have no choice but to pick another base address. For the purpose of this blog we cheated, in a real world application of this approach you mustn't.

In the real world you will hardly ever see this kind of case but if you do, you now know how to get everything in one go. Until next week...

TitanEngine ReversingLabs Corporation

RL!deUPX (package contains the unpacker with source and the samples used)

We can, with a little help from TitanEngine's hooking library. The idea is to use our unpacker as a library which will be injected into the packed file during its execution. Such a library would place hooks inside the packer code, redirecting the control flow to our unpacker wherever data collection or execution handling is needed. Those places are usually spots where the packer processes the import table or relocations, jumps to the original entry point, or just switches execution from one layer to another.

What are the benefits of such an approach? Even though its slightly harder to create and test such unpackers, the most notable benefit of unpacking by hooking is total immunity to various anti-debugging tricks used to detect the unpacking process. The only detection applicable to this unpacking scenario is anti-hooking and memory checksumming. The first is hardly ever used in modern protections due to the large number of false positives it gives, which are triggered by the operating system itself, security software and various window skinning applications. The second one is rarely present, and when it is it only covers specific memory regions that correspond to a single protection layer. In conclusion this method of implementing the unpacking process should result in fewer things to worry about.

Implementing this kind of hooking requires building custom functions to process the hook events. This is necessary to maintain the packed program work flow, and is exactly why we preserve the register state with PUSHAD, and if there is a jump affected by our hook, even EFLAGS with PUSHFD. These ASM instructions are embedded in our C code and with the help of naked pre-processor instruction they become the prologue and epilogue of the function. To apply the hooks we use the DLL_PROCESS_ATTACH event. For example if we were to hook the UPX code which loads libraries the hook code flow would look like this:

Since our hooks are 5 bytes we need to "borrow" as many instructions as we need to insert the hook. In this case we are "borrowing" three instructions. These instructions will be executed right after our inserted function is called. This is done to preserve the packer work flow. As you can see from this diagram we are using hooks instead of breakpoints. Therefore these hooks will be placed on at least three places: when UPX calls LoadLibraryA, GetProcAddress and finally once it jumps to the entry point. The most basic sample UPX unpacker is limited to working on executables that don't import functions by ordinals and use the old jump to entry point method. It's quite limited, but it's enough for a proof-of-concept of our technique.

Debugging this kind of unpacker can be rather tricky. This video shows a quick and easy way to do it:

Since we are creating a hook library unpacker, we also need a loader which will execute the unpacking target and inject the unpacker library in it. This can be done in number of ways but we decided to do it via the debug - detach method. Once both the unpacker hook library and the loader are made, our unpacker is complete. We hope you got the idea on how to use this technique to build your own hooking unpackers from our short blog. Until next week...

TitanEngine ReversingLabs Corporation

upxHooks (package contains the unpacker with source and the samples used)

There are a lot of optimizations one can do with the TitanEngine to make it work even faster then lightning. During the related unpacker execution timing research for our upcoming CARO Workshop talk we measured the impact that certain operations inside the engine itself have on the total unpacking time. We realized that there is significant space for performance improvement in certain unpacking areas which is especially important when we are processing large file volumes. Now, when unpacking files with unpackers built around the TitanEngine you get unpacker execution times quite similar to the sample execution time, except for cases where dynamic link library unpacking requires snapshots to correct the relocation table. in those cases we see a significant unpacking execution time increase. To counter this we can either do memory snapshots to memory or optimize relocation processing and avoid using snapshots at all.

Generally when talking about fixing relocation table we refer to the easy snap-and-compare method. However there is another way of making the unpacked dynamic link library valid for loading on non default base. We can use RelocaterGrabRelocationTableEx function for cases when the packer uses non modified relocation table, defined as it is in the PECOFF document. Relocation data is still compressed and can only be accessed just before the file is relocated, which is why we need a function to inspect the memory and determine the relocation table size. And that is exactly what RelocaterGrabRelocationTableEx does. It determines the size of the relocation table at the provided address and copies it to the engine for later exporting. If we look at the following PackMan code snippet which does the image relocation:

  OR ECX,ECX
  JE L018
  MOV EDI,DWORD PTR DS:[EBX+24]
  JMP L013
L004:
  XOR EAX,EAX
  LODS WORD PTR DS:[ESI]
  OR EAX,EAX
  JE L011
  AND AH,0F
  ADD EAX,DWORD PTR DS:[EBX]
  ADD DWORD PTR DS:[EDX+EAX],ECX
L011:
  CMP ESI,EDI
  JNZ L004
L013:
  MOV EDX,DWORD PTR DS:[EDI]
  LEA ESI,DWORD PTR DS:[EDI+8]
  ADD EDI,DWORD PTR DS:[EDI+4]
  TEST EDX,EDX
  JNZ L011
L018:
  POPAD
 

We can see that the relocation table is stored at EBX+0x24 address. Therefore by reading that memory pointer before the actual relocation occurs we have all the parameters we need to fix the relocation table. Passing that parameter to the RelocaterGrabRelocationTableEx will result in the engine reading the relocation table and estimating its size. Therefore we can just use the pointer we read at the EBX+0x24 address and the return from RelocaterEstimatedSize to correct the PE header for the unpacked file. However RelocaterEstimatedSize doesn't return the accurate size due to the system design. It must be reduced by 8 to be correct for all cases.

Since we are only updating the PE header data we can free the relocation table stored inside the engine with RelocaterCleanup. Once we dump the process relocation table fixing is as easy as updating the PE header fields. By doing the relocation table fixing this way we optimize the speed of execution by a significant percent. No actual data needs to be written to the file on the disk since it is already there and in the correct format. Furthermore you can start the debugging without the previously necessary DLL loading on the address other then default. If you choose to use that optimization as well packer execution time will be shorter since the file might not be relocated at all thus saving CPU cycles. Until next week...

TitanEngine ReversingLabs Corporation

RL!dePackMan (package contains the unpacker with source and the samples used)

Format we have selected is a simple a Debian archive file format called Deb. Debian packages (DEB files) are standard Unix ar archives that include two gzipped, bzipped or lzmaed tar archives: one that holds the control information and another that contains the data. These two files present in the archive are not compressed but instead they are just stored inside the binary package. Each stored item has its own header, which is defined like this:

typedef struct DEB_HEADER{
    char FileName[16];
    char FileTime[12];
    char Reserved0[6];
    char Reserved1[6];
    char Mode[8];
    char ItemSize[10];
    char TerminateQuote;
    char TerminateNewLine;
}DEB_HEADER, *PDEB_HEADER;

Preceding the first header which is used to describe the archive is the magic string "!<arch>\n" which is used to identify the binary package type. Therefore unpacking the DEB archive format is essentially reading the archive header and copying the binary content that follows it to the selected folder. Header for each binary content contains the file name and time information which can be used during the unpacking process to restore the packed item to its pre-packing state. Because this file format doesn't employ any compression by itself unpacking the DEB format only refers to extraction of the stored binary content. That content is additionally packed but with a different file format which commonly uses compression to reduce the size of the packed file on disk.

This is just one of the many uses for TitanEngine outside the area of unpacking and processing portable executable file format. As we have seen unpacking archives with TitanEngine is quite possible as long as there is no compression or content decompression is supported by the engine. Keep an eye out for our blog next week when we unveil our super secret project. Until then...

TitanEngine ReversingLabs Corporation

DEB unpacker (package contains source code, binary unpacker and a sample archive)

In our previous blog we have shown a short video that demonstrates the usage of new LUA SDK. Since then we decided that console unpackers are very boring to we included a new function in the TitanEngine which enables creation of a simple unpacker GUI that makes your script unpackers a little bit more user friendly. With this youtube video we welcome you to 2010. ReversingLabs will be back on Monday with more reverse engineering stories just for you. Catch us next time....

Simply put, regular static unpackers are only used to unpack "simple" crypters which don't compress data in order to decrease the encrypted file size. In contrast, in the case where some data is compressed, unpacking must decompress that data, therefore we call such unpackers static decompressors. Static decompression can be used to unpack  both PE packers and installer formats since similar unpacking logic is used for both.

The Unpacker we are making today will be a static decompressor, since AHPack uses aPLib compression to decrease the file size. Furthermore we are "killing two birds with one stone" since both AHPack and !EPPack are based on the same source code base and can be unpacked the same way. If you open any of the provided samples in OllyDBG you'll see the packed file entry point:

  PUSHAD
  PUSH 00407054		;String: kernel32.dll
  MOV EAX,[KERNEL32.GetModuleHandleA]
  CALL NEAR DWORD PTR DS:[EAX]
  PUSH 004070B3		;String: GlobalAlloc
  PUSH EAX
  MOV EAX,[KERNEL32.GetProcAddress]
  CALL NEAR DWORD PTR DS:[EAX]
  PUSH 3000		;Virtual size of first section
  PUSH 40
  CALL NEAR EAX
  MOV DWORD PTR DS:[4070CA],EAX
  MOV EDI,EAX
  MOV ESI,00401000 	;Virtual offset of first section
  PUSHAD		;aPLib decompression
  CLD
  MOV DL,80
  XOR EBX,EBX
  MOVS BYTE PTR ES:[EDI],BYTE PTR DS:[ESI]
...
  POPAD			;aPLib decompression end
  MOV ECX,2FFC		;copy decompressed data to first section
L002:
  MOV EBX,DWORD PTR DS:[EAX+ECX]
  MOV DWORD PTR DS:[ECX+401000],EBX
  LOOPD L002
 

This first part of the packer code quite clearly shows what the packer does. First it allocates a temporary memory buffer to store decompressed data, then decompresses the content of the first section to it. After the content is decompressed it is written to its original location, which, in this case, is first section's memory. The packer only compresses the first section since all compilers create PE files with a code section as the first file section. Resources, imports, relocations and TLS data isn't compressed, it is just realigned to new physical location after the size of first section decreases. In order to decompress the file we must do the following:

• Decompress the content of the first section
• Move the content of all other sections (including overlay) by the size needed to write decompressed content
• Write decompressed data to first section and correct its physical size
• Fix section data pointers to correctly point to the new section location for the remaining sections

After this we have to fix imports, correct the entry point address, and optionally delete the last section. We have already said the imports are not compressed, but that doesn't mean that this packer doesn't process imports. This code here does exactly that:

  MOV EDX,00400000
  MOV ESI,445C ;Address of first IID
  ADD ESI,EDX
  MOV EAX,DWORD PTR DS:[ESI+C]
  TEST EAX,EAX
  JE 00407277
  ADD EAX,EDX
  MOV EBX,EAX
  PUSH EAX
  MOV EAX,[KERNEL32.GetModuleHandleA]
  CALL NEAR DWORD PTR DS:[EAX]
...
  AND EBX,0FFFFFFF
  PUSH EBX
  PUSH DWORD PTR DS:[4070CE]
  MOV EAX,[KERNEL32.GetProcAddress]
  CALL NEAR DWORD PTR DS:[EAX]
  MOV DWORD PTR DS:[EDI],EAX
  ADD DWORD PTR DS:[4070D2],4
  JMP SHORT 00407218
  ADD ESI,14
  MOV EDX,00400000
  JMP 004071E5
 

You can see that it's very simple code that just goes through the normal import table and fills its content. The data we need from here is address of the first IID, which will be used to find out the size of the import table or the number of IIDs present in the import table. Keep in mind that last IID will be empty, since that is the way import table is described in PECOFF. Since this table is valid we can use these two values to fix it. Simply by setting ImportTableAddress and ImportTableSize values in the PE header, we fix the import table in the unpacked file. Last thing we need to do is read the address of the entry point which can be found here:

  PUSH EDX
  CALL NEAR EAX
  POPAD
  MOV EAX,004012C0 ;Address of entry point
...
  PUSH ECX
  RET
 

Writing an unpacker for AHPack  is fairly complex, since there are a few details to worry about. It provides an interesting challenge for any reverser and it shows the potential of TitanEngine's new static unpacking function. As always unpacker, source code and the samples are included with the blog. Until next week...

TitanEngine ReversingLabs Corporation

RL!deAHPack (package contains unpacker binary, source and samples used)

Proof of this thesis is found at the very beginning of our task. Entry point itself lays on a challenge. Polymorphic decryption is used to decrypt most of the crypter body. Since this code is random we must do something to handle it and all similar cases found in the crypter body.

L000:
  LODS BYTE PTR DS:[ESI]
;
; Totally random decryption code
;
  STOS BYTE PTR ES:[EDI]
  LOOPD L000

Since both start and end patter can be defined with the LODS and STOS instructions code in between can be easily located. But what to do with it? Simple way of handling this would be extraction of this code and dynamic generation of decryption code with the following structure:

; __stdcall function long Decrypt(EAX, ECX)
  PUSH EBP
  MOV EBP,ESP
  MOV EAX,DWORD PTR[EBP+8]
  MOV ECX,DWORD PTR[EBP+C]
;
; Totally random decryption code pasted here
;
  LEAVE
  RET 8

Here ECX and EAX are input variables since they change. EAX is equal to byte pointed by ESI since its loaded with LODS, and ESI at start points to first byte after LOOPD instruction. Decryption size is static and its calculated and stored just before this decryption loop inside the crypter body. Since LOOPD decrements the ECX value it must be handled before every call to our decryption function. Return value of our decryption function is the value of decrypted byte. This is one way of dealing with polymorphic decryption functions and therefore this or similar approach will be used every time we encounter such obstacle while unpacking the crypter. If we were making a dynamic unpacker skipping this polymorphic decryption would be as easy as setting a hardware breakpoint on the first byte after LOOPD and waiting for it to hit.

This first layer of encryption is the most important one since all the data needed for our unpacker is encrypted by it. If you remember when coding dynamic unpacker first logical step is to collect data about imports. Situation is a bit different when it comes to static unpackers. First thing to do is of course decrypt everything that needs decrypting. With the first layer already decrypted we move on to decrypting section content. Following code processes sections:

  MOV EDI,EAX
  ADD EDI,DWORD PTR DS:[EDI+3C]
  MOV ESI,EDI
  ADD ESI,0F8
  XOR EDX,EDX
L005:
  CMP DWORD PTR DS:[ESI],63727372 ;rsrc
  JE L046
  CMP DWORD PTR DS:[ESI],7273722E ;.rsr
  JE L046
  CMP DWORD PTR DS:[ESI],6F6C6572 ;relo
  JE L046
  CMP DWORD PTR DS:[ESI],6C65722E ;.rel
  JE L046
  CMP DWORD PTR DS:[ESI],4379     ;yC
  JE L046
  CMP DWORD PTR DS:[ESI],6164652E ;.eda
  JE L046
  CMP DWORD PTR DS:[ESI],6164722E ;.rda
  JE L046
  CMP DWORD PTR DS:[ESI],6164692E ;.ida
  JE L046
  CMP DWORD PTR DS:[ESI],736C742E ;.tls
  JE L046
  CMP DWORD PTR DS:[ESI+14],0
  JE L046
  CMP DWORD PTR DS:[ESI+10],0
  JE L046
  PUSHAD
  MOV ECX,DWORD PTR DS:[ESI+10]
  OR EBX,EBX
  JNZ L035
  MOV ESI,DWORD PTR DS:[ESI+14]
  ADD ESI,EAX
  CALL 0040748B
  JMP L038
L035:
  MOV ESI,DWORD PTR DS:[ESI+C]
  ADD ESI,EAX
  CALL 0040744E  ;Decrypt content
L038:
  MOV EDX,EBP
  ADD EDX,00402D3E
  LEA EAX,DWORD PTR DS:[EDX]
  PUSH EAX
  RET
  MOV EAX,0
  INT 0D
  POPAD
L046:
  ADD ESI,28
  INC EDX
  CMP DX,WORD PTR DS:[EDI+6]
  JNZ L005
  RET

All sections are processed by names. Every section except the ones named rsrc, idata, edata, rdata, tls and yC is decrypted. That kind of logic must be incorporated in our unpacker aswell. Decryption of content is done with another polymorphic decryption loop. Same procedure as described above can be applied. After that is done all that remains is that we fix imports and correct the entry point.

Now for the imports... Not exactly a hard task once we locate yC's internal data. Scroll down to the end of the crypter code, until you find this:

  PUSH EBP
  MOV EBP,ESP
  PUSH EDI
  MOV EAX,DWORD PTR SS:[EBP+10]
  MOV EDI,DWORD PTR DS:[EAX+9C]
  MOV EDX,EDI
  ADD EDX,crackme_.00403393
  PUSH DWORD PTR DS:[EDX]
  POP DWORD PTR DS:[EAX+B8]
  MOV DWORD PTR DS:[EAX+B4],EDI
  MOV DWORD PTR DS:[EAX+9C],0
  MOV EAX,0
  POP EDI
  LEAVE
  RET

Following this is a simple data structure containing the following:

; DWORD - LoadedBase (default: ImageBase)
; DWORD - OriginalEntryPoint address (RVA)
; DWORD - yC protection options selected (All options: 0x3C)
; DWORD - File checksum (custom algorithm)
; DWORD - Crypter body memory checksum (custom algorithm)
; DWORD - Reserved; Store place for a boolean variable
;
; Simplified IID (Image Import Descriptor)
;
; DWORD - Pointer to name of the first DLL in the IAT (RVA)
; DWORD - Pointer to IAT for the first DLL(RVA)
; DWORD - Reserved; OriginalFirstTrunk
; DWORD - Pointer to name of the second DLL in the IAT (RVA)
; DWORD - Pointer to IAT for the second DLL(RVA)
; DWORD - Reserved; OriginalFirstTrunk
; etc. for all DLLs

As we can see all the data we need is decrypted with the first polymorphic decryption and easily located. What we need from this is to read the location of DLL names and API pointers for every DLL and rebuild IIDs linking this data. Additionally all strings are encrypted so we need to go through the API pointers and decrypt them with the following algorithm:

  PUSH ESI
  PUSH EDI
  MOV ESI,EAX
  MOV EDI,EAX
L004:
  LODS BYTE PTR DS:[ESI]
  ROR AL,4
  STOS BYTE PTR ES:[EDI]
  CMP BYTE PTR DS:[EDI],0
  JNZ L004
  POP EDI
  POP ESI
  RET

Once that is done we have imports sorted and since we know the address of the original entry point we only need to write it to PE header and optionally strip to crypter section to complete the unpacker. Optionally because if crypter is used on programs with TLS table it will be moved to the crypter section and if we don't want to rebuild that as well we can just keep the crypter section.

Writing an unpacker for Yoda's Crypter is a fairly complex task since there are few details to worry about. It provides an interesting challenge for any reverser. As always unpacker, source code and the samples are included with the blog. Until next week...

TitanEngine ReversingLabs Corporation

RL!deY0daCrypter 1.x (package contains unpacker binary, source and samples used)

However this is a "code your own dynamic unpacker" Monday. Today we take a look at nPack a straight forward packer that comes to us from Russia. Since it supports compression of both dynamic link library and executable files it should give us a nice exercise on how to write dynamic unpackers. Shall we?

Entry point of the packed file gives more useful information than we usually see with packers. Take a look.

  CMP DWORD PTR DS:[407E48],0  ;File already decompressed check
  JNZ L003
  JMP L004
L003:
  RET
L004:
  CALL 0040720A
  CALL 0040723C
  MOV EAX,
  SUB EAX,DWORD PTR DS:[407E08]
  MOV DWORD PTR DS:[407E44],EAX
  CALL 0040727A
  CALL 004073FD
  CALL 004078B2
  CALL 00407806
  MOV EAX,DWORD PTR DS:[407E44]
  MOV DWORD PTR DS:[407E48],1   ;Set file already decompressed flag
  ADD DWORD PTR DS:[407E00],EAX ;Add loaded file base to OEP RVA
  PUSH DWORD PTR DS:[407E00]	;Entry point jump
  RET

So, once again we solve the entry point location before the other pieces of the puzzle. Normally the first of our points of interest is import table processing. We find that part of the file by scrolling through the code and looking for the API call combination that utilizes GetProcAddress and LoadLibrary/GetModuleHandle. Since functions can be imported by name or ordinal number instruction TEST which does a logical compare with 0x80000000 is also a big clue on where this code is located. Most packers check for ordinal imports this way and this code part usually stands out on its own identifying the import processing part.

  MOV EBX,DWORD PTR DS:[EDI+C] ;Part I - Loading new library
  ADD EBX,DWORD PTR DS:[407E44]
  PUSH EBX
  CALL LoadLibraryA
...
  TEST EAX,80000000            ;Part II - Is API ordinal?
  JE SHORT 004074A0
  AND EAX,0FFFF
  MOV DWORD PTR SS:[ESP+18],EAX
  MOVZX EAX,AX
  PUSH EAX
  PUSH DWORD PTR SS:[ESP+18]
  CALL GetProcAddress          ;Find function via ordinal
  TEST EAX,EAX
...
  MOV ECX,DWORD PTR DS:[407E44]
  ADD EAX,ECX
  ADD EAX,2
  PUSH EAX
  MOV DWORD PTR SS:[ESP+1C],EAX
  PUSH DWORD PTR SS:[ESP+18]
  CALL GetProcAddress          ;Find function via name
...
  MOV DWORD PTR DS:[ESI],EAX   ;Part III - Write function pointer
  ADD ESI,4
  JMP SHORT 00407469

As we can see this code is segmented inside the function that processes imports. All three parts of this code have their role. First part load the necessary libraries, second one finds the functions inside the loaded libraries and the third writes the found API pointers to the import address table. Three breakpoints are needed in order to collect this data. One at the library loading part and two at function finding part. We need two breakpoints at the function finding part because only one of two GetProcAddress calls gets executed depending on whether the function is imported by ordinal or not. Similarly to this we have the following relocation code:

L000:
  MOVZX EAX,WORD PTR DS:[EBX]
  MOV EBP,EAX
  AND BP,0F000
  CMP EBP,3000
  JNZ L010
  AND EAX,EDI
  ADD EAX,DWORD PTR DS:[ECX]
  ADD EAX,EDX
  ADD DWORD PTR DS:[EAX],ESI
  MOV EDX,DWORD PTR DS:[407E44]
L010:
  MOVZX EAX,WORD PTR DS:[EBX]
  MOV EBP,EAX
  AND BP,0F000
  CMP EBP,1000
  JNZ L022
  AND EAX,EDI
  ADD EAX,DWORD PTR DS:[ECX]
  ADD EAX,EDX
  MOV EDX,ESI
  SHR EDX,10
  ADD WORD PTR DS:[EAX],DX
  MOV EDX,DWORD PTR DS:[407E44]
L022:
  MOVZX EAX,WORD PTR DS:[EBX]
  MOV EBP,EAX
  AND BP,0F000
  CMP EBP,2000
  JNZ L032
  AND EAX,EDI
  ADD EAX,DWORD PTR DS:[ECX]
  ADD EAX,EDX
  ADD WORD PTR DS:[EAX],SI
  MOV EDX,DWORD PTR DS:[407E44]
L032:
  INC EBX
  INC EBX
  DEC DWORD PTR SS:[ESP+10]
  JNZ L000

Yet again this is only the part of a really long code which can be easily identified. Test or compares with value 0x3000 indicates a 32 bit relocation is always a good clue, and if such test is a part of a loop there is a good chance that that code is a part of a relocation to new base function. We make two snapshots that fix relocations with ease. One at the beginning of this function and the other at the end of the same function. Memory to be snapshot is always the entire memory minus the packer section, which is in all cases from virtual address of the first section to virtual address of the last one. Since we already know where the entry point jump is this is the last piece of the puzzle needed to complete our unpacker.

Writing an unpacker for nPack should be an easy task since there are just a few things to look out for. If you had no trouble writing an unpacker for PackMan you shouldn't have a problem with this one. As always unpacker, source code and the samples are included with the blog. Until next week...

TitanEngine ReversingLabs Corporation

RL!denPack (package contains unpacker binary, source and samples used)

  PUSHAD
  CALL L002
L002:
  POP EBX
  LEA EBX,DWORD PTR DS:[EBX-3A]
  ADD DWORD PTR DS:[EBX],EBX

That's is? This code can find on which base loaded module was loaded? It can and here is why. Once the first call and POP EBX execute EBX will be equal to address on which EBX is located. That doesn't get us closer to our loaded base address but next two instructions do. Once LEA executes EBX will be pointing to data inside the same section where the entry point resides. Data at that pointer is 0xFFFF8A30 which is equal to 0x004075D0 - 0x00400000 which is the EBX data minus the default image base. Since math for this is EBX - ImageBase = Delta reversing this would be EBX + Delta = ImageBase. And from this it is simple to figure out that as long as the EBX changes and delta remains the same with this simple math formula we can always calculate the loaded base of the file. Quite a neat trick.

  MOV BYTE PTR DS:[ESI],0E9
  MOV EAX,DWORD PTR DS:[EBX+C] ;0xFFFF9CB7
  MOV DWORD PTR DS:[ESI+1],EAX

What comes next is also interesting and very simple. Code above is a dynamic entry point jump generation. Since at that point ESI always point to the address of the packed entry point data that will be written to that address changes its code content. New instruction to be written instead of fist PUSHAD is a jump to the entry point. Since the relative distance between packed and original entry point will never change there is no need to recalculate this jump and we can always write the same data for that jump regardless of the file loaded base. This works of course because jumps are relative to their location. However in order  to get this location we can do several things:

• Set a breakpoint on the JUMP to packed entry point right after POPAD and single step twice to get to the entry point
• Place a breakpoint at the packed entry point at some point and wait for it to hit and then single step to get to entry point
• Read newly created entry point jump (or data used to write it) and recalculate the entry point jump placing a hardware breakpoint there

Any of the solutions above is a good choice and you can use any of those to place the final entry point breakpoint. But we are getting ahead of ourselves since we still need to work out relocations and imports before we even get to the entry point.

First thing is first, imports. And so this code blob does everything we need to know about import handling in PackMan.

L000:
  ADD EAX,DWORD PTR DS:[EBX]
  PUSH EAX
  CALL NEAR DWORD PTR SS:[EBP] ;GetModuleHandleA
  MOV EDI,DWORD PTR DS:[ESI]
  ADD EDI,DWORD PTR DS:[EBX]
  JMP L017
L006:
  BTR ECX,1F
  JB L011
  ADD ECX,DWORD PTR DS:[EBX]
  INC ECX
  INC ECX
L011:
  PUSH EAX
  PUSH ECX
  PUSH EAX
  CALL NEAR DWORD PTR SS:[EBP+4] ;GetProcAddress
  STOS DWORD PTR ES:[EDI]
  POP EAX
L017:
  MOV ECX,DWORD PTR DS:[EDI]
  TEST ECX,ECX
  JNZ L006
  ADD ESI,10
  LODS DWORD PTR DS:[ESI]
  TEST EAX,EAX
  JNZ L000

One thing to notice is that PackMan uses GetModuleHandleA to get the base of the loaded DLL file. This is because it doesn't load libraries by itself, instead it lets Windows do the loading part and it just fills in the import address table with the correct API pointers. Its easy to place two breakpoints on these function calls and grab the data we need to fill in the imports correctly. Moving on to relocations.

  MOV ECX,DWORD PTR DS:[EBX+2C] ;First snapshot
  OR ECX,ECX
  JE SHORT L015
  MOV EDI,DWORD PTR DS:[EBX+24]
  JMP L014
L005:
  XOR EAX,EAX
  LODS WORD PTR DS:[ESI]
  OR EAX,EAX
  JE L012
  AND AH,0F
  ADD EAX,DWORD PTR DS:[EBX]
  ADD DWORD PTR DS:[EDX+EAX],ECX
L012:
  CMP ESI,EDI
  JNZ L005
L014:
  MOV EDX,DWORD PTR DS:[EDI]
  LEA ESI,DWORD PTR DS:[EDI+8]
  ADD EDI,DWORD PTR DS:[EDI+4]
  TEST EDX,EDX
  JNZ L012
L015:
  POPAD ;Second snapshot

This code blob relocates the file to newly loaded base. As always we can make two snapshots that fix relocations automatically. Question is which memory segment do we snapshot? Since Packman has two memory forms we apply a solution that works for both. Packman can have two or more PE sections with the packer code in the last section. So the memory to snapshot is always the entire memory minus the packer section, which is in all cases from virtual address of the first section to virtual address of the last one. Comparing those two snapshots fixes the relocation table with ease.

Writing an unpacker for PackMan should be an easy task since there are just a few things to look out for. If you had no trouble writing an unpacker for UPX you shouldn't have a problem with this one. As always unpacker, source code and the samples are included with the blog. Until next week...

TitanEngine ReversingLabs Corporation

RL!dePackMan 1.x (package contains unpacker binary, source and samples used)

What is interesting about this unpacker is that we decided to make a static unpacker this time. We decided this because of the bugs in the crypter itself which prevented it from executing on x64 systems. So, in order to work around the crypters bugs today we make a static unpacker for it. This means that our analysis will be focused on different things then when we are creating dynamic unpackers.

First step when building static unpackers for crypters is to check if they have encrypted layers and if so how many. To find out this we just scroll through the code and look for sections of code that look like pure gibberish. Those sections are usually located just after the the decryption loops in-charge of their decryption. There could be several encryption layers following each other but usually for internal packer code decryption only one is used. Luckily for us this crypter doesn't have any. Entry point of the protected file looks like this:

  POP EBX
  AND EBX,FFFFFF00
L002:
  CMP WORD PTR DS:[EBX],5A4D
  JNZ L018
  MOV ESI,EBX
  ADD ESI,DWORD PTR DS:[EBX+3C]
  CMP DWORD PTR DS:[ESI],4550
  JNZ L018
  MOVZX EAX,WORD PTR DS:[ESI+18]
  MOV ECX,EAX
  IMUL EAX,EAX,0BAD
  MUL EAX
  SUB EAX,4B415DAB
  IMUL ECX,ECX,0C0DE
  ADD EAX,ECX
  JNZ L018
  SUB ESP,4
  JNZ 0040711E
L018:
  SUB EBX,100
  JNZ L002
  NOP
  JB SHORT 004070BC

This code is in-charge of locating the base of kernel32.dll. One of the reasons this crypter doesn't work on x64 systems is precisely this code. After it has executed and the kernel32 base has been located crypter will execute this code:

  MOV EAX,DWORD PTR FS:[30]
  TEST EAX,EAX
  MOV ECX,DWORD PTR FS:[20]
  JS L005
  MOVZX ECX,BYTE PTR DS:[EAX+2]
L005:
  JECXZ SHORT protecte.00407138
  POP EAX
  JMP NEAR EAX

Which is the only antidebugging code in the crypter stub. We talked about PEB.BeingDebugged detection last week so you should know that during this code execution ECX should be NULL by the point code executes label L005. But that is of no importance since we are coding a static unpacker. However following code is very important:

L001:
 PUSHAD
 CALL L003
 DB E8
L003:
 ADD DWORD PTR SS:[ESP],5C
 CMP DWORD PTR DS:[EDI],6164652E
 JE L031
 CMP DWORD PTR DS:[EDI],7273722E
 JE L031
 CMP DWORD PTR DS:[EDI],63727372
 JE L031
 CMP DWORD PTR DS:[EDI],7063632E
 JE L031
 CMP DWORD PTR DS:[EDI+14],0
 JE L031
 MOV ESI,EBX
 ADD ESI,DWORD PTR DS:[EDI+C]
 MOV ECX,DWORD PTR DS:[EDI+10]
 MOV EAX,D4497869    ;Variable
 MOV EDX,2F1F0FD2    ;Variable
 TEST ECX,ECX
 JE L031
L021:
 DEC ECX
 JECXZ L031
 XOR BYTE PTR DS:[ECX+ESI],AL
 NEG EAX
 SUB EDX,39E7B8FA    ;Variable
 DEC EAX
 NOT EAX
 ADD EAX,EDX
 ADD EDX,EAX
 JMP L021
L031:
 RET
 POPAD
 ADD EDI,28
 DEC ECX
 JNZ SHORT L001

This is the hearth of the crypter, code in-charge of decrypting the sections. This code also answers the question "Which sections does the crypter encrypt?". If we look at the sequence of compares at the start of this code we will see that only the sections named .rsr, rsrc and .cpp are not decrypted. It is common for crypters to use section names to determine if to decrypt the section or not. As we mentioned earlier the decryption is executed backwards, meaning that the sections are decrypted from the last to the fist byte of the section. However unlike the previous samples we can't just rip this code in order to use it in our unpacker. The reason for that is that some constants which are marked above are not the same for every packed sample. That is why those constants must be read by our unpacker and used as decryption keys for proper section decryption.

After the section data has been decrypted crypter will handle import data. This part is also interesting because of the following:

  MOV ESI,0040445C
  PUSH EBX
  PUSH ESI
  PUSH DWORD PTR DS:[ESI+C]
  ADD DWORD PTR SS:[ESP],EBX
  CALL NEAR DWORD PTR SS:[ESP+14] ;LoadLibraryA call
  POP ESI
  POP EBX
  TEST EAX,EAX
  JE SHORT 004072FE
...
 Decryption:
  ADD DWORD PTR SS:[ESP],3C
  LEA EDI,DWORD PTR DS:[EBX+EAX+2]
  MOV EAX,F4C05BBB             ;Variable
  MOV EDX,8B079C24             ;Variable
  SUB ECX,ECX
L005:
  XOR BYTE PTR DS:[ECX+EDI],AL
  CMP BYTE PTR DS:[ECX+EDI],0
  JE L015
  INC EDX                      ;Random code
  SUB EAX,23BC3756
  ADD EAX,C4A2711F
  ADD EAX,EDX
  ADD EDX,EAX
  INC ECX                      ;Random code
  JMP L005
L015:
  RET
004072FE:
  ADD ESP,0C
  JMP 004012C0 ;OEP jump

At the start of this code ESI is set to 0x0040445C which is the location of the valid import table, more specifically first IID. Following this is a call to LoadLibraryA API which loads all the dependencies until there are no more to load or the dependency isn't found on the system this file is executing on. Because of this there are cases when protected files won't execute correctly. But never the less lets imagine that this will work since all dependencies are present. What is going to happen when LoadLibrary tries to find a NULL dll file, and fails of-course,  is that the jump to 0x004072FE will execute which will align the stack and jump to the original entry point. This is usually the last piece of puzzle but since here import fixing and entry point jumping are overlapping we will handle imports after we have found the entry point location.

While still looking at the code from above we find out that another decryption is performed on every member of the import table. All the strings which are the names of functions to be found in loaded DLLs are decrypted in the decryption sub-routine. Here we also have some variable constants to harden the detection but we also have a randomly generated piece of code that uses them in order to decrypt the string. This code can't be ripped (since its random) and what we are going to do is copy this random piece of code, set input variables to it and call it in order to make it decrypt the data we want. Very simple procedure which is commonly used for such cases. Once all the import strings have been decrypted the file is fully decrypted and all that is left is to set the correct PE header data for entry point and import table.

Writing an unpacker for CryptoCrackPEProtector should be an easy task since there are just a few things to look out for. As always unpacker, source code and the samples are included with the blog. Until next week...

TitanEngine ReversingLabs Corporation

RL!deCryptoCrackPE 0.9x (package contains unpacker binary, source and samples used)