Main Area and Open Discussion > General Software Discussion

Best Executable Compressor Programs

<< < (5/8) > >>

db90h:
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)
--- End quote ---

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:
I've already tested PECompact and ... it still has a big problem with DLLs !!!
-Gerome (February 10, 2006, 04:11 PM)
--- End quote ---

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:
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)
--- End quote ---

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:
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.freeservers.com/Miscellaneous/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:
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
--- End quote ---


http://upx.sourceforge.net/

Navigation

[0] Message Index

[#] Next page

[*] Previous page