Author Topic: Best Executable Compressor Programs (Read 52,218 times)

f0dder · « **Reply #25 on:** April 28, 2006, 07:05 PM »

Whoa, I thought UPX was dead

masu · « **Reply #26 on:** April 28, 2006, 07:11 PM »

me, too
but obviously their forum is still dead

app103 · « **Reply #27 on:** April 30, 2006, 06:37 AM »

Quote from: seedling on February 20, 2006, 09:37 PM

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.

And how long ago were these 'old days'? I am concerned about this as I have one of those older, slower, low ram pc's and I wouldn't want to slow things down any more than it already is, considering that I won't release any software that isn't suitable for use on that pc.

I care about those that are stuck with old crap and can't afford the latest & greatest. I don't want to cheat them. Someone has to remember them...they are still out there, and they still have the need for software, and it wasn't long ago that I was among them with nothing but a P1, 233mhz, 64mb ram, running WinME as my one & only pc. (less than 6 months ago, and I was stuck on it for more than 2 years)

I am also concerned not about the one compressed app, but what kind of performance issues one would have if they ran numerous compressed apps at the same time on a pc like that. If it could cause a problem, I don't want to contribute to it by compressing mine.

f0dder · « **Reply #28 on:** April 30, 2006, 07:48 AM »

Quote

I am also concerned not about the one compressed app, but what kind of performance issues one would have if they ran numerous compressed apps at the same time on a pc like that. If it could cause a problem, I don't want to contribute to it by compressing mine.

You definitely shouldn't compress programs that will run multiple instances. With uncompressed programs, all code and data that isn't written to will be shared among multiple instances of the program. With compressed programs, ALL code/data in your app will be private to each instance.

Use a good tool like Process Explorer to check the "private bytes" of your app in compressed vs. uncompressed mode.

masu · « **Reply #29 on:** May 01, 2007, 11:01 AM »

UPX 3.0 is out now

Quote

Changes in 3.00 (27 Apr 2007):
* watcom/le & tmt/adam: fixed a problem when using certain filters

Changes in 2.93 beta (08 Mar 2007):
* new formats Mach/i386 and Mach/fat support Mac OS X i686 and
Universal binaries [i686 and PowerPC only]
* dos/exe: LZMA is now also supported for 16-bit dos/exe. Please note that
you have to explicitly use '--lzma' even for '--ultra-brute' here
because runtime decompression is about 30 times slower than NRV -
which is really noticeable on old machines.
* dos/exe: fixed a rarely occuring bug in relocation handling
* win32/pe & arm/pe: better icon compression handling

Changes in 2.92 beta (23 Jan 2007):
* new option '--ultra-brute' which tries even more variants
* slightly improved compression ratio for some files when
using '--brute' or '--ultra-brute'
* bug fixes

Changes in 2.91 beta (29 Nov 2006):
* assorted bug fixes
* arm/pe: fix "missing" icon & version info resource problem for wince 5
* win32/pe & arm/pe: added option --compress-icons=3 to compress all icons

Changes in 2.90 beta (08 Oct 2006):
* LZMA algorithm support for most of the 32-bit and 64-bit file formats;
use new option '--lzma' to enable
* new format: BSD/elf386 supporting FreeBSD, NetBSD and OpenBSD
via auto-detection of PT_NOTE or EI_OSABI
* arm/pe: all the NRV compression methods are now supported
(only NRV2D is missing in thumb mode)
* linux/elf386, linux/ElfAMD: remember /proc/self/exe in environment
* major source code changes: the runtime decompression stubs are now
built from internal ELF objects

http://upx.sourceforge.net/

Curt · « **Reply #30 on:** April 15, 2010, 04:17 PM »

Quote from: seedling on February 20, 2006, 09:37 PM

Quote from: mrainey on January 14, 2006, 08:41 PM
I use EXECryptor to protect and compress (....)
(...) anyway, for these reasons i'd never use execryptor.

Mail from Agnitum support because of my complaint against false positives:

Quote

Dear Curt,

Thank you for your message.

These files are detected as suspicious because they are packed by a packer widely appreciated by malware authors (Execryptor), but the files themseves are clean. You can add them to program exclusions by right-clicking on them in the scanning results window.

We are sorry for the inconvenience.

--
All the best,
Svetlana Goncova
Agnitum Support

