That graphic should explain the structure and nesting adequetly. If you need more of a reference
search the msdn site for the full PE specification. They have a very comprehensive pdf on it although it
is quite dry.
If you are to write any kind of import restoration tool you will have to understand it fully. To drill it into your mind, I would recommend finding a small target exe and opening it up in LordPE and a hexeditor at the same time. Use the hexeditor to navigate the structures and LordPE as reference on field values.
Even after all of that and writing a PE editor utility myself i still felt like i had to create that graphic in order to get a full sense of the nesting and layout. Dont worry it just takes time.
So, Lets say we have a packed executable... (with a packer that does not use API redirection for simplicity sake)
What information do we need to restore the import table of the app? To answer just this question i have put together a small download package consisting a very simple exe with only two imports. This file was compiled with fasm and simply displays a messagebox and then exits.
First thing we do is load it up in olly and search for all intermodular calls, we come up with the following:
0040103A CALL DWORD PTR DS:[40207A] USER32.MessageBoxA 00401042 CALL DWORD PTR DS:[40205C] KERNEL32.ExitProcessFrom this we really have everything that we need to build the import table from scratch. We know that the pointer for USER32.MessageBoxA must sit at offset 40207A and the one for KERNEL32.ExitProcess must be found at 40205C for this app to work properly. This seems simple enough, the only trick being that it is a rather complex structure to create to get the Windows loader to find all of the strings and load the dlls properly.
Lets now look at a packed version of this same app to see what the packer changed. The packer we used for this example was telock without using the API redirection option. The easiest way in, is to let the telocked sample run until it shows the messagebox and then attach to it. By this time, all debugger checks have already run and you know that it is paused in the main applications code. Once inside, you will be paused in ntdll, press ctrl-g and enter 401000 to jump to the main applications code. Now you can search for intermodular calls again and see all of the apis and how they are called:
0040103A CALL DWORD PTR DS:[40207A] user32.MessageBoxA 00401042 CALL DWORD PTR DS:[40205C] kernel32.ExitProcessThis is exactly as it was in the original exe. If you open up the raw dump file provided in LordPE and list the Import table you will find that telock wiped the structure andit is not present. What we need now is a way to reconstruct the complex structure of the import table in the binary so that these dlls are loaded by the windows loader and the pointer values to the functions appear at the right offsets the linker was originally expecting.
Of course the best way to do this is to use that graphic i created and the PE specification from MS and manually recreate the structures in your trusty hex editor. Even for such a simple exe it is a lengthy process but trust me it is worth it and this is one of the simplest exes you will find as a trainer so give it a shot.
Seeing how manually rebuilding the tables in a hexeditor is to lengthy of a process to do manually it is time to seek out some automation to help you rebuild the import table. For this I create a simple tool that allows you to build an import table from scratch and control all aspects of it. There are some other automated tools out there for this task but I wanted to try to design my own. As a bonus, I am also releasing it open source so that you can see how it was done and modify it to suit your needs.
In the download package linked below you will find all exes mentioned throughout this paper as well as the impreb tool and source. The readme in the package will take you through the steps on how to use the tool to rewrite the import table of the sample dumped exe. This tool should also come in handy if you wanted to hack new functionality into a compiled exe. It should be able to be used similar to iidKing in this respect to add new dlls to the import table. Note this is a very bare bones first shot implementation of a tool for this purpose. There is probably more stuff to come as i get time.
A couple last notes i should probably throw in just for reference. This paper is primarily about understanding the import table layout and rewriting it from scratch. I did not highlight all of the steps necessary to take a memory dump and fix it up, that just provided a nice example for something that needed its import table rebuilt.
The last thing worth mentioning is that some packers use what is termed api redirection techniques. From the mechanism outlined above you now know that the linker only cared that a Call[ptr] value eventually leads to the right api. If the packer wants to hide the actual apis from you...all it has to replace that pointer so that the call leads execution into its own little messed up thunk which after some junk operations and math will usally decode the real pointer and jump there. This is an interesting topic so I will include a sample of telock api redirection mechanism below:
00740016 -FF20 JMP DWORD PTR DS:[EAX] ; user32.MessageBoxA 00740018 90 NOP 0040103A FF15 7A204000 CALL DWORD PTR DS:[40207A] ;40207A used to hold normal ; pointer to Messageboxa ;now jumps to 740000 00740000 EB 02 JMP SHORT 00740004 00740002 CD 20 INT 20 00740004 EB 02 JMP SHORT 00740008 00740006 db B8 ;anti-disasm junk 00740008 3D 8500FF20 CMP EAX,20FF0085 ;\ 0074000D B8 735ECF00 MOV EAX,0CF5E73 ; \__anti-heuristic junk ? 00740012 98 CWDE ; / 00740013 8BC5 MOV EAX,EBP ;/ 00740015 B8 21007400 MOV EAX,740025 ;address real pointer was moved to 0074001A FF20 JMP DWORD PTR DS:[EAX] ;DS:=77E36544 (user32.MessageBoxA) 0074001C 90 NOP ; \ 0074001D B8 20000000 MOV EAX,20 ; /--- junk 00740022 0000 ADD BYTE PTR DS:[EAX],AL ;- 00740024 004465 E3 ADD BYTE PTR SS:[EBP-1D],AL ;\_ actual pointer val not opcodes 00740028 77 00 JA SHORT 00740026 ;/ cant disasmAnyway...it will probably some time to wrap your brain around it all..but its fun stuff so just play with it :P