UPX

From Wikipedia, the free encyclopedia

UPX

Ultimate Packer for eXecutables
Latest release:	2.02 / August 13, 2006
Preview release:	2.90 / October 10, 2006
OS:	Windows, Linux, DOS, Atari
Use:	EXE packer, compression
License:	GPL
Website:	upx.sourceforge.net

UPX, the Ultimate Packer for eXecutables, is an open source executable packer (EXE packer) supporting a number of file formats. It is free software, released under the GNU General Public License.

1 Executable compression
2 Obfuscation
3 Disadvantages
4 Formats supported
5 See also
6 External links

[edit] Executable compression

Executable compression is the process of compressing an executable file and prepending a decompression stub, which is responsible for decompressing the executable and initiating execution. The decompression stub is a standalone executable, making compressed and uncompressed executables indistinguishable to the casual user as they are not required to perform any additional steps to start execution.

Software distributors use executable compression for a variety of reasons, primarily to reduce the secondary storage requirements of their software, however as UPX is specifically designed to compress executable code it often achieves better compression ratio than standard data compression facilities such as gzip, zip or bzip2. 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.

[edit] Compression

UPX uses a lossless compression algorithm called UCL, which is a free implementation of the proprietary NRV, Not Really Vanished, algorithm.

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 requires no additional memory.

Next version of UPX (3.0) will use LZMA on 32/64-bit platforms.

[edit] Decompression

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 considered superior, but is not possible on all supported platforms. The rest use extraction to temporary file. This procedure involves additional overhead and other disadvantages, however, allows any executable file format to be packed. The executable is extracted to a temporary location, and then open() is used to obtain a file descriptor.

Once a file descriptor is obtained, the temporary file can be unlink()ed, the stub then uses execve() on the file handle (via /proc) to overwrite the stub with the executable image of the temporary file.

[edit] Disadvantages

The extraction to temporary file method has a number of disadvantages:

special permissions are ignored, such as suid.
argv[0] will not be meaningful.
applications will be unable to share common segments.

[edit] Obfuscation

Disguising the nature or function of an executable is sometimes desirable in order to prevent reverse engineering. UPX can be used to prevent direct disassembly, mask strings literals and modify signatures. Although this does not eliminate the chance of reverse engineering, it can make the process more costly.

Unmodified UPX packing is often detected and unpacked by anti-virus scanners. UPX also has a built-in feature for unpacking unmodified executables packed with itself.

[edit] Disadvantages

Some utilities can no longer identify run-time library dependencies, as only the statically linked extractor stub is visible.
UPX can increase the time applications require to initialize (although it also can decrease the initialization time depending on factors such as application size, hard-disk access speed and in-memory decompression speed).
Some older virus scanners simply report all compressed executables as viruses.
Executables compressed with UPX have a greater impact on system resources. The operating system cannot read their decompressed images on demand from the disk (see virtual memory), like it would with normal, uncompressed executables. Instead, the UPX 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. This also prevents UPX packed executables from reusing resources when an executable is loaded more than once at the same time.