Author Topic: Best Executable Compressor Programs (Read 40256 times)

jdd · « **on:** January 08, 2006, 10:17 AM »

I know that PECompact 2 has become available at a good discount but I am interested to hear other opinions from the forum regarding what they consider to be the best executable compression programs available.

Thanks,
jdd

mouser · « **Reply #1 on:** January 08, 2006, 10:21 AM »

you already mentioned pecompact: http://www.bitsum.com/pec2.asp

a good free (open source) one is UPX: http://upx.sourceforge.net/

i also would like to hear what people view are advantages and disadvantages of the different tools.
there are also protector programs which include compression (asprotect for example).

one point of clarification - bitsum is giving free licenses of pecompact to most donationcoder.com members (the discounts are for new members who want to upgrade to a higher edition). See https://www.donation.../drawing/drawing.php.

Jibz · « **Reply #2 on:** January 08, 2006, 10:33 AM »

If you had asked me some years back, I would have said whichever one makes the smallest executable. Today I tend to prefer compatibility and stability.

I'd rather have a 5k larger executable that doesn't crash on some machines, or trigger false virus alerts

.

f0dder · « **Reply #3 on:** January 08, 2006, 10:45 AM »

Whoa, I spotted The Jibz! :O

Carol Haynes · « **Reply #4 on:** January 09, 2006, 06:23 PM »

fOdder you deserve a prize ... welcome back Jibz ... now the smilies can come out of mourning

mouser · « **Reply #5 on:** January 09, 2006, 06:47 PM »

no. read carefully jibz smileys only come off strike when jibz visits the irc channel.

Carol Haynes · « **Reply #6 on:** January 09, 2006, 07:10 PM »

Ah - cattle prods out there ...

Here Jibzy, Jibzy ....

Sentinel · « **Reply #7 on:** January 12, 2006, 01:25 PM »

Jibz makes a very good point (as always), there is much more to consider than size alone. Personally with all of the computing power available today, size is not an issue, compatibility is key. I used UPX for a long time and it really is a great util, but from the release of Visual Studio 2003 onwards it started having compatibility issues with certain executables that were not easily resolved. These days I use PECompact simply because it is fully featured, stable and has great support from the author. That being said, as any common sense you have may say, avoid compressing or releasing anything with the alpha/beta releases.

jdd · « **Reply #8 on:** January 14, 2006, 12:35 PM »

Sometimes ......size does matter. We are working on a program and the executable is about 24MB. We want to shrink it down as much as possible so it can be downloaded or emailed.

jdd

f0dder · « **Reply #9 on:** January 14, 2006, 01:32 PM »

Sentinel, the problem with UPX and later-version VC executables is the "load config" data generated. You can use a tool like HIEW to nuke it, then UPX won't have any problems. Or I guess I could code a small tool to do this.

Sentinel · « **Reply #10 on:** January 14, 2006, 02:05 PM »

Sentinel, the problem with UPX and later-version VC executables is the "load config" data generated. You can use a tool like HIEW to nuke it, then UPX won't have any problems. Or I guess I could code a small tool to do this.
-f0dder (January 14, 2006, 01:32 PM)

Yep, I don't disagree and using the 'force' switch also works, not to mention the various ways of compiling your code that also avoids the problem, I just get the feeling that if it [UPX] is not happy about compressing my exe I'm not happy about letting it either. I guess my main issue with UPX is the lack of progress over the past 4 years and that really IS a long time in the exe packing arena.

Sometimes ......size does matter. We are working on a program and the executable is about 24MB. We want to shrink it down as much as possible so it can be downloaded or emailed.
-jdd

Yes size does matter to a point, but relative to compatibility it is irrelevant. If you save 10kb over an alternative product but your compressed exe only works on 50% of your customers PCs then you are in far from an ideal position. Sadly in the world of 'program for pleasure' exe compressors this is an all too common problem. Outside of ASPack, UPX and PECompact I wouldn't trust any exe compressors as far as I could throw them no matter how good the compression ratio may be. Even with the 'tried and trusted' compressors there may be certain situations where I would avoid them like the plague.

Sentinel · « **Reply #11 on:** January 14, 2006, 02:10 PM »

If you absolutely must have the best compression out there then WinUnpack appears to be the current leader.

http://dwing.go.nease.net/

Unfortunately the official website seems about as stable as the packer IMHO.

mrainey · « **Reply #12 on:** January 14, 2006, 02:41 PM »

