Executable compression

Executable compression is any means of compressing an executable file and combining the compressed data with the decompression code it needs into a single executable.

Running a compressed executable essentially unpacks the original executable code, then transfers control to it. The effect is the same as if the original uncompressed executable had been run, so compressed and uncompressed executables are indistinguishable to the casual user.

A compressed executable is one variety of self-extracting archive, where compressed data is packaged along with the relevant decompression code in an executable file. It is often possible to decompress a compressed executable without executing it (two such programs are CUP386 and UNP).

Most packed executables decompress directly into the memory and need no free file system space to start. However, some decompressor stubs are known to write the uncompressed executable to the file system in order to start it.

Advantages and disadvantages

Software distributors use executable compression for a variety of reasons, primarily to reduce the secondary storage requirements of their software; as executable compressors are specifically designed to compress executable code, they often achieve better compression ratio than standard data compression facilities such as gzip, zip or bzip2 Fact|date=November 2007. This allows software distributors to stay within the constraints of their chosen distribution media (such as CD-ROM, DVD-ROM, or Floppy disk), or to reduce the time and bandwidth customers require to access software distributed via the Internet.

Executable compression is also frequently used to deter reverse engineering or to obfuscate the contents of the executable (for example, to hide the presence of malware from antivirus scanners) by proprietary methods of compression and/or added encryption. Executable compression can be used to prevent direct disassembly, mask string literals and modify signatures. Although this does not eliminate the chance of reverse engineering, it can make the process more costly.

A compressed executable requires less storage space in the file system, thus less time to transfer data from the file system into memory. On the other hand, it requires some time to decompress the data before execution begins. However, the speed of various storage media has not kept up with average processor speeds, so the storage is very often the bottleneck. Thus the compressed executable will load faster on most common systems. On modern desktop computers, this is rarely noticeable unless the executable is unusually big, so loading speed is not a primary reason for or against compressing an executable.

On operating systems which read executable images on demand from the disk (see virtual memory), compressed executables make this process less efficient. The decompressor stub allocates a block of memory to hold the decompressed data, which stays allocated as long as the executable stays loaded, whether it is used or not, competing for memory resources with other applications all along. If the operating system uses a swap file, the decompressed data has to be written to it to free up the memory instead of simply discarding unused data blocks and reloading them from the executable image if needed again. This is usually not noticeable, but it becomes a problem when an executable is loaded more than once at the same time—the operating system cannot reuse data blocks it has already loaded, the data has to be decompressed into a new memory block, and will be swapped out independently if not used. The additional storage and time requirements mean that it has to be weighed carefully whether to compress executables which are typically run more than once at the same time.

Another disadvantage is that some utilities can no longer identify run-time library dependencies, as only the statically linked extractor stub is visible.

Also, some older virus scanners simply report all compressed executables as viruses because the decompressor stubs share some characteristics with those. Most modern virus scanners can unpack several different executable compression layers to check the actual executable inside, but some popular anti-virus and anti-malware scanners have had troubles with false alarms on compressed executables.

Executable compression used to be more popular when computers were limited to the storage capacity of floppy disks and small hard drives; it allowed the computer to store more software in the same amount of space, without the hassle of having to manually unpack an archive file every time the user wanted to use the software. However, executable compression has become less popular because of increased storage capacity on computers.

Executable compression has often been taken to extremes by the demoscene, and some compressors, such as MuCruncher, kkrunchy and 624, have been specifically designed for use in size-restricted demos. An extreme example is [http://www.crinkler.net Crinkler] , which has been created for 4096 byte intros, and is unable to compress much larger executables because of the compression method used and its memory consumption.

List of packers

For Portable Executable (Windows) files:
* [http://www.pelock.com .netshrink]
* ASPack
* CExe
* exe32pack
* eXPressor
* [http://programmerstools.org/node/50 FSG]
* MEW – development stopped
* NeoLite
* NsPack – .NET
* PECompact
* PEPack
* [http://www.pelock.com PELock]
* PKLite32
* PEtite
* RLPack
* Shrinker32
* Upack – Freeware
* UPX – free software
* WWPack
* PESpin
* BeRoEXEPacker
* [http://madebits.com/netz/ .NETZ] – .NET

For DOS executables only:
* apack
* diet
* lzexe – First widely publicly used executable compressor for microcomputers.
* pklite
* UPX
* wwpack

For ELF files:
* gzexe
* UPX

See also

* Data compression
* Disk compression
* Executable
* Kolmogorov complexity
* UPX
* Self extracting archive

References