Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

UPX – Ultimate Packer for Executables

upx.github.io

Post reply on HN
Print view View original

61–70 of 82 posts

Re: UPX – Ultimate Packer for Executables

#61

Post by beagle3 »

FooBarWidget wrote: post #59
beagle3 wrote: post #31

People who compress their go binaries (or any other binaries, really) - please be aware that thus doing, you stop the OS from being able to page out your executable (rarely a big loss), and also to be unable to share executable pages (not a huge loss for a 2MB executable, a huge loss for a 100MB executable). If there's only one copy of a program running, it won't matter - but if you are running hundreds of copies (ev…

> and also to be unable to share executable pages (not a huge loss for a 2MB executable, a huge loss for a 100MB executable). I don't think people care about that nowadays, seeing how popular Docker containers are. I think Docker containers already make it so that you cannot share executable memory between different containers because each one runs in its private namespace.

Do namespaces separate file system caches? That would surprise me.

Re: UPX – Ultimate Packer for Executables

#62

Post by jared0x90 »

Funny to see this here, it's been ages since I've seen UPX mentioned. In the early 2000's I had written some software whose executable was around a megabytes or maybe several megabytes in size coming out of VB6. On one of mid 90's test laptops we used at the time to ensure it would run on even the crummiest of machines it launched NOTICEABLY faster when packed with UPX. The hard disk in that machine was so incredibly slow loading less off the disk and decompressing the executable in RAM was easily an order of magnitude faster.

Re: UPX – Ultimate Packer for Executables

#63

Post by gundul »

Just to chip in on my experience on this matter. I use UPX as one of the RE defense method on a couple of Delphi based software we build which our customer runs regularly on their servers. One of the challenge is some A/V throws a false positive upon checking the result files. Somehow this became no longer an issue after applying code-signing to the UPX output executables.

Re: UPX – Ultimate Packer for Executables

#64

Post by viraptor »

beagle3 wrote: post #61
FooBarWidget wrote: post #59

Earlier quoted context omitted.

> and also to be unable to share executable pages (not a huge loss for a 2MB executable, a huge loss for a 100MB executable). I don't think people care about that nowadays, seeing how popular Docker containers are. I think Docker containers already make it so that you cannot share executable memory between different containers because each one runs in its private namespace.

Do namespaces separate file system caches? That would surprise me.

The only one that could matter here would be mnt. And since bind mounts normally wouldn't cache pages separately, I don't think that would happen for the namespaces either. Happy to be proven wrong though.

More specifically I wouldn't expect "free -m" to produce different result depending on the namespace it's run in.

Re: UPX – Ultimate Packer for Executables

#65

Post by majewsky »

gundul wrote: post #63

Just to chip in on my experience on this matter. I use UPX as one of the RE defense method on a couple of Delphi based software we build which our customer runs regularly on their servers. One of the challenge is some A/V throws a false positive upon checking the result files. Somehow this became no longer an issue after applying code-signing to the UPX output executables.

> RE defense method

How does UPX defend against reverse engineering? The binary literally contains the code to reverse the UPX compression (otherwise it couldn't run), and I'd expect all antiviruses to be able to unpack UPX executables.

Re: UPX – Ultimate Packer for Executables

#66

Post by s3arch »

userbinator wrote: post #45
bruno2223 wrote: post #14

UPX was also good to protect the code, not only for compacting: 1. I used UPX to compact my Delphi EXE file. 2. Then I openned up any HEXA editor 3. looked for "UPX" string and changed to "222x" Doing this, the UPX unpack tool didn't work and crackers could not easily see or edit my source code with Assembly (as UPX mess with everything!) Thanks UPX :-)

As someone "on the other side ;-)", I don't think you protected much. UPX is pretty much the classic "Hello World" of unpacking manually, and tools like PEid will still be able to tell it's UPX from the decompressor stub alone. It's been years since I unpacked a UPX manually, but I still remember what it looks like: a PUSHA at the start to save all the registers, a lot of decompression code, and finally a POPA and a…

Also it really doesn't matter what custom/tweaked packers the authors use.

It has been years. I vaguely remember, there is always a general standard way of unpacking.

Using the debugger, you keep track of those jmp instructions until unpacking is done. And then dump the memory to a file.

Re: UPX – Ultimate Packer for Executables

#67

Post by squarefoot »

analognoise wrote: post #50
spapas82 wrote: post #9

I used it to compress a Lazarus (open source Delphi clone) executable. The results were great (executable size reduced by more than 50%, iirc from 2 mb to around 800 kB). Offering a sub MB executable in the era of 100 MB electron apps is totally pioneer :)

I've done the same thing! Shout out to Lazarus/FPC!!!

I've seen some posts about it over here recently and believe the critical users/developers mass to make it a successful dev system is achieved, however it still has to struggle to be taken into consideration in some contexts for not using a major language. If it allowed to build GUIs for C++ (QT/*TK and other builders are not even close to its usability level) it would probably become mainstream in a week.

Re: UPX – Ultimate Packer for Executables

#68

Post by majewsky »

interfixus wrote: post #44

I do most of my web-dev in Nim these days. Meaning my ELFs are ultimately produced by GCC og Clang. Everyting statically linked - and I mean everything : For clib I use Musl. And then I UPX the bejesus out of them. It's simply nice to ship a fully working app, with SQLite* and everything, which will basically run anywhere with a Linux kernel, in a single executable far below 2 MB. *) Yes, the vast majority of the wor…

SQLite-only can be a feature. On my long list of potential projects is a cloud storage/PIM/etc. application (similar to OwnCloud) that only supports SQLite in order to scale badly to more than 50-100 users, thus forcing users to decentralize and federate.

Re: UPX – Ultimate Packer for Executables

#69

Post by pgeorgi »

beagle3 wrote: post #58
smegel wrote: post #39

Earlier quoted context omitted.

> you stop the OS from being able to page out your executable (rarely a big loss) Why is this exactly?

Indeed, as jlebar notes - since the actual executable code (the thing that the CPU executes) does not exist directly in the executable file, the OS will have to write it out to the swap if it needs the memory (unlike uncompressed files, where it just reuses the memory and later reloads from the executable file). It is rarely a big loss, because executables that are in use tend to remain in memory if the program is ac…

Also if you have the same executable running several times on a machine, they share the RAM for the code (read-only pages, which should be most of them).

That doesn't work for UPX because each execution decompresses anew, which makes it a "new executable" from the OS' point of view. The only thing that would help is kernel space merging, but that's really only activated for some virtual machines.

Re: UPX – Ultimate Packer for Executables

#70

Post by lm2s »

hannob wrote: post #2

Surprised this still exists. A little walk down memory lane: I once ran the exe mailing list for exe packers and protection tools. There was a whole scene of people in the 90s writing such tools and writing unpackers and removal tools for such things. UPX was one of the later ones that still existed when most of this scene vanished.

In the 90s I was still starting to explore computers and executables, etc, and it blew my mind when I found about packers and protection tools and RE in general. Good times! Oh nostalgia...

I just remembered: ProcDump32! Geez, that really blew my mind at the time and in a way still does.

Post reply on HN