I use EXECryptor to protect and compress ( http://www.strongbit.com ). It will prevent reverse engineering of an executable. According to the crackers over at http://forum.exetools.com, nobody has broken the encryption yet. I tried using the registration key feature of EXECryptor, but it was cracked pretty quickly. Now I just gut the demos by removing a lot of code, then encrypt them.

EXECryptor compresses a 2 meg executable down to about 450k. I haven't heard any complaints about compatibility or speed from my customers.

If you buy it, don't waste your time asking for help from the developer. He never answers.

f0dder · « **Reply #13 on:** January 15, 2006, 11:04 AM »

Yep, I don't disagree and using the 'force' switch also works, not to mention the various ways of compiling your code that also avoids the problem

Oh, which ways are that? I tried looking for compiler/linker settings to avoid the generation of load config data, but couldn't find any.

Btw, using --force to solve the problem sometimes produces crashing executables.

db90h · « **Reply #14 on:** February 10, 2006, 10:28 AM »

Sometimes ......size does matter. We are working on a program and the executable is about 24MB. We want to shrink it down as much as possible so it can be downloaded or emailed.
-jdd (January 14, 2006, 12:35 PM)

For most executables of this size, PECompact performs best anyway.. particularly v2.76b. I won't re-iterate the very intelligent arguments others have made here.. but you need to not choose a packer that creates a 0.1% smaller executable without evaluating it as a whole.

mouser · « **Reply #15 on:** February 10, 2006, 10:38 AM »

i agree with db (who makes pecompact, the tool we use at donationcoder). picking a compressor by choosing one that makes slightly smaller files than other would be a bad mistake (compatibility on different platforms would probably be my number 1 concern).

recent pecompact/bitsum (www.bitsum.com) email from february 8:

We hope that PECompact is continuing to suit your needs. We rarely send out product news, so we hope you are as excited to receive this news as we are
to send it.

The last few months have brought a long list of product improvements, far more than we can list here. A summary of a few of the more important changes
is below:

+ Support for resource-only DLLs (ones with no entry point)
These DLLs are common in the industry. PECompact is proud to be one of the first executable packers to fully support them.

+ New 'Restore Imports' option
This feature allows external applications to more easily hook API imports in your compressed modules. This is usually done to extend or modify API
behavior at run-time. One example is ATI display drivers, which hook the imports of OpenGL applications. This option is enabled by default to ensure
the widest possible compatibility.

+ An important fix for 'Enforce Memory Protections' (/emp:y).
For customers who utilize this non-default feature that sets the virtual memory access permissions to those indicated by the original section table,
we recommend upgrading to the latest version of PECompact. Don't worry, there is usually no need to re-release your compressed applications. For more
information on this fix, please visit our forums or email us at [email protected].

+ New 'Trim Memory' option
This option temporarily trims the working set after a compressed module has been decompressed. This will cause almost all virtual memory in the
process space to be paged out. Of course, as the pages are referenced again, they are paged back in. While it is usually best to let the virtual memory
manager do its job without interference, this can reduce the initial physical memory use of your application.

+ Compression ratio improvements
Compression ratios have been improved a bit across the board. With a re-written LZMA codec and new options like 'Truncate Last Section', you can make
sure your modules are as small possible.

+ GUI improvements and new languages
The enhanced GUI is now available in English, Russian, Chinese, German, Dutch, French, Swedish, Italian, Slovenian, Polish, and Japanese!

+ An assortment of other minor changes and fixes
We've made so many improvements and bug fixes that it's more practical to just download the new version and see for yourself!

In addition to the improvements we've made to PECompact, we've also made many improvements to Bitsum Technologies. Come see what we have to offer in
2006!

For those wondering, PE+ (PE64) support is coming to PECompact in the near future! When we've got this new capability fully release ready, we'll send out another notification like this.

nontroppo · « **Reply #16 on:** February 10, 2006, 11:11 AM »

mouser: why do you compress your programs out of curiosity? As far as I can see (I'm no programmer, so anyone tell me to shut

) the benefits in general are no so substantial.

mouser · « **Reply #17 on:** February 10, 2006, 11:18 AM »

my impression is people prefer having the smaller executables, and that it can actually be faster to load from disk.
if people prefer non-compressed i could go back to that.

nontroppo · « **Reply #18 on:** February 10, 2006, 11:37 AM »

Well, my only gripe with compression is specific to certain apps, as compression forces all code into RAM at startup and stops another running instance share any working set. In your case your apps are small when in memory and normally run one instance so those negatives don't really count. I'm certainly not opposed to compression for your apps, just curious on the reasons. Thanks

Gerome · « **Reply #19 on:** February 10, 2006, 04:11 PM »

Hi,

I've already tested PECompact and ... it still has a big problem with DLLs !!!
The idea is nice, the compression is good, but it fails onto some DLLs.
I've experimented it several times against my DLLs and i've never had any successful results :/
The *ONLY* program i've never had any kinda failure or warning is, and still is, is UPX Executable compressor !
FYI, my Fbsl runtimes are UPX'ed

db90h · « **Reply #20 on:** February 20, 2006, 01:32 PM »

Well, my only gripe with compression is specific to certain apps, as compression forces all code into RAM at startup and stops another running instance share any working set..
-nontroppo (February 10, 2006, 11:37 AM)

Virtual memory management is a complex affair. In the end, the penalty from having all code loaded into RAM at start-up isn't a penalty at all. Of course the pages will be paged back out as warranted, or with PECompact you can have them paged immediately back out.. but the fact is that loading the entire image at once is often better than using a demand loading scanario.

With modern hard drives and other storage mediums, its better to take an initial 'swipe' (read) of all a module's image, instead of having to go back to the disk several times to read portions as they are referenced. When read all at once, especially on an unfragmented disk, the read is quick and painless. When read in bits and pieces over time, the hard drive must relocate to the necessary clusters since it probably has gone off reading other data in the interim.

And, of course, with a compressed program the initial read of program data is 10-40% (on average) of what it would have been.

In the end, on modern computers this often makes for faster load-time.

Regarding shared memory: PECompact ignores sections marked as shared. Those not explicitly marked as shared will indeed not be shared (copy on-write) across instances. However, in the vast majority of cases this memory won't be shareable anyway and is quite a small chunk of over-all virtual memory use by an application.

db90h · « **Reply #21 on:** February 20, 2006, 01:33 PM »

I've already tested PECompact and ... it still has a big problem with DLLs !!!
-Gerome (February 10, 2006, 04:11 PM)

It would be wonderful of you if you could provide me examples of these DLLs. I compress all my DLLs with PECompact and it is designed and tested to work with DLLs. If there is a set of DLLs it isn't working with, I'd really like to know so I can address the errata.

If you'll give me uncompressed examples, I'll give you a free commercial unlimited license of PECompact and a license of Process Lasso

.

Thanks.

seedling · « **Reply #22 on:** February 20, 2006, 03:37 PM »

I use EXECryptor to protect and compress ( http://www.strongbit.com ). It will prevent reverse engineering of an executable. According to the crackers over at http://forum.exetools.com, nobody has broken the encryption yet. I tried using the registration key feature of EXECryptor, but it was cracked pretty quickly. Now I just gut the demos by removing a lot of code, then encrypt them.
-mrainey (January 14, 2006, 02:41 PM)

you are doing your customers such a disservice by releasing demos and then still using this cpu cycle eating monster. i mean if you truly remove key functions in your code then what's the point of using a protector compressor?

let me explain something about execryptor. first, it IS a very clever protection i have to admit. but for god sakes, don't you know it runs multiple threads watching for debuggers etc? not to mention how it creates, on demand, the import pointers it uses. and of course it doesn't really encrypt anything, it just obfuscates the hell out of the functions you want protected (which i guess is a form of encryption?). it does this by taking a normal small < 100 byte asm function and turns it into multiple thousands of bytes. when it's all done it then compresses the whole thing. if you were using this protector back in the old days you'd definintely see a difference in speed. i guess we all take advantage of the fact that new processor speeds all but hides these overactive protectors.

also, execryptor is not at all impervious to being cracked. believe me, i've seen it done

what do you gain from having yet another crackable protector/compressor that uses up more cpu cycles than your original app ever should have? not much i guess.

anyway, for these reasons i'd never use execryptor.

if you want good, solid compression, i'd stick with pecompact or upx.

if you want a step up for protection, then i'd go with asprotect (altho i don't like how it allocates so much memory to emulate api calls). but it's generally not that obtrusive, has quick decompression and solid function encryption.

armadillo is also a good protector, but too much overhead for my taste (actively debugging your app while running).

...there you go, my 2 cents

mrainey · « **Reply #23 on:** February 21, 2006, 09:41 AM »

Hi seedling,

I (attempt?) to encrypt my demos because there's still lots of data, formulas, and code in them that cost me hundreds of hours, and I don't see any reason to make it available.

I started with Armadillo, using the most basic level of protection. It was cracked almost immediately. After making daily visits to the private forum for a few months to see what people were talking about, I concluded that folks were tying themselves in knots, sticking all sorts of complex code into their apps to help Armadillo keep the crackers out - and it wasn't working. Armadillo protection was being cracked within a few days. The lead developer quit, and it didn't feel good. So I tried something else (EXECryptor).

I haven't personally read of EXECryptor being cracked. Where can I read more?

My applications open and run very fast, and don't seem to use an excessive number of CPU cycles. Customers comment favorably on the speed and don't mention their other apps slowing down. See this screenshot - my program open with a number of different windows displayed. CPU is 2. Look at CounterSpy (SunProtection) if you want a real hog.

http://mrainey.frees...laneous/MEProCPU.jpg

I don't think there is a perfect answer. I haven't seen a good reason to ditch EXECryptor myself, but do appreciate your point of view. Whatever works for you.

masu · « **Reply #24 on:** April 28, 2006, 01:34 PM »

Today UPX 2.0 is released

The main news in version 2 are:
new format: added support for arm/pe (ARM executables running on WinCE)
new format: added support for linux elf/amd64
new format: added support for linux elf/ppc32
new format: added support for mach/ppc32 (Apple Mac OS X)
new format: added support for bootable Linux kernels ("vmlinuz/386")
new format: added support for Playstation exes ("ps1/exe")
slightly better compression using the new NRV2E algorithm
new options for compression tuning (e.g. '--brute')
improved win32/pe compatibility
direct ELF-to-memory decompression
various bug fixes

http://upx.sourceforge.net/