Coding a packer stub in C++

[rendari]

Hello all,

While I've created packers for Windows before, they've all been in assembler. Right now I'm thinking of how to code a packer stub for windows in C++, and am stuck. Has anyone done this before and have any tips? Have any articles been written about this?

I have a couple of ideas on how to do this, but they're all really nasty. One involves building the stub as a DLL, and appending it to the exe as a new section. Set Import Table in PE header to point to the import table of the appended DLL. Also you will need to manually fix all the relocations in the DLLs code section. This might work, but I imagine there would be nasty problems.

Option 2 is to have an assembler stub that loads a DLL appended as an overlay to the exe. ARTeam wrote an excellent article on manually loading DLL files from memory, so I know this is possible. Still, I would like to avoid rewriting all of ARTeam's code in assembler.

So, anything that I'm missing?

-r

[JohnWho]

Set Import Table in PE header to point to the import table of the appended DLL.

DLL...

[hmi222]

have a look here:

https://github.com/farbrausch/fr_public/tree/master/kkrunchy

or

https://github.com/farbrausch/fr_public/tree/master/kkrunchy_k7

[metr0]

Rendari, you are still around?

I did a protector in C++ with some bit of inline assembly (could be replaced by intrinsics, if you're going for pure C++). I think you already know BigBoote's concept? Feel free to PM me, but the overall concept is still pretty doable even with modern C++ compilers.

[Zer0Flag]

You could take a look at dynamic forks also RunPE called and often used in malware to load binary files from memory into a process. Protection features could be done with self debugging..

I will soon release a little protector using this method as opensource.

~Zer0Flag

[metr0]

Mind you that he wants to code a packer, forking would involve a considerable amount of overhead.

[Zer0Flag]

The Stub I created has currently about 3,8kb ( including debugger and some protection features so this could be optimized for a packer only). Sure in asm it would be less but I think its not that bad. Using RtlCompressBuffer I get the win7 cmd.exe from about 300kb to 133kb.

@rendari if you want I would send you the project without the protection features to learn from this.

~Zer0

[metr0]

Yes, my point was that he did not seem to aim for protection features at all. But that I cannot be sure of, he only said he wanted to code a packer. Compressing code and having a smaller stub surely beats this. No offense, I'm just stating options.

[rendari]

Rendari, you are still around?

I did a protector in C++ with some bit of inline assembly (could be replaced by intrinsics, if you're going for pure C++). I think you already know BigBoote's concept? Feel free to PM me, but the overall concept is still pretty doable even with modern C++ compilers.

Hey metr0,

Yes I'm still alive and reversing, just not posting as much as I used to. Lost the will...

I ended up appending the encrypted DLL to the exe as an overlay, and then loading it with a stub as offset-independent assembly in MASM. It works really well and is very flexible! I found Big Boote's article from long ago; I think this is the best one ever written on coding packers Right now I'm dealing with dodging the antivirus detections. Seems that they're not too happy if you encrypt the code section and add a stub that they can't unpack

Also, I should have been more specific: I am coding a protector (not a packer). I just want to add a wrapper and antidebug around some code obfuscation I've been working on. Sorry for any confusion! I tend to use the terms protector/packer interchangeably, without thinking about it.

@hmi222: Thanks for the link. Never seen that particular packer source!

@Zer0Flag: Sure I'd love to look at your code sometime. Or I could just wait til you open source it, no rush

Cheers,

-rendari

Edited August 27, 2012 by rendari

[metr0]

You can replace even that stub of MASM with C++, just saying. You could try the ASProtect method (in fact, you could actually use their entrypoint, it might be excluded from detections): let the OEP point to the first section, it being in the last triggers some nasty heuristics. Then overwrite your custom OEP with the compressed bytes and go on.

[JohnWho]

Well sorry for my idiotic post, i thought you wanted to point the import table directly to the appended dll

I'm also working on a pe packer/protector, perhaps we could exchange ideas

[mudlord]

The Stub I created has currently about 3,8kb ( including debugger and some protection features so this could be optimized for a packer only). Sure in asm it would be less but I think its not that bad. Using RtlCompressBuffer I get the win7 cmd.exe from about 300kb to 133kb.

@rendari if you want I would send you the project without the protection features to learn from this.

~Zer0

Wow, nice work, I would also like to see. When I was tinkering with my code, was around 5kb, including a NASM LZMA based decompressor. This DLL idea sounds interesting for a packer (would allow for experimentation with different compression methods including Zlib, which is heavy on C runtime libs), but I would imagine it will only yield decent returns if the host file is large enough? (eg for small exe's like anything under 100KB a pure ASM based packer still is best?).

Edited September 1, 2012 by mudlord