CodeBreakers Magazine

2 / 20

CodeBreakers Magazine – Vol. 1, No. 2, 2006
How to Write Your Own Packer
By BigBoote
Why write your own packer when there are so many
existing ones to choose from? Well, aside from making
your executables smaller, packing is a good way to
quickly and easily obfuscate your work. Existing well­
know packers either have an explicit 'unpack' function,
or there are readily available procdump scripts for
generating an unpacked version.
1 Intro
Why write your own packer when there are so many
existing ones to choose from? Well, aside from making
your executables smaller, packing is a good way to
quickly and easily obfuscate your work. Existing well­
know packers either have an explicit 'unpack' function, or
there are readily available procdump scripts for
generating an unpacked version.
Since this document has quickly exploded in length I'm
going to break it up into separate installments. In this
installment I will cover the qualitative aspects of
producing a packer. I'll discuss what you're getting into
and how the packer is structured in general. I'll briefly
discuss some pitfalls, and I'll give some links to technical
information you will need to be familiar with before going
into the next installments.
In the next two installments I'll go into details of how to
implement the components of the packer and how I
usually go about producing them.
2 What You're Getting Into
It's not really hard, per se, but it is rather tedious code.
Lots of pointer manipulation and translation to keep
track of. Aside from that, if you can write code to add and
subtract integers and do file IO, you've got all the skill
needed! As mentioned, it is tedious code so you will
probably do well to not attempt this coding on a
hangover; trust me, I know.
FYI, the last packer I produced was fairly fullfunctioned
(exes and dlls, several compression algorithms with
debug capability and advanced support such as TLS
(critical for Delphi apps)) and it weighed in at about 3700
lines for the packer tool and about 1000 lines for the
decompression stub it embeds in the target. That's
somewhere around 70 printed pages of code. So, not a
huge app, but not a tiny one either. The first one I
produced took about 1.5 weeks to produce including
research and bug fixing. Subsequent ones took far less
since I had already done the hard part, which is figuring
out how. Hopefully this document will save you that time
as well!
You do not have to use assembler for the most part. If you
can part with supporting some esoteric features, you
won't have to use it at all. All of that is relevant for the
decompression stub only anyway. The packer can be in
Logo or ObjectOriented COBOL if you like.
OK, enough of the blahblahblah, on to technical stuff....
3 Big Picture
Simple. Executable is analyzed, transformed, and an
extra piece of code is attached which gets invoked instead
of the original program. This piece is called a 'stub' and
decompresses the image to its original location. Then it
jumps to that original location. But you know this
already.
Sounds simple, but there are pitfalls that await you.
Some of these include:
• Support for simplified Thread Local Storage, which is
key in supporting Delphi applications
Support for code relocation fixups in dlls if you care
about packing dlls. Recall ActiveX controls are dlls
too, as are other common things you might be
interested in packing
• Support for some stuff that must be available even in
the compressed form. This includes some of your
resources and export names in dlls
Dealing with bound imports
• Support for stripping out directory entries that will
confuse the Windows loader since the decompression
won't have happened and they will point to nothing
useful, like the IAT and debug info
• Support for doing relocation fixups manually on your
decompression stub since it will certainly be in a
different memory location than where the linker
thought it would be when it was compiled
• Dealing with differences in interpretation of the PE
spec between different vendor's linkers. Borland
linkers interpret aspects of the spec differently from
Microsoft's so you need to be ready for that.
© CodeBreakers Journal,