ReversingLabs | Blog

Halloween is a special time of year and it deserves a special blog we might call "writing unpackers in reverse". But wait, writing unpackers in reverse... isn't that packer writing?

We are going to do some TitanEngine coding in order to make it do a complete opposite of what it is meant for. We are going to force our good friend Titan to recreate a crypter we already made an unpacker for. Crypter we are recreating is called LameCrypt. So, what does LameCrypt do?

Its a very very simple crypter designed only to crypt the first executable section by XORing with 0x90. Extremely simple protection mechanism which looks just like this:

  PUSHAD
  PUSHFW
  MOV EBX,4C000
L003:
  XOR BYTE PTR DS:[EBX+401000],90
  DEC EBX
  CMP EBX,-1
  JNZ L003
  POPFW
  POPAD
  MOV EAX,0044CF38
  JMP NEAR EAX

That is the entire crypter code. To recreate it we will copy the binary for the code above and leave the constants blank. After processing that binary data looks like this:

60 66 9C BB 00 00 00 00 80 B3 00 00 00 00 90 4B
83 FB FF 75 F3 66 9D 61 B8 00 00 00 00 FF E0

All the zeroes above will be filled with the following data: virtual size of the first section, virtual offset of the first section and the address of the original entry point. This data, once filled to code above, will be written to the new section. List of actions to perform for this would be:

• Read necessary PE32 data
• Fill the  binary data from above
• Add new section to PE32 file
• Fill written data to it
• Encrypt the first section by XORing it with 0x90
• Update PE header data

Since this is a very simple crypter its code is very short. What makes this a Halloween post is the spooky fact that TE can be forced to create his own worst enemies, crypters! Until next time...

TitanEngine ReversingLabs Corporation

LameCrypter (Package contains binary and source files)

TitanEngine just became Linux friendly! Even though this framework was and is designed only for Microsoft Windows x86/x64 platforms it can work with no problems under Linux with the help of WINE. Small modifications were necessary in order to make this possible but from next release you will be able to execute all ReversingLabs unpackers under Linux distribution of your choice. We have chosen Ubuntu, what is your choice?

This ensures maximum safe environment for live malware analysis for those reverse engineers that make Linux their platform of choice.

Last week was particularity interesting as we did very interesting research related to archive formats. But that's topic for some other week, today we talk about one of the code samples for TitanEngine we mentioned few weeks ago. That code sample is a sample that shows TitanEngine's handler module capabilities implemented as an OllyDBG plugin.

Functionality of the plugin is almost equal to the OllyDBG's handle window but with a slight difference. TitaniumHandles gives you an option to view only open mutex handles and has an ability to close remote handles which can come in handy when analyzing software protections. This plugin is just another sample of multiple ways one can use the functions inside the TitanEngine to ease file analysis.

TitanEngine ReversingLabs Corporation

TitaniumHandles 1.0 (package contains plugin binary and source code)

For today's blog we had to do some minor engine modifications which is always fun. Even though we met these kinds of crypters before it completely slipped our mind that some crypters decrypt data in backward direction. That is why with CryptoCrackPEProtector we introduced new function for data decryption called StaticMemoryDecryptSpecial. Only thing special about it is that you can choose the direction of decryption and in later versions if it proves necessary byte skipping etc.

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)

After one week detour to reversing tool coding field we return to what TitanEngine does best which making unpackers of course. This week we take a peek into what hides in the fog, exeFog.

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)

Remember how last week we decided not to publish some tools? Well it has been brought to our attention that we can publish the binaries and later publish the source with the next TitanEngine update which is very close as it is. That is why this Monday we decided to publish TitaniumOverlay tool.

As stated last week, TitaniumOverlay is a very simple PeID plugin designed to aid in packed binary analysis. Specifically to aid in install format overlay analysis. Being that most install formats store interesting information inside overlay tool that can extract, copy, remove and add overlay can come in handy. Tool itself also informs the user about location and the size of the overlay so that you can go to that location with your favorite hex editor and inspect or manipulate the data.

Don't get confused by the empty selected file field in the plugin's main window. That field is reserved only for adding data to overlay or moving overlay from one PE file to another. So depending on the action you want to perform you either select a PE file (in case you are moving overlay from one PE file to another) or a binary file if you are appending data as an overlay to PE file.

This plugin makes use of TitanEngine overlay functions and its full source will be available with the next TitanEngine release.

Download TitaniumOverlay PeID plugin