PECompact Documentation

CODEC Plug-ins

Back to Index ] [ Back to Bitsum Technologies ]

PECompact is allows for use of third-party CODECs (encoding/decoding algorithms). It even supports use of any number of CODECs on a single executable, meaning you can chain the CODECs together. For example, one could use the LZMA CODEC and the CRC CODEC to 1.) Compress the data and 2.) Perform a CRC check on the data, respectively.

When extremely fast decompression is desired as well as a good compression ratio, we recommend FFCE. It doesn't compress as well as LZMA, but decompresses more rapidly. FFCE is the default for executables under 48Kb.

PECompact2 includes several CODECs for compression, encryption, and other uses. Some are only inclduded in the registered version of PECompact.

Which CODECs are available for PECompact?
How do I sequence multiple CODECs?
How do I know which CODEC I should use?

Available CODECs:

Name Filename Author Type Description
aPLib pec2codec_aplib.dll Jørgen Ibsen Compression
aPLib
aPLib is a high performance compression algorithm with less decompression overhead than FFCE, but slower and does not compress larger files as well as FFCE. Its decompression code is slightly larger than FFCE's.
BriefLZ pec2codec_brieflz.dll Jørgen Ibsen Compression
BriefLZ
BriefLZ is a compression algorithm optimized for fast compression and reasonable ratios.
CRC32 pec2codec_crc32.dll Jørgen Ibsen Integrity check
CRC32
A simple CRC32 checksum routine. If the data is found to be corrupt at runtime, you will see a message box stating such and the module will exit.
ElfHash pec2codec_elfhash.dll User contributed Integrity check
ElfHash
ElfHash is a high-speed checksum algorithm. It is a good replacement for CRC32.
FFCE
*recommended for small files and when faster decompression is desired.
pec2codec_ffce.dll Jørgen Ibsen Compression.
FFCE
FFCE is the default CODEC for small files. It is a high-performance general purpose compression algorithm. It performs best on larger files and has a decompressor that is slightly smaller than aPLib's
JCALG1 pec2codec_jcalg1.dll Jeremy Collake Compression
JCALG1
JCALG1 is a high-performance general purpose compression algorithm. Compression is much slower, but (especially) at higher compression levels JCALG1 may perform better than other CODECs on some files. Decompression speed is very fast, comparable with aPLib and NRV2E.
LZMA
*recommended for mid-size to large files, but doesn't decompress as fast as FFCE.
pec2codec_lzma2.dll (v2) LZMA Author: 7-Zip (Igor Pavlov)
Codec Author: Jeremy Collake
Compression
LZMA
LZMA is the default CODEC for mid-size and large-size modules. It is a high performance compression algorithm that generally compresses substantially tighter than any other of the algorithms listed here.
MessageBox pec2codec_messagebox.dll Jørgen Ibsen User I/O
MessageBox Prompt
At runtime displays a message box entirely configured by the user (at time of encode) and takes action appropriate to the user's response at runtime. For example, one could install a 'Are you sure you want to allow this to run?' Yes/No message box on a script interpetor.
NRV2E pec2codec_nrv2e.dll UPX/BobSoft Compression
NRV2E
This compression algorithm is used by UPX. Its compression ratio is not as good as LZMA, though its decompression speed may be a bit faster. This plug-in is NOT distributed by Bitsum Technologies. BoBSoft has some third-party examples of how to write plug-ins in Pascal, including a built NRV2E codec plug-in.
Password pec2codec_password.dll Jørgen Ibsen Encryption
Password key
TEA
Encrypts a file using password entered by user as key. At runtime, the user is prompted for a password. If correct, the module is decompressed and run. If incorrect, the module exits.
TEA encryption is used: http://www.simonshepherd.supanet.com/tea.htm .
         
 

CODEC Ordering / Sequence:

The ordering use of CODECs is very important since it dramatically affects the output. For instance, you should always compression before encrypt, else the compression is likely to suffer a terrible penalty since the data was transformed into a much more random state by the encryption. The ordering of CODECs is as specified during compression and reversed during decompression. This means that the following configuration would perform a CRC check on the compressed data, there-by performing in at run-time before decompression:

  1. pec2codec_ffce
  2. pec2codec_crc32

Another example is the case of a password protected and compressed executable with crc32 validation, which should be in a similar order as follows:

  1. pec2codec_ffce
  2. pec2codec_password
  3. pec2codec_crc32

Sometimes you may want to use a single CODEC multiple times, for instance:

  1. pec2codec_crc32
  2. pec2codec_ffce
  3. pec2codec_crc32

This would perform a CRC32 check before and after decompression, making sure that the data supplied to the decompressor is unchanged and that your data is in its exact original state after decompression. Note that this will slightly slow load time, though perhaps not noticably, depending on the size of the data set(s). Typically speaking, such a configuration is redundant.

Since PECompact performs its own quick checksum, it is generally better to not use the CRC32 plug-in unless you really need good image validation.

Which CODEC should I use?

Selecting the appropriate CODEC depends on the size and contents module you are compressing. Often, PECompact can best optimize small files when aPLib, FFCE, or JCALG1 are used with their small decoders. Larger files are typically compressed better by LZMA. Since the additional size of the fast decoder is insignificant for larger files, it is recommended that the fast decoder be used in such cases. For smaller files, the small decoder often performs as well, or better, than the fast decoder.

When extremely fast decompression is desired as well as a good compression ratio, we recommend FFCE. It doesn't compress quite as tight as LZMA, but decompresses much more rapidly. FFCE is the default for executables under 100Kb.

You should experiment with various CODECs to determine which is appropriate for your application. Some algorithms may perform particularly well on specific data, but generally speaking, FFCE and LZMA are the two typically used.