'packed'에 해당되는 글 2건

  1. 2008.12.04 Manual Unpacking of UPX Packed PE File by CEOinIRVINE
  2. 2008.11.23 Manually Unpacking a Morphine-Packed DLL with OllyDbg by CEOinIRVINE 1
Manual Unpacking of UPX Packed PE File

 
 
Introduction
Here is a short tutorial on unpacking the UPX packed binary file. UPX is a free, portable, executable packer for several different executable formats. It achieves an excellent compression ratio and offers very fast decompression.

To follow this tutorial you need to download latest UPX packer from UPX website and then pack any of the PE (windows executable) file with it.

 
Unpacking Steps
Before we begin with unpacking exercise, lets try to understand the working of UPX. When you pack any executable with UPX, all existing sections of that file are compressed and appended with new UPX code which decompresses entire packed sections during run time. During the execution of UPX packed binary file, following steps take place...

  • First the current register status is saved through PUSHAD instruction
  • Next all packed sections are unpacked.
  • Resolve the import table of original executable file.
  • Once the job is done, restore the register status via POPAD instruction
  • Finally jump to Original Entry point (OEP)
 
 
Unpacking UPX
Manual unpacking process involves following steps
  • Finding OEP of the program.
  • Dumping the memory image of the binary when the program reaches OEP.
  • Fixing the import table
I am using the generic approach so that you will be able to unpack the executable which is packed with any version of UPX. Here I am using the OllyDbg to unpack the PE file. Although you can use any debugger, OllyDbg is one of the best ring 3 debugger for reverse engineering.

That is all you needed to know before the start. Lets get into some action. Load the UPX packed binary file into the OllyDbg and start tracing the binary, until you encounter a PUSHAD instruction. Usually this is the first instruction or it will be present in the first few instructions based on the UPX version that you have used to pack the PE file. Now put the breakpoint on POPAD instruction. So when we reach POPAD instruction, all the sections will be unpacked and all imports will be resolved. After POPAD instruction, it will jump to OEP.

There are many ways to set the breakpoint at the PUSHAD instruction. When you are at this instruction, you can put the hardware read breakpoint at ESP-4 address. If you have command bar plugin installed then you can just type 'hr esp-4' to set this breakpoint. Other way is to find the POPAD (opcode 61) instruction in the code and set the breakpoint for yourself. You can just scroll down in OllyDbg from the current instruction till you find all zeroes, then just few instructions above the start of zeroes you will find the POPAD instruction. Now you can directly set breakpoint on POPAD instruction.

Once you have set the breakpoint, press F9 and you will break on the instruction which is immediately after POPAD or on POPAD instruction based on which method you have used. Now start tracing with F7 and soon you will encounter a instruction which will jump to OEP that is somewhere in the unpacked code section.

Now you have found the OEP. Note down this address somewhere. Next task is to dump the entire binary image from memory. This can be done using OllyDmp plugin which comes with OllyDbg. Now launch this plugin and dump the entire binary file to the disk using default options. It will automatically fix the import table for you so there is no need to explicitly fix it. That's it and you are done with unpacking the UPX packed file.
 
 
 
Fixing Import Table
For most of the advanced packers, OllyDmp will not be able to fix the import table. In such a case, following method will be helpful. Here, we will be using the ImpREC tool which is more advanced tool for fixing import table.

When you are at the OEP of the program, just dump the memory image of binary file using Ollydmp without asking it to fix the import table. Next launch the ImpREC tool and select the process that you are currently debugging. Then in the ImpREC, enter the OEP (enter only RVA, not a complete address) and click on 'IAT Autosearch' button to automatically search for import table. Then click on 'Get Imports' to retrieve all the imported functions. You will see all the import functions listed under their respective DLL names. If you find any import function which is invalid (marked as valid : No) then remove it by right clicking on it and then from the popup menu, press on 'Delete Thunks'. Now once the import functions are identified, click on Fix Dump button in ImpREC and then select the previously dumped file.

Once you have dumped the image from memory and fixed the import table, you can verify it by executing that application.
 
 
UPX Unpacked...!
That's all, you have successfully unpacked the UPX packed executable file. Its great job though its the simplest packer without any anti debugging features.

As you move on, you will see more and more challenging protectors. Hope you have enjoyed your first unpacking lesson as I did years back..!
 
 
References
    1. UPX: Ultimate Packer for Executables.  
    2. OllyDbg: Popular Ring 3 Debugger.     
    3. ImpREC: Import Reconstruction for PE files  
 
 
See Also
  Writing PESpin plugin for ImpREC. 
  Faster way to enumerate process heaps. 
  Finding the reference count of DLL. 
 
Posted by CEOinIRVINE
l

Manually Unpacking a Morphine-Packed DLL with OllyDbg

Tools Required: OllyDbg, Stud_PE, UltraEdit or any suitable hexeditor
Skill Level: Beginner

