UPX(1)
โจ UPX(1) โจ
okay bestie, welcome to the upx manual page, section 1 ๐ it's the ultimate packer for eXecutables and it's literally about to become your whole personality. buckle up ๐
๐ฆ NAME ๐ฆ
upx โ compress or expand executable files. that's it, that's the job, no cap ๐
๐ธ SYNOPSIS ๐ธ
upx [ command ] [ options ] filename...
โญ ABSTRACT โญ
The Ultimate Packer for eXecutables
Copyright (c) 1996-2024 Markus Oberhumer, Laszlo Molnar & John Reiser
https://upx.github.io
so here's the tea ๐ซ โ UPX is a portable, extendable, high-performance executable packer for several different executable formats. it gets an excellent compression ratio and offers *very* fast decompression. and the best part? your executables suffer no memory overhead or other drawbacks for most of the supported formats, because of in-place decompression. iconic behaviour honestly ๐
๐ DISCLAIMER ๐
UPX comes with ABSOLUTELY NO WARRANTY; for details see the file COPYING.
please report all problems or suggestions to the authors. thanks!! ๐
๐ฅ SECURITY CONTEXT ๐ฅ
IMPORTANT NOTE: UPX inherits the security context of any files it handles.
this means that packing, unpacking, or even testing or listing a file requires the same security considerations as actually executing the file. yeah. fr fr. ๐ญ
Use UPX on trusted files only! ๐จ
๐ DESCRIPTION ๐
UPX is a versatile executable packer with the following features:
- secure: as UPX is documented Open Source since many years any relevant Security/Antivirus software is able to peek inside UPX compressed apps to verify them ๐
- excellent compression ratio: typically compresses better than Zip, use UPX to decrease the size of your distribution ! ๐ฆ
- very fast decompression: more than 500 MB/sec on any reasonably modern machine โก
- no memory overhead for your compressed executables for most of the supported formats because of in-place decompression ๐ง โจ
- safe: you can list, test and unpack your executables. Also, a checksum of both the compressed and uncompressed file is maintained internally. ๐
- universal: UPX can pack a number of executable formats, including Windows programs and DLLs, macOS apps and Linux executables ๐
- portable: UPX is written in portable endian-neutral C++ ๐ช
- extendable: because of the class layout it's very easy to support new executable formats or add new compression algorithms ๐งฉ
- free: UPX is distributed with full source code under the GNU General Public License v2+, with special exceptions granting the free usage for commercial programs ๐๏ธ
you probably understand now why we call UPX the "ultimate" executable packer. and honestly? we're right. periodt. ๐
๐ COMMANDS ๐
๐ Compress
this is the default operation, eg. upx yourfile.exe will compress the file specified on the command line.
๐ฆ Decompress
all UPX supported file formats can be unpacked using the -d switch, eg. upx -d yourfile.exe will uncompress the file you've just compressed.
โญ Test
the -t command tests the integrity of the compressed and uncompressed data, eg. upx -t yourfile.exe check whether your file can be safely decompressed.
note, that this command doesn't check the whole file, only the part that will be uncompressed during program execution. this means that you should not use this command instead of a virus checker. ๐
๐ธ List
the -l command prints out some information about the compressed files specified on the command line as parameters, eg upx -l yourfile.exe shows the compressed / uncompressed size and the compression ratio of yourfile.exe.
๐ OPTIONS ๐
-qโ be quiet, suppress warnings-q -q(or-qq) โ be very quiet, suppress errors-q -q -q(or-qqq) โ produce no output at all--helpโ prints the help--versionโ print the version of UPX--exactโ when compressing, require to be able to get a byte-identical file after decompression with option-d. [NOTE: this is work in progress and is not supported for all formats yet. If you do care, as a workaround you can compress and then decompress your program a first time - any further compress-decompress steps should then yield byte-identical results as compared to the first decompressed version.] ๐ซ-kโ keep backup files-o fileโ write output tofile
[ ...more docs need to be written... - type upx --help for now ]
๐ง COMPRESSION LEVELS & TUNING ๐ง
UPX offers ten different compression levels from -1 to -9, and --best. the default compression level is -8 for files smaller than 512 KiB, and -7 otherwise.
- Compression levels 1, 2 and 3 are pretty fast. ๐โโ๏ธ
- Compression levels 4, 5 and 6 achieve a good time/ratio performance. โ๏ธ
- Compression levels 7, 8 and 9 favor compression ratio over speed. ๐ข
- Compression level
--bestmay take a long time. โณ
note that compression level --best can be somewhat slow for large files, but you definitely should use it when releasing a final version of your program. like, do it. ๐
Quick info for achieving the best compression ratio:
- Try
upx --brute --no-lzma myfile.exeor evenupx --ultra-brute --no-lzma myfile.exe. ๐ฅ - The option
--lzmaenables LZMA compression, which compresses better but is *significantly slower* at decompression. you probably do not want to use it for large files.
(Note that --lzma is automatically enabled by --all-methods and --brute, use --no-lzma to override.) ๐
- Try if
--overlay=stripworks. ๐ - For win32/pe programs there's
--strip-relocs=0. See notes below. ๐
๐ OVERLAY HANDLING OPTIONS ๐
Info: an "overlay" means auxiliary data attached after the logical end of an executable, and it often contains application specific data (this is a common practice to avoid an extra data file, though it would be better to use resource sections).
UPX handles overlays like many other executable packers do: it simply copies the overlay after the compressed image. this works with some files, but doesn't work with others, depending on how an application actually accesses this overlaid data. ๐คทโโ๏ธ
--overlay=copyโ Copy any extra data attached to the file. [DEFAULT]--overlay=stripโ Strip any overlay from the program instead of copying it. Be warned, this may make the compressed program crash or otherwise unusable. ๐--overlay=skipโ Refuse to compress any program which has an overlay.
๐ ENVIRONMENT VARIABLE ๐
the environment variable UPX can hold a set of default options for UPX. these options are interpreted first and can be overwritten by explicit command line parameters. for example:
for DOS/Windows: set UPX=-9 --compress-icons#0
for sh/ksh/zsh: UPX="-9 --compress-icons=0"; export UPX
for csh/tcsh: setenv UPX "-9 --compress-icons=0"
Under DOS/Windows you must use '#' instead of '=' when setting the environment variable because of a COMMAND.COM limitation.
not all of the options are valid in the environment variable - UPX will tell you. ๐ฃ๏ธ
you can explicitly use the --no-env option to ignore the environment variable.
๐ซถ NOTES FOR THE SUPPORTED EXECUTABLE FORMATS ๐ซถ
๐น๏ธ NOTES FOR ATARI/TOS
this is the executable format used by the Atari ST/TT, a Motorola 68000 based personal computer which was popular in the late '80s. support of this format is only because of nostalgic feelings of one of the authors and serves no practical purpose :-). see https://freemint.github.io for more info. ๐ฅน
packed programs will be byte-identical to the original after uncompression. all debug information will be stripped, though.
extra options available for this executable format:
--all-methodsโ Compress the program several times, using all available compression methods. This may improve the compression ratio in some cases, but usually the default method gives the best results anyway.
๐ง NOTES FOR BVMLINUZ/I386
same as vmlinuz/i386. ๐ซก
๐พ NOTES FOR DOS/COM
obviously UPX won't work with executables that want to read data from themselves (like some commandline utilities that ship with Win95/98/ME). ๐ฌ
compressed programs only work on a 286+.
packed programs will be byte-identical to the original after uncompression.
Maximum uncompressed size: ~65100 bytes.
extra options available for this executable format:
--8086โ Create an executable that works on any 8086 CPU.--all-methodsโ Compress the program several times, using all available compression methods. This may improve the compression ratio in some cases, but usually the default method gives the best results anyway.--all-filtersโ Compress the program several times, using all available preprocessing filters. This may improve the compression ratio in some cases, but usually the default filter gives the best results anyway.
๐ฅ๏ธ NOTES FOR DOS/EXE
dos/exe stands for all "normal" 16-bit DOS executables.
obviously UPX won't work with executables that want to read data from themselves (like some command line utilities that ship with Win95/98/ME). ๐ญ
compressed programs only work on a 286+.
extra options available for this executable format:
--8086โ Create an executable that works on any 8086 CPU.--no-relocโ Use no relocation records in the exe header.--all-methodsโ Compress the program several times, using all available compression methods. This may improve the compression ratio in some cases, but usually the default method gives the best results anyway.
โ๏ธ NOTES FOR DOS/SYS
compressed programs only work on a 286+.
packed programs will be byte-identical to the original after uncompression.
Maximum uncompressed size: ~65350 bytes.
extra options available for this executable format:
--8086โ Create an executable that works on any 8086 CPU.--all-methodsโ Compress the program several times, using all available compression methods. This may improve the compression ratio in some cases, but usually the default method gives the best results anyway.--all-filtersโ Compress the program several times, using all available preprocessing filters. This may improve the compression ratio in some cases, but usually the default filter gives the best results anyway.
๐งต NOTES FOR DJGPP2/COFF
first of all, it is recommended to use UPX *instead* of strip. strip has the very bad habit of replacing your stub with its own (outdated) version. ๐ additionally UPX corrects a bug/feature in strip v2.8.x: it will fix the 4 KiB alignment of the stub.
UPX includes the full functionality of stubify. this means it will automatically stubify your COFF files. use the option --coff to disable this functionality (see below). ๐
UPX automatically handles Allegro packfiles. ๐
The DLM format (a rather exotic shared library extension) is not supported. Sorry bestie, she's just not invited to the party. ๐
Packed programs will be byte-identical to the original after uncompression. All debug information and trailing garbage will be stripped, though. ๐งน
Extra options available for this executable format:
--coffโ Produce COFF output instead of EXE. By default UPX keeps your current stub.--all-methodsโ Compress the program several times, using all available compression methods. This may improve the compression ratio in some cases, but usually the default method gives the best results anyway.--all-filtersโ Compress the program several times, using all available preprocessing filters. This may improve the compression ratio in some cases, but usually the default filter gives the best results anyway.
๐ธ NOTES FOR LINUX [general] ๐ธ
๐ซ Introduction
Linux/386 support in UPX consists of 3 different executable formats, one optimized for ELF executables ("linux/elf386"), one optimized for shell scripts ("linux/sh386"), and one generic format ("linux/386").
We will start with a general discussion first, but please also read the relevant docs for each of the individual formats. ๐
Also, there is special support for bootable kernels โ see the description of the vmlinuz/386 format. ๐ง
๐ฆ General user's overview
Running a compressed executable program trades less space on a permanent'' storage medium</pink> (such as a hard disk, floppy disk, CD-ROM, flash memory, EPROM, etc.) for <purple>more space in one or more temporary'' storage media (such as RAM, swap space, /tmp, etc.). Running a compressed executable also requires some additional CPU cycles to generate the compressed executable in the first place, and to decompress it at each invocation.
How much space is traded? It depends on the executable, but many programs save 30% to 50% of permanent disk space. How much CPU overhead is there? Again, it depends on the executable, but decompression speed generally is at least many megabytes per second, and frequently is limited by the speed of the underlying disk or network I/O.
Depending on the statistics of usage and access, and the relative speeds of CPU, RAM, swap space, /tmp, and file system storage, then invoking and running a compressed executable can be faster than directly running the corresponding uncompressed program. The operating system might perform fewer expensive I/O operations to invoke the compressed program. Paging to or from swap space or /tmp might be faster than paging from the general file system. ``Medium-sized'' programs which access about 1/3 to 1/2 of their stored program bytes can do particularly well with compression. Small programs tend not to benefit as much because the absolute savings is less. Big programs tend not to benefit proportionally because each invocation may use only a small fraction of the program, yet UPX decompresses the entire program before invoking it. But in environments where disk or flash memory storage is limited, then compression may win anyway. ๐
Currently, executables compressed by UPX do not share RAM at runtime in the way that executables mapped from a file system do. As a result, if the same program is run simultaneously by more than one process, then using the compressed version will require more RAM and/or swap space. So, shell programs (bash, csh, etc.) and ``make'' might not be good candidates for compression. ๐ฌ
UPX recognizes three executable formats for Linux: Linux/elf386, Linux/sh386, and Linux/386. Linux/386 is the most generic format; it accommodates any file that can be executed. At runtime, the UPX decompression stub re-creates in /tmp a copy of the original file, and then the copy is (re-)executed with the same arguments. ELF binary executables prefer the Linux/elf386 format by default, because UPX decompresses them directly into RAM, uses only one exec, does not use space in /tmp, and does not use /proc. Shell scripts where the underlying shell accepts a -c'' argument can use the Linux/sh386 format. UPX decompresses the shell script into low memory, then maps the shell and passes the entire text of the script as an argument with a leading -c''.
โจ General benefits:
- UPX can compress all executables, be it AOUT, ELF, libc4, libc5, libc6, Shell/Perl/Python/... scripts, standalone Java
.classbinaries, or whatever... All scripts and programs will work just as before. ๐ - Compressed programs are completely self-contained. No need for any external program.
- UPX keeps your original program untouched. This means that after decompression you will have a byte-identical version, and you can use UPX as a file compressor just like
gzip.
[ Note that UPX maintains a checksum of the file internally, so it is indeed a reliable alternative. ]
- As the stub only uses syscalls and isn't linked against
libcit should run under any Linux configuration that can run ELF binaries. - For the same reason compressed executables should run under FreeBSD and other systems which can run Linux binaries.
[ Please send feedback on this topic ]
๐ญ General drawbacks:
- It is not advisable to compress programs which usually have many instances running (like
shormake) because the common segments of compressed programs won't be shared any longer between different processes. lddandsizewon't show anything useful because all they see is the statically linked stub. Since version0.82the section headers are stripped from the UPX stub andsizedoesn't even recognize the file format. The filepatches/patch-elfcode.hhas a patch to fix this bug insizeand other programs which use GNU BFD.
๐ General notes:
- As UPX leaves your original program untouched it is advantageous to strip it before compression.
- If you compress a script you will lose platform independence โ this could be a problem if you are using NFS mounted disks.
- Compression of
suid,guidandsticky-bitprograms is rejected because of possible security implications. - For the same reason there is no sense in making any compressed program
suid. - Obviously UPX won't work with executables that want to read data from themselves. E.g., this might be a problem for Perl scripts which access their
__DATA__lines. - In case of internal errors the stub will abort with exitcode 127. Typical reasons for this to happen are that the program has somehow been modified after compression. Running
strace -o strace.log compressed_filewill tell you more. ๐
๐ง NOTES FOR LINUX/ELF386 ๐ง
Please read the general Linux description first. โ๏ธ
The linux/elf386 format decompresses directly into RAM, uses only one exec, does not use space in /tmp, and does not use /proc.
Linux/elf386 is automatically selected for Linux ELF executables.
Packed programs will be byte-identical to the original after uncompression.
๐ How it works:
For ELF executables, UPX decompresses directly to memory, simulating the mapping that the operating system kernel uses during exec(), including the PT_INTERP program interpreter (if any). The brk() is set by a special PT_LOAD segment in the compressed executable itself. UPX then wipes the stack clean except for arguments, environment variables, and Elf_auxv entries (this is required by bugs in the startup code of /lib/ld-linux.so as of May 2000), and transfers control to the program interpreter or the e_entry address of the original executable.
The UPX stub is about 1700 bytes long, partly written in assembler and only uses kernel syscalls. It is not linked against any libc.
๐ญ Specific drawbacks:
- For
linux/elf386andlinux/sh386formats, you will be relying on RAM and swap space to hold all of the decompressed program during the lifetime of the process. If you already use most of your swap space, then you may run out. A system that is "out of memory" can become fragile. Many programs do not react gracefully whenmalloc()returns0. With newer Linux kernels, the kernel may decide to kill some processes to regain memory, and you may not like the kernel's choice of which to kill. Running/usr/bin/topis one way to check on the usage of swap space. ๐
Extra options available for this executable format:
(none)
๐ NOTES FOR LINUX/SH386 ๐
Please read the general Linux description first. โ๏ธ
Shell scripts where the underling shell accepts a -c'' argument can use the `Linux/sh386` format. UPX decompresses the shell script into low memory, then maps the shell and passes the entire text of the script as an argument with a leading -c''. It does not use space in /tmp, and does not use /proc.
Linux/sh386 is automatically selected for shell scripts that use a known shell.
Packed programs will be byte-identical to the original after uncompression.
๐ How it works:
For shell script executables (files beginning with "#!/" or "#! /") where the shell is known to accept "-c <command>", UPX decompresses the file into low memory, then maps the shell (and its PT_INTERP), and passes control to the shell with the entire decompressed file as the argument after "-c". Known shells are sh, ash, bash, bsh, csh, ksh, tcsh, pdksh. Restriction: UPX cannot use this method for shell scripts which use the one optional string argument after the shell name in the script (example: "#! /bin/sh option3\n".)
The UPX stub is about 1700 bytes long, partly written in assembler and only uses kernel syscalls. It is not linked against any libc.
๐ญ Specific drawbacks:
- For
linux/elf386andlinux/sh386formats, you will be relying on RAM and swap space to hold all of the decompressed program during the lifetime of the process. If you already use most of your swap space, then you may run out. A system that is "out of memory" can become fragile. Many programs do not react gracefully whenmalloc()returns0. With newer Linux kernels, the kernel may decide to kill some processes to regain memory, and you may not like the kernel's choice of which to kill. Running/usr/bin/topis one way to check on the usage of swap space. ๐
Extra options available for this executable format:
(none)
โญ NOTES FOR LINUX/386 โญ
Please read the general Linux description first. โ๏ธ
The generic linux/386 format decompresses to /tmp and needs /proc file system support. It starts the decompressed program via the execve() syscall. That's the whole vibe.
linux/386 only gets selected if the specialized linux/elf386 and linux/sh386 won't recognize a file. Like, it's the last one picked for dodgeball. ๐
Packed programs will be byte-identical to the original after uncompression. periodt. โจ
How it works ๐
- For files which are not ELF and not a script for a known
-cshell, UPX uses kernelexecve(), which first requires decompressing to a temporary file in the file system. And interestingly โ because of the good memory management of the Linux kernel โ this often does not introduce a noticeable delay, and in fact there will be no disk access at all if you have enough free memory, as the entire process takes places within the file system buffers. iconic behavior tbh. - A compressed executable consists of the UPX stub and an overlay which contains the original program in a compressed form.
- The UPX stub is a statically linked ELF executable and does the following at program startup:
- decompress the overlay to a temporary location in
/tmp - open the temporary file for reading
- try to delete the temporary file and start (
execve) the uncompressed program in/tmpusing/proc/<pid>/fd/Xas attained by step 2) - if that fails, fork off a subprocess to clean up and start the program in
/tmpin the meantime
- decompress the overlay to a temporary location in
- The UPX stub is about 1700 bytes long, partly written in assembler and only uses kernel syscalls. It is not linked against any libc. smol. tiny. a little legend. ๐ง
Specific drawbacks ๐ญ
- You need additional free disk space for the uncompressed program in your
/tmpdirectory. This program is deleted immediately after decompression, but you still need it for the full execution time of the program. - You must have
/procfile system support as the stub wants to open/proc/<pid>/exeand needs/proc/<pid>/fd/X. This also means that you cannot compress programs that are used during the boot sequence before/procis mounted. (not me trying to compress my init scripts ๐) - Utilities like
topwill display numerical values in the process name field. This is because Linux computes the process name from the first argument of the lastexecvesyscall (which is typically something like/proc/<pid>/fd/3). - Because of temporary decompression to disk the decompression speed is not as fast as with the other executable formats. Still, I can see no noticeable delay when starting programs like my ~3 MiB emacs (which is less than 1 MiB when compressed :-).
Extra options available for this executable format:
--force-execveโ Force the use of the generic linux/386 "execve" format, i.e. do not try thelinux/elf386andlinux/sh386formats.
๐ฎ NOTES FOR PS1/EXE ๐
This is the executable format used by the Sony PlayStation (PSone), a MIPS R3000 based gaming console which is popular since the late '90s. Support of this format is very similar to the Atari one, because of nostalgic feelings of one of the authors. ๐ฅน the way that's so real of them.
Packed programs will be byte-identical to the original after uncompression, until further notice.
Maximum uncompressed size: ~1.89 / ~7.60 MiB.
Notes:
- UPX creates as default a suitable executable for CD-Mastering and console transfer. For a CD-Master main executable you could also try the special option
--boot-onlyas described below. It has been reported that upx packed executables are fully compatible with the Sony PlayStation 2 (PS2, PStwo) and Sony PlayStation Portable (PSP) in Sony PlayStation (PSone) emulation mode. ๐ - Normally the packed files use the same memory areas like the uncompressed versions, so they will not override other memory areas while unpacking. If this isn't possible UPX will abort showing a
packed data overlaperror. With the--forceoption UPX will relocate the loading address for the packed file, but this isn't a real problem if it is a single or the main executable.
Extra options available for this executable format:
--all-methodsโ Compress the program several times, using all available compression methods. This may improve the compression ratio in some cases, but usually the default method gives the best results anyway.--8-bitโ Uses 8 bit size compression [default: 32 bit]--8mib-ramโ PSone has 8 MiB ram available [default: 2 MiB]--boot-onlyโ This format is for main exes and CD-Mastering only ! It may slightly improve the compression ratio, decompression routines are faster than default ones. But it cannot be used for console transfer !--no-alignโ This option disables CD mode 2 data sector format alignment. May slightly improves the compression ratio, but the compressed executable will not boot from a CD. Use it for console transfer only !
bestie read those last two twice.--boot-only= CD-Mastering only, no console transfer.--no-align= console transfer only, won't boot from a CD. They do NOT swap. ๐
๐ธ NOTES FOR RTM32/PE and ARM/PE ๐ธ
Same as win32/pe. that's it, that's the note. short and sweet. ๐
โญ NOTES FOR TMT/ADAM โญ
This format is used by the TMT Pascal compiler โ see http://www.tmt.com/ .
Extra options available for this executable format:
--all-methodsโ Compress the program several times, using all available compression methods. This may improve the compression ratio in some cases, but usually the default method gives the best results anyway.--all-filtersโ Compress the program several times, using all available preprocessing filters. This may improve the compression ratio in some cases, but usually the default filter gives the best results anyway.
๐ง NOTES FOR VMLINUZ/386 ๐ง
The vmlinuz/386 and bvmlinuz/386 formats take a gzip-compressed bootable Linux kernel image (vmlinuz, zImage, bzImage), gzip-decompress it and re-compress it with the UPX compression method.
vmlinuz/386 is completely unrelated to the other Linux executable formats, and it does not share any of their drawbacks. no baggage, main character energy, we love that for it. โจ
Notes:
- Be sure that
vmlinuz/386orbvmlinuz/386is displayed during compression โ otherwise a wrong executable format may have been used, and the kernel won't boot. (and then you're just staring at a black screen like ๐ okay.)
Benefits:
- Better compression (but note that the kernel was already compressed, so the improvement is not as large as with other formats). Still, the bytes saved may be essential for special needs like boot disks.
For example, this is what I get for my 2.2.16 kernel:
1589708 vmlinux
641073 bzImage [original]
560755 bzImage.upx [compressed by "upx -9"]
- Much faster decompression at kernel boot time (but kernel decompression speed is not really an issue these days).
Drawbacks:
- (none) ๐ซถ not a single one. flawless. ate and left no crumbs.
Extra options available for this executable format:
--all-methodsโ Compress the program several times, using all available compression methods. This may improve the compression ratio in some cases, but usually the default method gives the best results anyway.--all-filtersโ Compress the program several times, using all available preprocessing filters. This may improve the compression ratio in some cases, but usually the default filter gives the best results anyway.
๐ NOTES FOR WATCOM/LE ๐
UPX has been successfully tested with the following extenders:
- DOS4G
- DOS4GW
- PMODE/W
- DOS32a
- CauseWay
The WDOS/X extender is partly supported (for details see the file bugs BUGS).
DLLs and the LX format are not supported. ๐ซ
Extra options available for this executable format:
--leโ Produce an unbound LE output instead of keeping the current stub.
๐ NOTES FOR WIN32/PE ๐
The PE support in UPX is quite stable now, but probably there are still some incompatibilities with some files. (lowkey relatable.)
Because of the way UPX (and other packers for this format) works, you can see increased memory usage of your compressed files because the whole program is loaded into memory at startup. If you start several instances of huge compressed programs you're wasting memory because the common segments of the program won't get shared across the instances. On the other hand if you're compressing only smaller programs, or running only one instance of larger programs, then this penalty is smaller, but it's still there. ngl it never fully goes away.
If you're running executables from network, then compressed programs will load faster, and require less bandwidth during execution. ๐ slay.
DLLs are supported. But UPX compressed DLLs can not share common data and code when they got used by multiple applications. So compressing msvcrt.dll is a waste of memory, but compressing the dll plugins of a particular application may be a better idea.
Screensavers are supported, with the restriction that the filename must end with .scr (as screensavers are handled slightly different than normal exe files).
UPX compressed PE files have some minor memory overhead (usually in the 10 - 30 KiB range) which can be seen by specifying the -i command line switch during compression.
Extra options available for this executable format:
--compress-exports=0โ Don't compress the export section. Use this if you plan to run the compressed program under Wine.--compress-exports=1โ Compress the export section. [DEFAULT] Compression of the export section can improve the compression ratio quite a bit but may not work with all programs (likewinword.exe). UPX never compresses the export section of a DLL regardless of this option.--compress-icons=0โ Don't compress any icons.--compress-icons=1โ Compress all but the first icon.--compress-icons=2โ Compress all icons which are not in the first icon directory. [DEFAULT]--compress-icons=3โ Compress all icons.--compress-resources=0โ Don't compress any resources at all.
heads up bestie:--compress-exports=1is the default but it's not universal โ some programs (looking at you,winword.exe) just won't have it, and DLL export sections never get compressed no matter which value you pick. ๐
--keep-resource=listโ bestie, this one says hands off to specific resources ๐ . Everything in theliststays uncompressed, and the list members are separated by commas. Each member looks liketype[/name], where type is the resource type โ standard types gotta be written as decimal numbers, but user types can be decimal IDs or strings. The name is the resource's identifier, and it can be a decimal number or a string too. Like, for example:
--keep-resource=2/MYBITMAP,5,6/12345
So in that example UPX won't compress the named bitmap resource "MYBITMAP", it leaves every dialog (5) resource uncompressed, and it won't touch the string table resource with identifier 12345. No notes taken, no changes made ๐ซถ.
--forceโ forces compression even when there's an unexpected value sitting in a header field.
Use with care, okay? This is the "just send it" button ๐ซฃ.
--strip-relocs=0โ don't strip relocation records.--strip-relocs=1โ strip relocation records. [DEFAULT] โจ
This one only does anything on executables with a base address greater or equal to 0x400000. Usually the compressed file gets smaller, but ngl some files may become larger ๐ญ. Also heads up: the resulting file will not work under Windows 3.x (Win32s). And UPX never strips relocations from a DLL regardless of this option โ it's just not doing that, periodt.
--all-methodsโ compresses the program several times, using all available compression methods. This may improve the compression ratio in some cases, but usually the default method gives the best results anyway. Iconic of the default honestly ๐.--all-filtersโ compresses the program several times, using all available preprocessing filters. This may improve the compression ratio in some cases too, but usually the default filter gives the best results anyway. Same energy, fr fr ๐ฆ.
๐ DIAGNOSTICS ๐
Exit status is normally 0. If an error occurs, exit status is 1. If a warning occurs, exit status is 2. So like, 0 = slay, 1 = we have a problem, 2 = something's a little off but we survived ๐.
UPX's diagnostics are intended to be self-explanatory. It literally tells you what's up. iykyk ๐
๐ BUGS ๐
Please report all bugs immediately to the authors. Not later, not "I'll do it tomorrow" โ immediately bestie ๐ซถโจ
๐ AUTHORS ๐
- Markus F.X.J. Oberhumer
<markus@oberhumer.com>http://www.oberhumer.com - Laszlo Molnar
<ezerotven+github@gmail.com> - John F. Reiser
<jreiser@BitWagon.com>
๐ COPYRIGHT ๐
Copyright (C) 1996-2024 Markus Franz Xaver Johannes Oberhumer
Copyright (C) 1996-2024 Laszlo Molnar
Copyright (C) 2000-2024 John F. Reiser
UPX is distributed with full source code under the terms of the GNU General Public License v2+; either under the pure GPLv2+ (see the file COPYING), or (at your option) under the GPLv+2 with special exceptions and restrictions granting the free usage for all binaries including commercial programs (see the file /usr/share/doc/upx-ucl/copyright).
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
You should have received a copy of the UPX License Agreements along with this program; see the file /usr/share/doc/upx-ucl/copyright. If not, visit the UPX home page.
Okay so the all-caps disclaimer is the legal version of "no take-backsies" โ it's giving serious, and it is serious ๐.
And that's a wrap on the whole page, bestie!! ๐ This was upx version 4.2.4, dated 2024-05-09, filed under UPX(1) โ go forth and compress responsibly, mwah ๐
โจ
๐ฆ where this page comes from
- debian trixie: upx-ucl 4.2.4-1.1 ยท GPL-2.0-or-later WITH Special Exception for Compressed Executables
- ubuntu questing: upx-ucl 4.2.4-1.1
- ubuntu resolute: upx-ucl 4.2.4-1.1build1 ยท GPL-2.0-or-later WITH Special Exception for Compressed Executables
- ubuntu stonking: upx-ucl 4.2.4-1.1build1 ยท GPL-2.0-or-later WITH Special Exception for Compressed Executables
- ๐ girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms