%~~~~~~~~~~~~~~~~~~~~~~~~%
|H4sIAAAAAAACA3P3dLOwTOxh|
|YGF4zsBg7tHJMApGwYgE////|
|V/zJwsjF8I9BB8QH5QkGjhYG|
|xj/MD'              gULH|
|JrY'                BbVi|
|Tlx|   Y4NgmoOxWoxH4yL5d|
|VDR|   oTseHh8f6WK359lQU|
|qJy\              \YJOGt|
|xhN5I\              \dlr|
|qoJvnIznRDXvHjPWZ   |SY7|
|Lz31nKtYPklkV0F6w   |AKr|
|1E17                ,Vk5|
|afng              ,hp63R|
|VsvNzy8u9qpU670lon11hvnS|
|KNWuSS+vrvNf3HV05beU0NXB|
|p71kJQQYrAFt8kQCpwMAAA==|
%~~~~~~~~~~~~~~~~~~~~~~~~%
  D  E  C  O  D  E  M  E

We are pretty sure that "S" stands for Sophos not Superman. Now, the first thing that comes to mind when you look at the "picture" is that the data around the "S" is important. And if we look at the last two letters we see the base64 trademark signature. Which means that all that data is an encoded message or a file. To decode it, we must strip that "S" to form a proper base64 data chain. Once done, the data looks like this:

H4sIAAAAAAACA3P3dLOwTOxhYGF4zsBg7tHJMApGwYgE////V/zJwsj
F8I9BB8QH5QkGjhYGxj/MDgULHJrYBbViTlxY4NgmoOxWoxH4yL5dVD
RoTseHh8f6WK359lQUqJyYJOGtxhN5IdlrqoJvnIznRDXvHjPWZSY7L
z31nKtYPklkV0F6wAKr1E17Vk5afnghp63RVsvNzy8u9qpU670lon11
hvnSKNWuSS+vrvNf3HV05beU0NXBp71kJQQYrAFt8kQCpwMAAA==

That data must be reverted to either text or binary to continue. First, we tried  an online base64 decoder but it returns a very strange string. So then, we decoded the data to a binary file and opened that with a hex editor, where we see the well known 0x1F 0x8B signature, which indicates that the decoded data is in fact a GZIP file. Now, we know GZip files may or may not store a file name, so when we decompress the packed data we do another hex data inspection to discover that the decompressed file is a GIF file. It's an image showing us this: Not quite readable, but once you zoom in on it, and lower-case it, it points to: http://www.sophos.com/anz/sofarsogood.html which holds the last piece of the puzzle.

Sadly last piece of the puzzle has nothing to do with file analysis whatsoever. Its a crypto challenge requiring you to play with letter substitution crypto algorithms. And this isn't something we are really interested in. You are however more than welcome to fiddle with it if you like. For some help on solving it check this out. Until next week...

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)

As we have seen in our previous blog on this subject tools that provide this kind of protection are very often coded with major design flaws which enable us with quick and painless ways to work around the password protection. However today's password protection option doesn't have such flaws. And that is why we need to find an optimal way to quickly and accurately recover the password. Can it be done in this case?

Quick analysis of the protected file shows us these interesting pieces of code:

  PUSH ECX
  PUSH ECX
  PUSH 40
  PUSH 0D
  PUSH DWORD PTR SS:[EBP+20]
  CALL NEAR DWORD PTR DS:[EDI+402923]
  POP ESI
  CALL L025        ;Calculate the hash for input string
  CMP EAX,F492C2C1 ;Correct password hash
  MOV EAX,0
  JNZ L015
...
L025:              ;Slow hashing algorithm
  XOR EAX,EAX      ;Hash initialization
  PUSH ECX
  PUSH ESI         ;ESI holds the password pointer
  PUSH EDX
  XOR EDX,EDX      ;Reason why it executes 0xFFFF times
  DEC ESI          ;for every letter
L031:
  INC ESI
  XOR AH,BYTE PTR DS:[ESI]
L033:
  XOR AL,DL
  ADD EAX,434F4445 ;Constant
  MOV CL,AL
  ROR EAX,CL
  XOR EAX,55AA5A5A ;Constant
  DEC DX
  JNZ L033
  CMP BYTE PTR DS:[ESI],0
  JNZ L031
  POP EDX
  POP ESI
  POP ECX
  RET