Unpacking executables in OllyDbg is usually pretty straight-forward, but sometimes, we come across a DLL that is packed, which can affect how we approach the problem. Due to the way OllyDbg uses the loaddll.exe wrapper to analyze DLLs, the DLL's initialization code will run before we hit our startup breakpoint, allowing the code to perform debugger detection or any other nasty tricks before we get a chance to stop it.

This tutorial gives a step-by-step illustrated guide to unpacking a Morphine-packed DLL using OllyDbg. In this case, our target is a piece of malware identified by Kaspersky Anti-Virus as "Trojan-Proxy.Win32.Agent.jz". RDG packer detector tells us that it is packed by Morphine 2.7.

RDG Packer Detector

If we load the file as-is, OllyDbg will detect that it is a DLL file, and prompt us to use LOADDLL.EXE to analyze it.

LOADDLL.EXE

This is not what we want, so we close this out. Before we load this bug into Olly, we are going to make a small change, to make Olly think that our target is a standalone executable instead of a DLL. We do this by using Stud_PE to locate the "Characteristics" field of the PE header. There is a single bit that we want to toggle in the byte at 0x117. We can do this by changing the value 0x21 to 0x01. Save the file, and now we can load it into OllyDbg as if it were an EXE.

Stud_PE Characteristics (DLL)

Stud_PE Characteristics (EXE)

Now when we load the file into Olly, we are taken to the ModuleEntryPoint, and can begin our unpacking.

OllyDbg at ModuleEntryPoint

When a morphine-packed DLL runs, it will unpack the original file and then copy it to memory allocated by VirtualAlloc. All we need to do in order to dump the original file is to interrupt this process and dump the memory before it is loaded and executed. We can do this by finding the VirtualAlloc function (use CTRL-G to go to a memory location by address or by exported name) and setting a breakpoint on it.

Locate VirtualAlloc

Some packers may use anti-debugging tricks or check the first few bytes of the imported functions to insure that they do not have software breakpoints set. In this case however, there are no tricks, and we can simply set our breakpoint at the start of the VirtualAlloc subroutine, and run the code by pressing F9.

Breakpoint at VirtualAlloc

Once we come to the breakpoint, the original code is unpacked and ready to be copied. We can locate the code in memory by going to the OllyDbg memory map window and right-clicking on the first section after the PE header, and selecting "Dump". This opens a window with our dump in "Disassemble" mode. Right-click on the window and choose "Hex->Hex/ASCII (16 Bytes)" and you'll see the hexdump as shown below.

Hexdump of memory

Scroll through the output and find the PE header, starting with the familiar bytes "MZ" followed by the usual "This program must run under Win32" verbage. If this is present, it means our unpack worked, and we can dump the memory by right-clicking on the dump window and selecting "Backup->Save data to file".

Save memory dump to file

At this point all we need to do with the memory dump is delete the bytes preceding our PE header, and truncate the file at the proper length. I usually use Linux for my low-level file manipulation, but since I know most of you reading this tutorial are working on Windows, I'll show the process using the UltraEdit-32 hex editor.

First, open the memory dump file in UltraEdit and locate the MZ bytes indicating the start of the PE header. Note the offset into the file, in this case, 0x4969 hex, in decimal, 18793.

UltraEdit viewing PE header

Go to the start of the file, select the first byte, right-click and choose Edit->Hex Insert/Delete or hit CTRL-D. In the dialog that pops up, choose "Delete" and enter the number of bytes to delete up to the PE header start.

Delete prefix bytes

Now all we have to do is truncate the file at the correct location. (It won't hurt anything in terms of functionality if you skip this step; the file will just be larger than it needs to be.) Save the file in UltraEdit, then open the saved file in Stud_PE. Look at the "Sections" tab, and note the RawSize and RawOffset fields of the last section of the file. Add them together, and that tells you the overall raw size of the original file. In this case, 0x25800 + 0x3800, which equals 0x29000.

Finding the original file length in Stud_PE

Go back to UltraEdit, and select the byte at offset 0x29000. Hit CTRL-D to bring up the delete bytes dialog again, and now enter a sufficient number of bytes to truncate the rest of the file.

Truncating the file in UltraEdit

We now have a copy the original DLL as it was before being packed by Morphine. We can verify its integrity by loading it into Stud_PE and checking that all of the components of the file have sane values and that the import table actually shows imports from various system DLLs, which would not have been shown in its packed state. The export table should now also show any exported functions in the DLL.

Unpacked!

'Hacking' 카테고리의 다른 글

Overview of U.S. Federal Laws  (0) 2008.11.26
Google Chrome MetaCharacter URI Obfuscation  (0) 2008.11.26
Dynamic-Link Library Creation  (0) 2008.11.21
Comercial Vulnerability Alerts  (0) 2008.11.21
Investigation of Vulnerabilities  (0) 2008.11.21
Posted by CEOinIRVINE
l