upx.doc

PT2258,文件下载

                          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 KByte aligment 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.

    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 excutables ("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 (such as a hard disk, floppy disk,
      CD-ROM, flash memory, EPROM, etc.) for 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 filesystem storage, then
      invoking and running a compressed executable can be faster than
      directly running the corresponding uncompressed program.
      The operating system might perfrom 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 filesystem.
      ``Medium-sized'' programs which access about 1/3 to 1/2 of their
      stored program bytes can do particulary 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 filesystem 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 .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.

      - Compression of suid, guid and sticky-bit programs 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_file' will 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 exectuables.

    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/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/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/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
    filesystem 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 filesystem.  Interestingly -
      because of the good memory management of the Linux kernel - this
      often does not introduce a noticable 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 filesystem 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