Compress data or compress executable?
I need to embed some binary data in my program and I'm torn between compressing the compiled binary with UPX or compressing the data with LZ4 at compile time and decompressing it at run time.
What do you guys think is better?
What do you guys think is better?
I vote for the latter. UPX has a variety of issues you can avoid by just using a simple decompress filter on your resource data.
Currently I don’t, sorry...
Zlib is designed to work over streams and it is pretty small and all but guaranteed to exist on your target system due to its ubiquity.
You’d need to write something that wraps the resource acquisition into a read stream (or find a library that does this) and pipe it through the zlib deflate stream reader.
Zlib is designed to work over streams and it is pretty small and all but guaranteed to exist on your target system due to its ubiquity.
You’d need to write something that wraps the resource acquisition into a read stream (or find a library that does this) and pipe it through the zlib deflate stream reader.
Oops. Sorry, I guess my phrasing was kind of ambiguous. I mean if you have any links about the UPX thing.
Last edited on
Do you mean like this?
https://stackoverflow.com/questions/353634/are-there-any-downsides-to-using-upx-to-compress-a-windows-executable
Basically, UPX replaces your executable with the UPX executable and places your executable as a block at the end of the UPX executable file, which it then decompresses.
This produces a number of problems:
• You need to make sure to modify the UPX info block to represent your application.
• On Windows, at least, you must have a disk lock to execute code.
That is, the executable parts must be duplicated to disk, when you could just decompress only the data you want to memory.
• UPX these days can handle file signing, but it is still a bit clunky (to my mind, at least)
• Reducing file size is really only an issue for two reasons:
○ Transmission
○ Limited disk space
For transmission, just 7zip the file. For limited disk space, UPX requires more disk
to unpack and execute your executable.
• Multiple instances are unique — they do not share the base image file lock.
• UPXers don’t like this, but UPX executables are still routinely tagged as malware by AV scanners.
• Cross-platform, it necessarily behaves differently to work.
My preference is skip any wrapper overhead. It is easy to pack a resource in the executable cross-platform that you can then decompress to memory (or file, or whatever). You can still sign your executable and adjust its info header — all unique to your actual executable and not hijacked by the UPX executable and therefore winding up in some AV database as (not) your code.
Anyway, those are my quick thoughts. I may have missed something...
https://stackoverflow.com/questions/353634/are-there-any-downsides-to-using-upx-to-compress-a-windows-executable
Basically, UPX replaces your executable with the UPX executable and places your executable as a block at the end of the UPX executable file, which it then decompresses.
This produces a number of problems:
• You need to make sure to modify the UPX info block to represent your application.
• On Windows, at least, you must have a disk lock to execute code.
That is, the executable parts must be duplicated to disk, when you could just decompress only the data you want to memory.
• UPX these days can handle file signing, but it is still a bit clunky (to my mind, at least)
• Reducing file size is really only an issue for two reasons:
○ Transmission
○ Limited disk space
For transmission, just 7zip the file. For limited disk space, UPX requires more disk
to unpack and execute your executable.
• Multiple instances are unique — they do not share the base image file lock.
• UPXers don’t like this, but UPX executables are still routinely tagged as malware by AV scanners.
• Cross-platform, it necessarily behaves differently to work.
My preference is skip any wrapper overhead. It is easy to pack a resource in the executable cross-platform that you can then decompress to memory (or file, or whatever). You can still sign your executable and adjust its info header — all unique to your actual executable and not hijacked by the UPX executable and therefore winding up in some AV database as (not) your code.
Anyway, those are my quick thoughts. I may have missed something...
Great, thanks! I don't think any of those are huge problems for my particular application, but it's worthwhile to keep it in mind. I'll go with LZ4.
Topic archived. No new replies allowed.