mupack
 

This is a small executable packer that I have been working on and off for some time. The public build is restricted compared to the private one, but it still packs alright. There is some bugs:

Known bugs:
* Resources are not compressed in certain cases. Might redo resource compression to fix this.
* TLS callbacks with DLLs don��t work fully. TLS callback tables and ptrs need to be relocated via the relocs.
* Proxy TLS callback not implemented. I guess this is a feature as atm it works like a antidebug trick. Ideally it should handle TLS callbacks cleanly to ease debugging.
* Crash when unpacking VBA-Ms Wx build. Not sure why, need to fix the above TLS issue before fixing this. This would make debugging a lot easier.
* Digital code signing when executables are packed does not work.

Source code:

Updated:
* Rewrote resource compression. Fixes a known bug of not compressing executables in certain cases.

Updated:

* Rewrote TLS callback emulation. As a result, there is preliminary TLS callback in DLL support as well as easier debugging of EXE/DLL files with TLS callbacks. I found one case where TLS callbacks/index variables in DLLs doesn't work properly, need to debug that use case more.
* More work on handling uncompressed resources, fixes some bugs.

Updated:

* Fixed any TLS regressions from last build. DLL support for TLS callbacks is still preliminary, though.
* Now updates the PE file checksum.
* Added a small TLS callback on TLS using executables to fix any possible invalid TLS addresses.

Cool utility.
I guess the unpacking will not be difficult as i see into the stub:

Yeah, my private builds focus on compression ratio, using completely different compression algorithms. I designed it to be easy to depack. Figured theres no point in trying protection since people will crack it anyway. The public build is there so there is no real loss if people misuse it, although there might still be a possibility of that happening. :( Pity the taggant scheme for packers is a crock of sh*t. (only useful for commercial stuff, not freeware) And digital signatures do nothing too.

Plus, many packers like ASPack, PESpin and mpress seem to miss crucial things like proper TLS callback support. I guess now I need to work out overlay support, and fully reentrant DLL entry points. (so it doesn't needlessly depack itself over and over)

Atm I am trying to debug a nice (as in, interesting and hard) test case with DLLs with TLS. For some reason there is one flaw there, but other DLLs with TLS callbacks work fine. Dunno if its something to do with reentrancy though.

Do not share outside EXETools.com, otherwise development will cease.

Updated:
* removed asmjit, replaced with Xbyak.
* added DLL reentrancy.
* saved bytes in entrypoint, down to 34 bytes.
* removed aplib (lzss based), replaced with a lz77+arithmetic coder backend:
double the depacker size (around 360 bytes compared to 160 bytes for aplib), yet a much improved compression ratio, nearing the private packer builds compression ratio in some cases, which uses LZMA.

you can't avoid it,the only way is to share it with private people that you trust with in.

True, but I can ask for some common basic human decency?

I guess that is too much to ask for? If thats the case, might as well stop dev already. So far I haven't noticed any leaks which is nice, hopefully it stays that way, otherwise development can go back to being completely private.

i'm afraid it's not anymore a world to expect that,you may trust in me as i think like you but it's not the place to expand psychology :)

regards!

There are so many retarded people in the RE forums that it will sell your program in a few minutes after you put on public. The time teach me that some users are present including this site.
So NO do not ask for that.
:)

Unfortunately that is a little too true... Brutal... But too true :(

Yep, as proven by the most recent leak and using download credits on some website (so in practise, it being sold)....
So instead, will stick to people that I know and trust, like what was done a few months ago.
At least with that, might as well experiment with taggants too down the track.

From past experience the "developers" will take your program and edit the resources to wipe your name and put his on credits and sell your thing as his.
Many of my scripts was selled too for hundreds of EUR even i put them on sites for free.
This happened with CodeCracker tools and many other developers work.
So for me is a strong "NO" for put for free my work because i know what will happen next.
:)

In that case, no point releasing the x64 port when its finished.

As a direct response to the leaker, I have documented the main depacker internals. I might do a static unpacker, too.

I have no intention of obfuscation at all. Being transparent should be a goal of any ethical programmer. Hopefully this stops any ideas of people using the packer to pack malware.

Updated:

* better error handling when handling invalid files (already mupacked files, .NET assemblies, x64 files).
* tested post packing digital code signing.

Nice tool

Dragging an executable on mupack_pub.exe won't start packing.
Packing section take some time, at first i thought it freezes during while loop or something, it would be nice to have some text like "Wait...Packing" while packing.
Also what about merging all section into one section ? no options tab ?

About Compression ratio: Have you done some exe packer comparison with similar tools ? (uPack/XPack/MEW/..)

Nice idea, I should add commandline support.

Another nice idea, I'll add that.

Merging all sections would take a rewrite, although it should help compression ratio. I didn't see the need for a options tab, what options should there be? :)

No, I should though.

blog seems down chief, also firefox reports the site as serving malware... if i tell it to ignore it i get a 404 on the link you posted for the 'response' ... kinda sucks someone leaked, i know what that feels like.. really makes you question the motives of some people

Yah, Google in thier infinite wisdom blocked my site thanks to some false positives on some demos & files I coded, because I used a packer. And its impossible to get them to unblock because the review process seems to be entirely automated.

I tried working around it by setting Apache settings to make http://mudlord.info/blog usable instead, but that broke Wordpress entirely.

At least now the people at the taggant team have a PDF of the depacker internals, hopefully they can spread it amongst the cabal so they can autodepack it like UPX.

@mudlord you could try setting a subdomain with some aliasing, but chances are google blocked your entire domain range :)

