|This article relies too much on references to primary sources. (February 2015) (Learn how and when to remove this template message)|
|Initial release||May 26, 1998|
3.93 / January 29, 2017
|Written in||C++, Assembly|
|Operating system||Microsoft Windows, Linux, macOS, DOS, Atari|
|Platform||i386, MIPS, AMD64, ARM, PowerPC, m68k|
|License||GPL with exception for compressed executables|
UCL has been designed to be simple enough that a decompressor can be implemented in just a few hundred bytes of code. UCL requires no additional memory to be allocated for decompression, a considerable advantage that means that a UPX packed executable usually requires no additional memory.
UPX (since 2.90 beta) can use LZMA on most platforms; however, this is disabled by default for 16-bit due to slow decompression speed on older computers (use
--lzma to force it on).
UPX supports two mechanisms for decompression: an in-place technique and extraction to temporary file.
The in-place technique, which decompresses the executable into memory, is not possible on all supported platforms. The rest use extraction to temporary file. This procedure involves additional overhead and other disadvantages; however, it allows any executable file format to be packed.
The extraction to temporary file method has several disadvantages:
- Special permissions are ignored, such as suid.
argvwill not be meaningful.
- Multiple running instances of the executable are unable to share common segments.
Unmodified UPX packing is often detected and unpacked by antivirus software scanners. UPX also has a built-in feature for unpacking unmodified executables packed with itself. The default license for the existing stubs explicitly forbids modification that prevent manual unpacking. Most antivirus products will raise an alarm when UPX header is detected.
- DOS/COM (including some binary images[nb 1][nb 2])[nb 3]
- DOS/EXE[nb 3]
- DOS/SYS[nb 3]
- Linux/i386 a.out
- Linux/ELF on i386, x86-64, ARM, PowerPC
- Linux/kernel on i386, x86-64 and ARM
- Mach-O/ppc32, Mach-O/i386 (even produced by Google Go since 3.09)
- rtm32/PE (as generated by Borland C/Pascal compilers)
- tmt/adam (as generated by the TMT Pascal compiler)
- Watcom/LE (DOS4G, PMODE/W, DOS32A and CauseWay)
- Windows/PE EXE files containing native x86 (32-Bit) code
- Windows/PE EXE files containing native AMD64 (64-Bit) code – still experimental
- The facility to compress DOS .COM-style files can be utilized also to compress other binary executable files. Some FreeDOS and EDR-DOS kernel files are known to be UPX-compressible this way.
- The facility to compress DOS .COM-style files can be utilized also to compress non-executable binary data files, if the driver/application using these files has been enhanced to detect UPX-compressed files and jump to the decompressor embedded in the file. FreeDOS is known to utilize this for .CPX files, UPX-compressed .CPI font files.
- For the DOS targets, UPX supports a special option -8086 in order to force the embedded decompressor to become compatible with 8088/8086 processors, so that the compressed files can be executed and decompressed even on the earliest PCs running DOS.
- Marak, Victor (2015). Windows Malware Analysis Essentials. Packt Publishing. p. 188. ISBN 978-1-78528-151-8. Retrieved November 22, 2015.
Packers such as Ultimate Packer for Executables (UPX) are more of executable compressors as size reduction is the primary goal, not obfuscation, which can be a byproduct ...
- Blunden, Bill (2013). The Rootkit Arsenal (Second ed.). Jones & Bartlett Learning. pp. 353–355. ISBN 978-1-4496-2636-5. Retrieved November 22, 2015.
One of the most prolific executable packers is UPX (the Ultimate Packer for executables). Not only does it handle dozens of different executable formats, but also its source code is available online.