kyrathaba · « **Reply #31 on:** October 17, 2010, 05:19 PM »

Anyone know of a freeware .NET packer for 32/64-bit .NET applications? I found, and downloaded, MPress 1.27, but AVG says it's infected with 2 virii.

kyrathaba · « **Reply #32 on:** October 17, 2010, 05:38 PM »

Perhaps someone could confirm that MPress is/is not actually virus-laden? Virus Total results were that 8 of 43 engines found virus/malware? Yet even Primewares hosts this freeware.

4wd · « **Reply #33 on:** October 18, 2010, 12:52 AM »

Outpost Security Suite reports no virus and doesn't complain when I run it. Output files are considered clean also.

JottiScan result

kyrathaba · « **Reply #34 on:** October 18, 2010, 02:14 AM »

Interesting...

Total Virus shows 8 of 43 engines giving the thumbs down to "MPress". But your Outpost Security Suite, and my MalWare Bytes and Spybot Search and Destroy say it's okay. Wonder if I dare test it with one of my .NET executables?

f0dder · « **Reply #35 on:** October 22, 2010, 06:30 PM »

Quote from: kyrathaba on October 17, 2010, 05:19 PM

Anyone know of a freeware .NET packer for 32/64-bit .NET applications? I found, and downloaded, MPress 1.27, but AVG says it's infected with 2 virii.

Don't bother. Really, don't bother. The false A/V positives is reason enough (damn those bastards!), and the gains usually aren't worth it. I wonder about the penalties, though... I suspect you already get some "pessimization" wrt. multiple instances not sharing code in .NET because of the JIT'ed nature, but there's other potential pessimization as well, like reflecting over assemblies.

What's your perceived need of executable compression anyway?

Hypocrisy? - While I'm generally pretty much against executable compression, I do employ it on fSekrit. I'm defending it with "people might need to store their password file online as a single file, and grab it over slow links", but I've been considering whether to keep compressing for future releases.

4wd · « **Reply #36 on:** October 22, 2010, 11:42 PM »

Quote from: f0dder on October 22, 2010, 06:30 PM

What's your perceived need of executable compression anyway?

The only place I use it is to maximise free space on my "tool" flash drive.

kyrathaba · « **Reply #37 on:** October 29, 2010, 02:26 AM »

To be honest, I don't really have a perceived need for compression. I've actually wondered, with the storage/performance of PCs nowadays, why compression of executables? They say it speeds up execution, but how much, really?

I guess I've just been looking for a compressor of .NET apps out of curiosity, really.

f0dder · « **Reply #38 on:** October 29, 2010, 09:00 AM »

Hm, speeds up execution...

The application will load from disk a bit faster - in theory. Thing is, Windows does demand-paged execution, meaning it won't load parts of your application from disk until they're used. This is defeated by exe compression, since the entire module will be loaded at once (I'm not sure how much of a .NET assembly is loaded under normal execution... so perhaps this isn't such a big problem).

There's additional CPU usage because of the decompression, but the decompressors are fast - even on older machines, the time to decompress the additional data is a lot lower than reading data from disk (but again, we're ignoring demand-paging here).

HOWEVER, in reality, your executable is likely to load a lot less slower on a lot of end-user systems, regardless. Why? Anti-malware software. When doing on-demand scanning of executables, the anti-malware software has to decompress the executable before it can scan it - and for safety reasons, it can't just execute the executable's own decompressor, it has to have specific support for the exe-packer used, or run (slow!) sandboxed code emulation.

Author Topic: Best Executable Compressor Programs (Read 52,218 times)

f0dder

Re: Best Executable Compressor Programs

masu

Re: Best Executable Compressor Programs

app103

Re: Best Executable Compressor Programs

f0dder

Re: Best Executable Compressor Programs

masu

Re: Best Executable Compressor Programs

Curt

Re: Best Executable Compressor Programs

kyrathaba

Re: Best Executable Compressor Programs

kyrathaba

Re: Best Executable Compressor Programs

4wd

Re: Best Executable Compressor Programs

kyrathaba

Re: Best Executable Compressor Programs

f0dder

Re: Best Executable Compressor Programs

4wd

Re: Best Executable Compressor Programs

kyrathaba

Re: Best Executable Compressor Programs

f0dder

Re: Best Executable Compressor Programs