automated blacklisting is a recipe for disaster...

There are many:
Strip TLS
Strip Reloc
Strip Debug
Strip Delphi Resources
Don't compress resource
Preserve Overlay
Merge Sections
Compression Algo
...

I know, but I proved it happened: Managed to unblacklist my site just by password protecting ZIPs/RARs with packed files.

Some executables might need it.

Might be needed for some executables, mandatory for DLLs.

Useful feature to strip. Will have to do some research to see which section debug data is stored in.

Could you elaborate?

Better yet, selectable section compression.

Overlay preservation is a feature I must add, especially when there is plenty of Flash games around these days.

Would like to add. Would need to experiment with some things, such as the rebuilt resource section after resources compression.

Private build already does this dynamically depending on the file size. It also does better compression with the default compression algorithm. But whats in there currently thats public is already pretty good as it. It sure beats LZO/aplib/zlib/LZ4/lzss. I have some ideas to further improve the compression algorithm though, but I got a private x64 rewrite in progress though.

Strip VCLAL and PACKAGEINFO resources
Nice, so that's why it's one file drop pack and Go :)

Thanks for the info.

Yes, the private build uses a high compression variant of whats in the public build as well as LZMA1. LZMA2 wasn't chosen since thats just 7z related, and not compression algo related. It changes on the fly since LZMA works well on files on large file sizes whereas the LZ77+range coder works well on small-medium file sizes. There is also a tradeoff when using the HC variant of LZ77+range coder, in terms of speed, so thats taken into account too. I'm quite proud of that.

Have you tried alternatives to LZMA by any chance?

LZMA1 seemed to be one of the best, if not the best for compression ratio vs decompressor size.

Started work on dj-siba's requests, next version will have at least commandline support for integration into MSVC and other things.

Updated:

* Added commandline support.

Updated:

* Hack around commandline issues.
* Fixed bug on displaying depacker stub size.

The last 2 version does not work in windows xp.

It prompt exe is not a valid win32 application.

im not on xp , but try.

ref
https://supportxpdotcom.wordpress.com/2012/03/30/editbins-dirty-little-secret/

Updated:

* Fixed compiler flags to work on XP again, sorry about that.

Also you could change MajorLinkerVersion to 0E, MajorOperatingSystemVersion to 5, MinorOperatingSystemVersion to 01, MajorSubsystemversion to 5 and MinorSubsystemversion to 1 inside optional header to make it run on xp.. Although this solution is not really needed.. it's another way :)

To me its preferred if its done upstream, like its supposed to be. It was meant to be fixed, as it was a bug after all.

Setting:

[a] peHeader.MajorOperatingSystemVersion = 5;
[b] peHeader.MinorOperatingSystemVersion = 1;
[c] peHeader.MajorSubsystemVersion = 5;
[d] peHeader.MinorSubsystemVersion = 1;

would make a binary run under XP, although setting only [a] and [c] should suffice...
Having the source, however, mudlord's is the way to follow.

For those that care, released the source code to the current public and private versions of the packer.

What made you change your mind about releasing the source code? I thought that you said that it won't happen.