pouët.net

That's true of course, but that's up to ryg now. As far as I can remember he once mentioned that the code is not polished to be released to the public, but I might be wrong. I agree that it'd be a great thing to see new kkrunchy versions.

yep, me too :)

as possible (exe < 65.536) I'm tried to use the classic kkrunchy because it's the fastest to depack exe among all others packer.
If the filesize is > 64k I'm using the "k7" version or the mighty (but very slow) apk2.

@ham said:


I hope not, it's still my favourite demo format :(

The problem with releasing source code, whether crappy or not, is that if it's interesting enough, you WILL get feature requests, support requests and all kinds of looney e-mails. I've released my (simple and uninteresting) sources for the last few demos that I have made, encouraged people in my seminars to contact me and I've gotten quite a lot of mail about them, including a few demands that I fix certain stuff or implement XYZ so that they could copy it. One socially very challenged person even sent me horrible flame mails after I refused to rewrite some of my stuff for him so that it would fit his own engine well. The world is full of loonies and it's just might not be worth the trouble. I intend to keep open sourcing everything though.

I imagine ryg and kb already receive feature requests and bug reports, and I suppose this number won't increase if they release the source code.

Preacher: if you "encourage people in [your] seminars to contact [you]" it's no surprise you actually get mails. With a more dissuasive message (kb knows how to write them), you shouldn't get much emails.

But you're right, it's really sad to get such reactions. :(

I have nothing against reactions or people contacting me for discussion or coding help (that part I enjoy), but I have a lot against people who make unreasonable demands and believe that because you released something to the public, you're somehow responsible for filling their needs. I like the "I can't be bothered to do XYZ myself so I'll just ask the guy who wrote something similar" attitude even less.

Thankfully, only a very small minority of my correspondence is like this :)

:-) that's the spirit, my friend. Most readers don't write, anyways (but hopefully release a nice demo instead someday!)

(...+ greetings to loonies, of course..)

You are more than welcome to code your own exe packer.
Ryg already released the most important part (the filter), and there is plenty of sources around that show how to resolve the IAT manually, etc.....:O

btw I got one more question for you boys.

Like a polite little boys I write "#define WIN32_LEAN_AND_MEAN" at the beginning of my code but I really don't know if I have too or if it does something, I just heard (or read somewhere) that it do not load some "windows unknown things" so the code can be smaller.

But I really don't know, someone can explain me? :D
(or give me a link where it's explained well).

Hint from Captain Obvious: Use Google and click one of the first five links.

Mudlord: Where can we find those sources? I've been looking for a PE parser/loader/builder source a bit and the only stuff I can find is either UPX source which is rather bloated and another one which is outdated and dysfunctional: http://www.cultdeadcow.com/tools/pewrap.html
Also found some info here: http://securitylabs.websense.com/content/Assets/HistoryofPackingTechnology.pdf

preacher: frustration leads to insanity :) unfortunatly most open source projects due to lack of proper testing, documentation and dedicated support end up being extremly frustrating for others to use :) just giving 2 cents into an explanation, not saying i agree with the behavior at all :)

yomat:
try looking for sources to:
* Yoda's Protector/Cryptor
* PeX
* Packman
* sePACK
* TitanEngine

Mudlord: Thanks!

Nice article and the packer works albeit weak compression ratio:
http://www.programmersheaven.com/2/PE-Protector
Requires external compression library but might be useful anyway:
http://packmanpacker.sourceforge.net/
Clean source and good idea but refused to pack my project:
http://en.sourceforge.jp/projects/sfnet_sepacker/releases/
Assembler source in pex.zip archive near the bottom:
http://xtreeme.prv.pl/

Might as well push a couple of more links on ya'll:
http://fgiesen.wordpress.com/2011/01/24/x86-code-compression-in-kkrunchy/
http://cs.fit.edu/~mmahoney/compression/

Yah, look at def by bart as well :)
Quite neat source on basic encryption (if you call shit like XOR encryption)

Compression ratios can be improved by prefiltering x86 code. Ryg already posted working code, all thats needed is x86 versions of disfilter. Or you could decompile disfilter and just use IDA Pro to help write up a assembler implementation.

I am having *decent* results using aplib for compression. LZMA is proving problematic because the LZMA code from Packman doesn't respect the fucking stack. Which means from my code, its a bitch to use. Better off rewriting it but not too motivated to do that......

1kpack is nice for ideas. You can still use ZLIB and make a import table entry for d3dx_30.dll for unpacking.

I'd strongly recommend reading this:
http://www.ntcore.com/files/inject2exe.htm

Explains all the details on code injection via inserting sections, as well as how to respect the TLS callbacks, which is vital for Delphi/Borland C++.

oh forgot:
http://mordor.in/

more PE packer sources.

"Def by Bart" proved to be difficult search criteria. :P

Thanks for the links! I'll keep reading. Although this is in the backburner. I want to make something to pack first and foremost!

1kpack. Very interesting for step-wise packing.

Also I had the infamous 'Randomized Base Adress' active so everything kept crashing for me. sePACK actually packs the exe now but it crashes when I try to run instead (win7). Might have that as a first project: Fix sePACK.

For those who wondered about aplib:
http://www.ibsensoftware.com/download.html

Sitrep:
for me, most targets compress.
Having issues working out the base resource address for some targets. Which seems to be needed for correct compression of resources....

Well, could be worse. a 660KB EXE down to 152 just using aplib.