Developing PE file packer step-by-step. Step 8. DLL’s and exports

Previous step is here.

Our packer can do almost everything already, except one thing - packing binaries with exports. This, in particular, is an absolute majority of DLL files and OCX components. Some EXE files also have exports. Our packer should rebuild export table and place it to available space, to make it accessible for the loader.

We can relax a bit for now - we have to add just a small amount of code to the packer (generally, the same for the unpacker, but it will be in assembler).

Continue reading "Developing PE file packer step-by-step. Step 8. DLL’s and exports"

Developing PE file packer step-by-step. Step 6. TLS

Previous step is here.

It's time to manage such important thing as Thread Local Storage (TLS). What is it? It is a small structure, which tells PE loader where it has to place the data which should be allocated for each thread. The loader also calls TlsAlloc, and the return value is stored at the address specified in this structure (this is called index). Besides that, this structure may contain address of an array storing a set of callbacks (function addresses), which are called by loader when the file is loaded into memory or when a new thread in process is created.

To be honest, working with TLS will be somewhat more hardcore, than it was with other things, so get prepared and strain your brain. My old packer I mentioned one or two steps ago don't support TLS callbacks, it notifies cowardly that they exist but they are not processed. Basically, this is a reasonable behaviour, as TLS callbacks are contained mainly in rather weird files, which use them as anti-debugging trick. There is no regular linker like Borland or Microsoft linker, with TLS callback creation support. However, we will add their support to make our packer cool.

Continue reading "Developing PE file packer step-by-step. Step 6. TLS"

Developing PE file packer step-by-step. Step 3. Unpacking

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"