Sample chapter from Reverse Engineering Course

Chapter 3 - Dealing With Protected Binaries

Introduction To Protected Binaries  Packers / Protectors are following two different approaches in compressing executable files.  Packers compresses the executable files to make them smaller; same thing that WinZip does with all kind of files.  The famous packers are: UPX, PECompact, FSG, MeW.

 Protectors do the compression not for shrinking the executable files. They compress them in a special manner to protect their code against reversing and modifications.  Protectors use lots of tricks such as anti-debugging, anti- dumping, anti-disassembling, etc. to make hard the unpacking process.  Most of the times, a protected file are too bigger than a packed file.

 The famous protectors are: Asprotect, Armadillo, ExeCryptor, Themida, etc.

How packers/protectors work A program before packing: Resources Import Directory Import Address Table Code Section PE Header Original Entry Point IAT fills by Windows Loader

 Same program after packing Resources Unpacker Stub Import Directory Import Address Table Code Section PE Header IAT fills by unpacker stub Unpacker stub decompresses the code section Entry Point

Identifying The Packers/Protectors  There are few tools to identify the name of the packers / protectors based on a certain binary signature. They are called: Packer Identifiers.  A packer identifier mostly reads few bytes at entry point of the executable and compares them with its database. If a match is found, it shows the name of the packer, protector, or compiler.

Sample signature of PEiD: [Microsoft Visual C++ 8] signature = E8 ?? ?? E9 ?? ?? FF FF ep_only = true  ?? Means any bytes, and ep_only meansonly search at the entry point  The entry point in Visual C usually is: E8 7A CALL Original.00401F28 E9 36FDFFFF JMP Original E9

Packer Identifiers  PEiD is the most famous and fully featured tool which supports external database and plugins. It has a simple PE header viewer which shows useful information about the file, but it just supports x86 executables  The last version was 0.95 and released on It’s almost a dead project, but some people have created a large external dataset for new packers/protectors.

Packer Identifiers…  RDG Packer Detector is another famous tool with a strong heuristic analyzer, but it doesn’t have an user- friendly GUI. It just support x86 architecture.  The last version is and has been released on Jan It’s alive and being updated frequently.

Packer Identifiers…  ExEinfo PE is a x86-x64 support tool which tries to be similar to PEiD. It has most of the features of PEiD, but it’s not very famous, and has a messy GUI.  The last version is and has been released at the end of It’s alive and being updated frequently.

Packer Identifiers…  Detect It Easy is a new toll which supports both x86 and x64 files. It has most of the features of PEiD. It has a PE Viewer which is able to edit the PE too.  The last version is and has been released on Aug It’s alive and being updated frequently.

The art of unpacking  Unpacking a DLL file has few extra steps comparing with an EXE file.  DLL needs the Relocation Table for moving to different address spaces by Windows loader. So, it should be fixed during the unpacking procedure.  Relox is a tool for fixing relocations by comparing the dump of the DLL with two different ImageBases.

Steps of unpacking an EXE 1.Using a packer identifier to find out the name of the packer/protector. 2.After identifying the packer/protector type, an strategy should be chosen to do the unpacking based on the type of packer/protector. 3.Next step is running the program by a debugger and try to find the original entry point (OEP).

4.Then the process should be dumped by a process dumper. 5.Then, the import address table of the dump file should be fixed by an import fixer such as Import Reconstructor. 6.The final step is re-attaching the overlay (if exists) to the fixed dump.

Steps of unpacking a DLL  The procedure is same as steps 1-5 of an EXE file, but at step 4, after dumping, the ImageBase of dump should be corrected by a PE editor.  The first additional step is loading the DLL into another address space to have the dump at different ImageBase. The Imagebase of new dump should be corrected, like the first dump.

 The second additional step is opening two dumps by Relox to rebuild the Relocation Table and after that, the dump with its Import Table had been fixed at step 5, should be fixed again by Relox.  The last step is same as step 6 of an EXE file; however usually the DLLs don’t have an overlay.