I know the basic principle of a packer. Basically, it is a small routine launched at the beginning of the program that decompress the actual program and jump to it once achieved.

Yet, it seems that there are quite a lot of variations around this principles. I recently learned about "virtualized packers" or "on-the-fly packers", and I might miss a lot. So, can somebody define what a basic packer is and then explain what are the different types that can be encountered ?

  • Hi @perror, Could you give me some related meterials about "on-the-fly packers"...? I searched in Google but haven't found anything interesting. Thank you! – lllllllllllll Mar 26 '14 at 17:38
  • From the name "on-the-fly packers", it should be quite similar to VM packer.....but I am not sure – lllllllllllll Mar 26 '14 at 17:39
up vote 17 down vote accepted

Generic definition

Binary packers alter the original binary data, and restore it (more or less) before execution.

Their different names depend more on their characteristic: it's difficult to clearly distinguish, as just putting an anti-debug and a Xor loop would make a packer also a protector and a cryptor.

types

extension

extra packer code is executed

  • compressor: reduce original data's size
    • common: aPLib (FSG, , LZMA, NRV (UPX)
    • others: JCALG1, BriefLZ, LZMAT
  • protector: makes reverse engineering harder
    • countermeasures:
      • anti-debugging: IsDebuggerPresent, ...
      • anti-virtualization: detect VmWare, ...
      • anti-dumping: erase header in memory...
      • anti tampering, via checksums
        • common: rolling checksum, CRC32, md5, sha1, adler, md4
        • others: Tiger, Whirlpool, md4, adler
  • cryptor: crypts original data
    • common: bitwise operators (XOR/ROL/...), LCG, RC4, Tea
    • others: DES, AES, Blowfish, Trivium, IDEA, ElGamal

transformation

the original code is rewritten

  • virtualizer: turns original code into virtual code with embedded virtual machine
  • mutater: alters code — same instruction set and architecture, but modified:
    • reflowing
    • oligomorphism

extra features

  • bundler: file dropping, with API hooking (to make a multi-file program run as single file)

These graphics might help as further reference.

  • I'm not sure now if I should have turned it into a community wiki straight from the beginning - let me know your opinion. – Ange Apr 15 '13 at 12:54
  • Hard to say. The classification of question vs wiki is very subjective. I'd say do whichever you feel most comfortable with. It could survive as either in my opinion. – dyasta Apr 15 '13 at 16:26

Definition

We'll define a packer as an executable compressor.

Packers reduce the physical size of an executable by compressing it. A decompression stub is usually then attached, parasitically, to the executable. At runtime, the decompression stub expands the original application and transfers control to the original entry point.

Packers exist for almost all modern platforms. There are two fundamental types of packers:

  • In-Place (In Memory)
  • Write To Disk

In-Place packers do what is termed an in-place decompression, in which the decompressed code and data ends up at the same location it was loaded at. The decryption stub attached to these compressed executables transfer control to the original application entry point at runtime, after decompression is complete.

Write to Disk packers have a decryption stub (or entire module) that, at runtime, write the decompressed application out to the file system, or a block of memory, then transfer control to the original application via execution of the application's code via normal API calls.

Uses

The original intention of executable compressors was to reduce storage requirements (size on disk), back when disk space was at a premium. They can also lower the network bandwidth footprint for transmitted compressed executables, at least when the network traffic would not otherwise be compressed.

These days, there is no premium on disk space, so their use is less common. They are most often used as part of a protection system against reverse engineering. Abuse is also, sadly, common.

Abuse

Some packers are abused by malware authors in an attempt to hide malware from scanners. Most scanners can scan 'inside' (decompress) packed executables. Ironically, use of packers on malware is often counter-productive as it makes the malware appear suspicious and thus makes it subject to deeper levels of analysis.

Additional Features

Additional features such as protection from reverse engineering can be added to the packer, making the packer also a protector. The process of compression is itself a form of obfuscation and abstraction that inherently serves as some protection.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.