Now just by looking at this piece of code we see that the author of the program thought of many things when it comes to protected file's security. Why? Algorithm in charge of hashing the string is really slow because it executes 0xFFFF times for every letter of the password. If it wasn't for this bruteforcing  this algorithm would be nice and quick. But before we go for that extreme we should always check for possible shortcuts that can enable us to skip the password necessity.

Since we already know that password hash must be 0xF492C2C1 lets see if the memory content decryption has a weakness.

  PUSHAD
  MOV EDI,EAX
  MOV ESI,EDX
  MOV EAX,48415348 ;Hash initialization
  XOR AL,BYTE PTR DS:[ESI]
  CALL GetPasswordHash
  MOV EBX,EAX
  XOR AH,BYTE PTR DS:[ESI]
  CALL GetPasswordHash
  SHR ECX,2
  MOV EDX,ECX
L011:              ;Decrypt first section
  XOR DWORD PTR DS:[EDI],EAX
  MOV CL,AL
  ADD EDI,4
  ROL EBX,CL
  XOR EAX,EBX      ;Keys for decryption: EAX and EBX
  MOV CL,BH
  ROR EAX,CL
  ADD EBX,EAX
  DEC EDX
  JNZ L011
  POPAD
  RET

Here is what happens here. Just before the program decrypts the first section it initializes two 32bit decryption keys. Both keys are initialized from the password string, more accurately the keys are password hashes. Second key is calculated fist. This key which is stored in EBX register is a direct product of password hash for algorithm initialize value 0x48415348. However this value isn't a constant, it is modified by XORing with the fist letter of the password. That is why the already calculated  password hash we have 0xF492C2C1 isn't enough to break this algorithm. Fist key is calculated last and its value is stored in EAX register. Hashing algorithm for this key calculation is a direct result of first key stored in EBX XORed with the fist letter of the password. Only by having the state of both keys for decryption beginning we can correctly decrypt the file. However we put it the password seems like a must for decryption. We are going to return to shortcuts a bit later, lets discuss the bruteforce option first.

Building a bruteforcer for this algorithm is quite easy. We just need to go through the all possible combinations that a password can take in order to recover the 'lost' password. However that proves to be a much harder task then it sounds. Building the bruteforcer isn't a problem but the time its needed for recovering a simple password which is only 4 characters in length is very long. Take a look at this program log to see a basic log which shows the "slowness" of this algorithm. It seems that author of the program saw bruteforce as a potential risk and made it slow on purpose. But this isn't the only problem. Our bruteforce test shows that passwords collide meaning the multiple passwords have the same hash. Any of these passwords will unlock the program but it won't be decrypted correctly and therefore it will crash. Here is how the bruteforce program log looks like:

Correct password for this sample is: "ap0x" but to recover it bruteforcer needed approximately 4 minutes. And as you can see in log file time needed to go through every four character password combination (a..z + A..Z + 0..9) is more then 2 hours. And even that isn't a guarantee because you have check every password since the protection doesn't have an additional validation to check if the code decrypted correctly. Since that is way too slow for any practical use on longer passwords we return to finding the algorithm weakness.

But is there a weakness? If we look at the decryption algorithm we see that both EAX and EBX keys are needed for decryption to work correctly. However only one key, EAX, is used to decrypt data by XORing the file memory content. Therefore recovering the password would be easy if we knew the first four bytes unencrypted. Which we don't... Could it help if we need the unencrypted value of any random sequence of bytes in the file? It might but that would mean that we would also need one more information for that location, the value of ECX register because it is used to modify successive decryption keys. Is there just such a sequence of bytes? Sure, at the end of file whose sections are aligned to PE.FileAlignment (and its a must for this protection) we have at least 12 bytes which are zeroes. Last four bytes in that case are equal to EAX decryption key at that time, which leaves EBX and CL as unknowns. Four bytes before that we have the same story. In order to recover EAX, EBX and CL we must do the following:

