Professional Documents
Culture Documents
Upx
Upx
*
*
*
*
*
*
*
*
*
*
rtm32/pe
tmt/adam
vmlinuz/386
[bootable Linux kernel]
vmlinux/386
watcom/le (supporting DOS4G, PMODE/W, DOS32a and CauseWay)
win32/pe (exe and dll)
arm/pe (exe and dll)
linux/elfamd64
linux/elfppc32
mach/elfppc32
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.
Quick info for achieving the best compression ratio:
*
--overlay=strip
--overlay=skip
ENVIRONMENT
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:
for sh/ksh/zsh:
for csh/tcsh:
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 http://www.freemint.de 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
--all-methods
--all-filters
--no-reloc
--all-methods
--all-methods
--all-filters
--all-methods
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 .class
binaries, 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 libc it
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 `sh' or `make') because the common segments of
compressed programs won't be shared any longer between different
processes.
- `ldd' and `size' won't show anything useful because all they
see is the statically linked stub. Since version 0.82 the section
headers are stripped from the UPX stub and `size' doesn't even
recognize the file format. The file patches/patch-elfcode.h has a
patch to fix this bug in `size' and 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.
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/elf386 and linux/sh386 formats, 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 when
malloc() returns 0. 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/top is 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.
Linux/386 is only selected if the specialized linux/elf386 and
linux/sh386 won't recognize a file.
Packed programs will be byte-identical to the original after
uncompression.
How it works:
For files which are not ELF and not a script for a known "-c" shell,
UPX uses kernel execve(), which first requires decompressing to a
temporary file in the file system. 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.
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:
1) decompress the overlay to a temporary location in /tmp
2) open the temporary file for reading
3) try to delete the temporary file and start (execve)
the uncompressed program in /tmp using /proc/<pid>/fd/X as
attained by step 2)
4) if that fails, fork off a subprocess to clean up and
start the program in /tmp in the meantime
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:
- You need additional free disk space for the uncompressed program
in your /tmp directory. This program is deleted immediately after
decompression, but you still need it for the full execution time
of the program.
- You must have /proc file system support as the stub wants to open
/proc/<pid>/exe and needs /proc/<pid>/fd/X. This also means that you
cannot compress programs that are used during the boot sequence
before /proc is mounted.
- Utilities like `top' will display numerical values in the process
name field. This is because Linux computes the process name from
the first argument of the last execve syscall (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
th
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 uncompresse
d
versions, so they will not override other memory areas while unpacking.
If this isn't possible UPX will abort showing a 'packed data overlap'
error. With the "--force" option 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
--8-bit
--8mib-ram
--boot-only
--no-align
,
but the compressed executable will not boot from a CD.
Use it for console transfer only !
NOTES FOR RTM32/PE and ARM/PE
Same as win32/pe.
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
--all-filters
--all-filters
The PE support in UPX is quite stable now, but probably there are still
some incompatibilities with some files.
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.
If you're running executables from network, then compressed programs
will load faster, and require less bandwidth during execution.
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 (like winword.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.
--keep-resource=list Don't compress resources specified by the list.
The members of the list are separated by commas.
A list member has the following format: I<type[/name]>
.
I<Type> is the type of the resource. Standard types
must be specified as decimal numbers, user types can b
e
specified by decimal IDs or strings. I<Name> is the
identifier of the resource. It can be a decimal number
or a string. For example:
--keep-resource=2/MYBITMAP,5,6/12345
--strip-relocs=0
--strip-relocs=1
--all-methods
--all-filters
DIAGNOSTICS
Exit status is normally 0; if an error occurs, exit status is 1. If a
warning occurs, exit status is 2.
UPX's diagnostics are intended to be self-explanatory.
BUGS
Please report all bugs immediately to the authors.
AUTHORS
Markus F.X.J. Oberhumer <markus@oberhumer.com>
http://www.oberhumer.com
Laszlo Molnar <ml1050@users.sourceforge.net>
John F. Reiser <jreiser@BitWagon.com>
Jens Medoch <jssg@users.sourceforge.net>
COPYRIGHT
Copyright (C) 1996-2013 Markus Franz Xaver Johannes Oberhumer
Copyright (C) 1996-2013 Laszlo Molnar
Copyright (C) 2000-2013 John F. Reiser
Copyright (C) 2002-2013 Jens Medoch
This program may be used freely, and you are welcome to redistribute it
under certain conditions.
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. See the UPX License
Agreement for more details.
You should have received a copy of the UPX License Agreement along with
this program; see the file LICENSE. If not, visit the UPX home page.