mupack

[giv]

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

0049A000 m>  BB 00000000           MOV EBX,0x0
0049A005     E9 03000000           JMP mupack_p.0049A00D
0049A00A     C2 0C00               RETN 0xC
0049A00D     8D83 00A04900         LEA EAX,DWORD PTR DS:[EBX+<ModuleEntr>
0049A013     53                    PUSH EBX
0049A014     50                    PUSH EAX                              ; mupack_p.0041F394
0049A015     8D83 7EA04900         LEA EAX,DWORD PTR DS:[EBX+0x49A07E]
0049A01B     FFD0                  CALL EAX                              ; mupack_p.0041F394
0049A01D     8D83 94F34100         LEA EAX,DWORD PTR DS:[EBX+0x41F394]
0049A023   - FFE0                  JMP EAX                               ; mupack_p.0041F394

[mudlord]

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.

[mudlord]

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.

[bolo2002]

Originally Posted by mudlord

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

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

[mudlord]

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.

[bolo2002]

Originally Posted by mudlord

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

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!

[giv]

Originally Posted by mudlord

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

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.

[CryptXor]

Originally Posted by giv

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