• Reverse the decryption algorithm so it decrypts the memory backwards
• Bruteforce that decryption to recover EAX, EBX and CL values
• Make sure that those key values are correct since algorithm does collide
• Decrypt the file backwards using the correct keys

Since keys are 32bit and we already know the value of one of those at one point we can bruteforce keys between 0x00000000 and 0xFFFFFFFF in order to get the missing EBX and CL values. That is much faster then trying to bruteforce the infinity of possible passwords. Reversed algorithm can be seen in the source code under the function named PEPDecryptFile.

Writing a bruteforcer for PEPasswordEncryptor is a nice reversing exercise especially when algorithm shortcut inspection is involved. As always binary, source code and the samples are included with the blog. Until next week...

PEBrute
(package contains unpacker binary, source and samples used)

Now it theory only one password should be able to unlock such protected application and allow its execution without any possibility of removing the protection without the correct password. Well that's the theory behind such tools but they themselves have a weakness too because there still must be a way for the application to check the validity of the inputted password. So regardless of the protection executable password protection solution must do one of the following:

• Compare passwords or password hashes to determine whether or not to execute the file
• Use the inputted password for code decryption and verify the decrypted content by hashing

So, not a lot of options to choose from. First model would be the least secure since no content is encrypted and the second most secure requiring password bruteforce to be removed. Lets see what we are dealing with in LCCrypto's case. Entry point of the protected file looks like this:

  MOV EAX,DWORD PTR SS:[ESP] ;Pointer to ExitProcess API
  AND EAX,FFFF0000
L002:
  CMP DWORD PTR DS:[EAX],905A4D
  JE L006
  SUB EAX,1000
  JMP L002
L006:
  PUSH EBP

Very simple way to get the kernel base most commonly used in malware which could flag this sample as malicious by some anti-virus vendors. Following this we have:

  MOV EBP,EAX
  ADD EAX,DWORD PTR DS:[EAX+3C]
  MOV EDI,DWORD PTR DS:[EAX+78]
  ADD EDI,EBP
  MOV ESI,DWORD PTR DS:[EDI+20]
  ADD ESI,EBP
  XOR EDX,EDX
L007:
  MOV EAX,DWORD PTR DS:[ESI]
  ADD EAX,EBP
  CMP DWORD PTR DS:[EAX],50746547
  JNZ L025
  CMP DWORD PTR DS:[EAX+4],41636F72
  JNZ L025
  CMP DWORD PTR DS:[EAX+8],65726464
  JNZ L025
  CMP WORD PTR DS:[EAX+C],7373
  JNZ L025
  MOV EAX,DWORD PTR DS:[EDI+24]
  ADD EAX,EBP
  MOVZX EBX,WORD PTR DS:[EAX+EDX*2]
  MOV EAX,DWORD PTR DS:[EDI+1C]
  ADD EAX,EBP
  MOV EAX,DWORD PTR DS:[EAX+EBX*4]
  ADD EAX,EBP
  MOV DWORD PTR DS:[407408],EAX
L025:
  ADD ESI,4
  INC EDX
  CMP EDX,DWORD PTR DS:[EDI+18]
  JNZ L007

Another code which is used to locate GetProcAddress API pointer. This is crucial since that API and already located kernel base are all that this protection needs to locate all other needed APIs to create password input dialog and process it. Code that creates the window and its elements is located just after the code locates all needed APIs. Code that is of interest is here:

  PUSH DWORD PTR DS:[407004]
  CALL NEAR DWORD PTR DS:[407410] ;FreeLibrary
  PUSH DWORD PTR DS:[407000]
  CALL NEAR DWORD PTR DS:[407410] ;FreeLibrary
  CMP BYTE PTR DS:[407881],0
  JE L008
  MOV EAX,004012C0 ;OriginalEntryPoint
  JMP NEAR EAX
L008:
  PUSH 0
  CALL NEAR DWORD PTR DS:[407414] ;ExitProcess

