Previous step is here.
Let’s continue! It’s time to write an unpacker, this is what we are going to do during this step. We will not process import table for now, because we have some other things to do at this lesson.
We will begin from the following thing. To operate, the unpacker definitely needs two WinAPI functions: LoadLibraryA and GetProcAddress. In my old packer (that I’ve written once) I developed unpacker stub in MASM32 without creating import table at all. I looked for these function addresses in kernel, which is rather complicated and hardcore, besides that, this may cause serious antivirus suspicions. This time, let’s create import table and make loader to tell us these function addresses. Of course, set of these two functions in import table is as suspicious as their total absence, but nothing prevents us from adding more random imports from different .dll files in future. Where will the loader store these two function addresses? It’s time to expand our packed_file_info structure!
Continue reading “Developing PE file packer step-by-step. Step 3. Unpacking”
Previous step is here.
Straight off I want to say that as I write this series of articles I fix some things and update my PE library (Note, that this step is for 0.1.x versions, too).
And we continue to develop our own packer. At this step it is time to turn directly to PE file packing. I shared a simple packer long time ago, which was ineffective by two reasons: firstly, it uses standard Windows functions for data packing and unpacking, which are rather slow and have low compression rate, secondly, all PE file sections were packed individually, which is not very optimal. This time I will do this differently. We are going to read data of all sections at once, assemble them into one block and pack. So, the resulting file will have only one section (actually two, I will explain this later), we can place all the resources, the packer code and helper tables into it. This will provide some benefits, because we don’t need to spend space for file alignment, besides that, LZO algorithm is much more effective than RtlCompressBuffer in all respects.
Continue reading “Developing PE file packer step-by-step. Step 2. Packing”
Since I completed portable executable C++ library development, it would be totally wrong not to use it in any more or less serious project. Thus I am going to develop a packer with step-by-step explanations of what I am doing, and C++ library will make our life easier. So, where do we start the development? Maybe, from choosing some free simple compression algorithm. After short search I found such one: LZO. It supports lots of compression modes, and LZO1Z999 is the most effective by compression ratio of all available. Of course, it is not like ZIP, but its performance is close: 550 Kb file was compressed to 174 Kb with zip with maximum compression level, at the same time LZO compressed this file to 185 Kb. However, LZO has much more fast unpacker. It is also base-independent, that means, it can be placed at any virtual address and it will work without any address corrections. This algorithm will be right for us.
Continue reading “Developing PE file packer step-by-step. Step 1”