Reverse Engineering Stack Exchange is a question and answer site for researchers and developers who explore the principles of a system through analysis of its structure, function, and operation. It only takes a minute to sign up.
Sign up to join this community
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 ?
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.
extra packer code is executed
the original code is rewritten
These graphics might help as further reference.
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 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.
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.
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 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.