This is what happens when the window message processing loop just above this exits, and that will happen when the created window associated with that message processing loop terminates by window closing. Which means that if the byte at address 0x00407881 isn't set to zero LCCrypto will pass the code execution to original entry point which in this case isn't encrypted at all. Patching this compare in memory and closing the window would do the trick. Removing the protection completely would be as easy as setting the entry point address in the PE header to 0x000012C0. Normally our work would be done here, but lets dig in just a little bit more.

  PUSH 10
  PUSH 0040776E
  PUSH 64
  PUSH DWORD PTR SS:[EBP+8]
  CALL NEAR DWORD PTR DS:[407460] ;GetDlgItemTextA
  CALL 00407FF9 ;Calculate CRC32
  LEA EBX,DWORD PTR DS:[40776E]
  CALL 00408021 ;Update CRC32
  CMP DWORD PTR DS:[40775E],EAX ;Compare password CRC32
; DS:[0040775E]=0E1A88EF
  SETE BYTE PTR DS:[407881] ;Set the correct password switch

This code bit here processes the inputted password. As we can see from the code above inputted password is hashed with CRC32 and that value is compared with the value 0x0E1A88EF, and that means that hash for the password must be 0x0E1A88EF for protection to pass the control to original code. Now, leaving alone the fact that we can patch the file, think about what we can do to legitimately start the application. Bruteforce the hash? What about make a string that has the same one?

CRC32 algorithm collides which means that we can create such a string. Without going into coding a program that can do that we use a PeID plugin called CRC32 made by Gelios on a simple text file containing only the string "pwd". After the file's CRC32 has been set to 0x0E1A88EF our string "pwd" becomes "pwd€va" which is a string with the CRC32 hash we need. Entering such string into program will fool it into thinking that is the original password making LCCrypto execute the file normally.

We didn't do any coding today because it wasn't necessary. However we did investigate the security of one executable password protection and saw all the flaws its has. Next time we return to this topic we will do some coding in order to make a bruteforce engine that will recover the password used to protect the file. Until next time...

Download protected sample

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)

Being a relatively simple shell modifier it must be classified as a protector. I know that most of you wold disagree because this shell modifier is a simple one but it has all the characteristics of an protector so we have no choice but to call it one. What does it have? It compresses the PE file with aplib algorithm, encrypts the file, processes the import table and makes use of simple anti debugging features. Maybe advanced crypter or just a packer?

Can't wait to have some fun? Me neither. Lets load up some samples and make them sing our tune.

Entry point looks like there is a loader decryption going on but its all an optical illusion. Take a closer look at:

  PUSH ECX
L001:
  MOVZX ECX,CL
  ROR ESP,80
  LEA ECX,DWORD PTR DS:[ECX]
  NOP
  PUSH EBX
  JB L009
  JNS L009
  ADD EBX,0
L009:
  POP EBX
  CMP SI,6C
  CLC
  DEC ECX
  INC ECX
  STC
  CLD
  CMC
  LOOPD L001

It doesn't do anything except execute 0xFF times trying to confuse us. Or possibly break an emulator or two? Never the less we trace some more until we find first and the only stub decryption code.

  MOV EBX,00406E57
  MOV ECX,3C8
  MOV AL,0A0
L003:
  XOR BYTE PTR DS:[EBX+ECX],AL
  MOV AL,BYTE PTR DS:[EBX+ECX]
  LOOPD L003

We simply place a hardware breakpoint on execution for the next "call" instruction and hit run. After this has been executed we see that our "call" was indeed a CALL but after it has been decrypted it lead to a more plausible location. What comes next is an interesting approach to an old anti debugging trick. Here we have to pay close attention to what is going on:

  XOR ECX,ECX
  ADD ECX,10
  MOV EBX,77FFFFFF
  MOV EAX,DWORD PTR FS:[EBX+88000019] ;TEB
  MOV EAX,DWORD PTR DS:[EAX+ECX*2+10] ;PEB
  MOVZX EAX,BYTE PTR DS:[EAX+2] ;BeingDebugged
  NOT EAX
  AND EAX,1
  MOV EBX,EAX
  PUSH 0C3FBF6
  CALL L011
L011:
  SUB DWORD PTR SS:[ESP],33
  MOV ESI,ESP
  ADD ESI,4
  JMP NEAR ESI ;Crash the debugger (safely)

This is a simple PEB.BeingDebugged trick but if you trace the code and your debugger isn't hidden from this you will end up executing JMP ESI which leads to IDIV BL instruction. Why is this bad? Because if the program is being debugged processor will need to divide AL with BL which would be fine if they weren't set to NULL. In math we can handle such cases but processor doen't know how to do this and generates an exception which can't be passed making the target terminates itself. To skip this we can either hide our debugger with OllyDBG plugins or manually set EAX to NULL after the BeingDebugged line.

  PUSH EAX
  LEA EDX,DWORD PTR SS:[EBP+1000]
  PUSH EAX
  PUSH EDX
  CALL 00407173 ; decompress aplib data
  ADD ESP,8
  MOV EAX,DWORD PTR SS:[ESP]
  MOV ECX,EDI
  DEC ECX
  MOV EDX,EAX
  PUSH ESI
  LEA ESI,DWORD PTR SS:[EBP+1000]
L012:
  MOV AL,BYTE PTR DS:[EDX+ECX] ; write decompressed data
  MOV BYTE PTR DS:[ESI+ECX],AL
  LOOPD L012

Further tracing leads us to this point where exeFog decompresses the main section and writes it to its original location. Following this is a code which frees up temporary memory and creates a unique mutex which ensure that only one copy of the protected file is running at the same time. This is an option set in exeFog before the file was protected, but that doesn't have an impact on what we are doing. However next code does:

  MOV EBX,0040445C
  MOV ECX,3C
  MOV AL,1B
L003:
  XOR BYTE PTR DS:[EBX+ECX],AL
  LOOPD L003

What is interesting about this code is that it only decrypts a small piece of memory, and that piece of memory is the exact size of three IIDs. After the code is decrypted we take a look at the decrypted memory and find out that imports are  at their original location and that only the IIDs were encrypted meaning that we can just skip the import processing in our unpacker and read the data from the decryptor above in order to set the import table address and size. But for exercise purposes we decided to use our importer module and make this a full dynamic unpacker with the full use of importer module. Code that exeFog uses to process the import table is located just below this decryptor and you can easily analyze it to figure out where to set the breakpoints.

Which only leaves the last piece of the puzzle, and that is always... How does it jump to entry point (and is it protected)?

  PUSH 12C0 ;Entry point relative virtual address
  TEST EAX,EAX
  PUSH EBX
  PUSH EDI
  PUSH EAX
  ADD SI,0
  POP EAX
  POP EDI
  POP EBX
  NOP
  SUB DL,0
  ADD DWORD PTR SS:[ESP],EBP
  RET ; Jump to OEP

Just after the code for import filling exeFog store the code above which is in-charge of jumping to the entry point. As you can see the PUSH instruction hold the relative virtual address of the entry point, and once the last RET instruction is executed exeFog passes control to the original entry point and continues the execution of protected file.

Writing an unpacker for exeFog 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!deExeFog (package contains unpacker binary, source and samples used)

We open our known formats list, place our hand over the eyes and pray that our next pick wont be an epic fail... And the pick is... PeX 0.99. Nice and easy, it should be fun to do. Gentleman, start your debuggers.

Once we start the analysis we find that the entry point has a nice message for us telling us that the sample is packed with PeX. How nice of bart^xt, the author of the packer. This can be used as a part of the signature for this format. After some tracing we find this code:

  ADD ESP,4 ; [EntryPoint + 0x254]
  POP EDX
  POP ESI
  PUSH CS
  PUSH ESI
  RETF

Which once executed leads us to level two of the packer. Formats who use multiple packing levels usually use them to process PE format specifics, such import table processing and file memory protection. In this case packer shell uses this level to fill and protect the import table. So by some more tracing we find:

  CALL NEAR EAX ; kernel32.LoadLibraryA [Level2 + 0xF0]
  TEST EAX,EAX
  JE Level2 + 0x3BF

Simple call the LoadLibraryA API call to load all needed libraries. Data we need is located as a pointer to string in EBX register which holds the name of DLL to be loaded. Some more tracing leads us to this point in code:

  ADD ESP,4 ; [Level2 + 0x1DF]
  AND EBX,7FFFFFFF
  PUSH EBX
  PUSH DWORD PTR SS:[EBP+402A18]
  CALL +0x01	;Redirected GetProcAddress call

This is a call to GetProcAddress API which locates the functions inside the previously loaded DLL file. Parameters we need from here are EBX which is either API ordinal number or a pointer to string which is the name of the function to be found in loaded DLL, and EDI which holds the pointer to IAT. More specifically the place where the API pointer will be written. Normally that would be it for import fixing but PeX has a simple redirection code we must disable before continuing the unpacking process. That code is located here:

  LEA ECX,DWORD PTR SS:[EBP+4025CB] ; [Level2 + 0x299]
  ADD EBX,DWORD PTR DS:[ECX]
  CMP DWORD PTR DS:[ECX],0B13
  JNB OverCodeThatProtectsTheImportTable
  PUSH EBX

By simple patching we change JNB jump from above to JMP and ensure that import table protection code isn't executed. Last thing we have to find is the entry point location and set a breakpoint to dump and fix the file on it. We look a little bit down the code and find this:

  PUSH 4012BF ; [Level2 + 0x396]
  JMP L003
  ???
L003:
  POP EAX
  INC EAX
  PUSH EAX
  RET

Code that will be written to packed entry point and used as a redirection to original entry point. We read this address (0x004012BF) and add one to it to get the original entry point address. Breakpoint we chose to set is a hardware breakpoint on execution, but we could have used a normal breakpoint as well since code at that address has been unpacked and written just before level switching. Once that breakpoint is hit our unpacker will finalize the unpacking in the well known manner.

Since we were (and are) low on Delphi samples, this weeks unpacker was written for that programming language. Also note that all bugs that affected the three candidates for Monday blog were fixed and will be published very soon with the next TitanEngine release. In the mean time keep checking back at our blog and forums for more info about the continuous TitanEngine development.

TitanEngine ReversingLabs Corporation

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

The reason we chose to do MEW (again) is that in its version 5 it is a simple crypter which can be used as a perfect example on how to write static unpackers for these kind of crypters. That kind would be the kind that doesn't do anything to imports but only encrypts the executable code section. Next time we revisit static unpackers we will be talking about such cases. We are going to leave that aside for now because this Monday is all about simple and fast unpacker writing. Start your timers we will do in under 10 minutes.

Minute 1 - 2:

We load our sample into Olly and see the entire MEW5 code at the entry point.

  MOV ESI,0040005B
  LODS DWORD PTR DS:[ESI]
  XCHG EAX,ECX
  LODS DWORD PTR DS:[ESI]
  XCHG EAX,EBX
  PUSH EBX
  LODS DWORD PTR DS:[ESI]
  XCHG EAX,ESI
  PUSH ESI
  POP EDI
L010:
  LODS BYTE PTR DS:[ESI]
  ROL AL,29
  ADD AL,BA
  ROR AL,50
  STOS BYTE PTR ES:[EDI]
  LOOPD L010
  RET

Yes, that it. The whole code. So what does it do? First it loads a pointer to all internal information into ESI register. We follow ESI in the hex dump to find that there are 3 DWORDs that have the data necessary for unpacking. First DWORD is 0x3000 which is the size of the first section, second DWORD is 0x004012c0 which is the address of the original entry point and third DWORD is 0x00401000 which is the virtual address of the first section. Code following this loads 0x3000 bytes one by one and decrypts them with a custom decryption algorithm. Here instruction sequence ROL, ADD and ROR is used to decrypt data.

Minute 3 - 4:

We make a copy of existing TitanEngine SDK sample for DEF and use that as a template for our unpacker. We are making a Delphi unpacker since,... well since TitanEngine is low on Delphi samples and this is a nice and quick exercise.

Minute 5 - 9:

We code the unpacker. First we need to read the ESI pointer and read the data from the file. Once we make that we convert third DWORD to physical address inside mapped file and we also convert the original entry point address to relative one. Simple call to StaticMemoryDecryptEx makes sure that our StaticCallBack decrypts the data by executing this custom decryption algorithm. Lastly we add the code to store the new entry point to PE32 header and we're done.

Minute 9:47 - 10:

We run the compiled unpacker to test if it works... Success!

TitanEngine ReversingLabs Corporation

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