Admiral
January 3rd, 2005, 15:14
I was reading into IAT reconstruction of Armadilloed binaries recently when I came up with an idea I haven't been able to shake since. I'm fairly sure that I am misunderstanding something or other and so I don't want to go to the effort of coding the following dumper/fixer without being at least nearly sure that it won't be a total waste of time.
As I understand it, the IDATA section is a part of the (disk) executable header that tells the operating system which DLL imports to load, and the IAT is the part of the (memory image) header into which the OS loads all of the addresses. Many modern packers will pack the whole subject file including the header, and when executed, will unpack the whole file, step through its IDATA section filling in the IAT manually before/while destroying all the evidence in the IDATA area.
If this isn't right so far, then perhaps I have the wrong end of the stick entirely.
My problem is the apparent simplicity with which this IDATA section could be reconstructed. My conceptual panacaea program would attach itself to the target app once it has been unpacked; dump the relevant sections, then scan the code area for CALL commands that point to memory locations known to be imports. It will keep a record of all such CALLs, noting all relevant details before going on to redirect them in the dump as necessary and manually adding the entries into the IDATA section of the dumped PE header. Failing that, more elegant examples exist in which the app is loaded as a debugged process and all calls to LoadLibrary are logged etc etc.
If this was possible then surely somebody would already have implemented it, so what am I missing?
As I understand it, the IDATA section is a part of the (disk) executable header that tells the operating system which DLL imports to load, and the IAT is the part of the (memory image) header into which the OS loads all of the addresses. Many modern packers will pack the whole subject file including the header, and when executed, will unpack the whole file, step through its IDATA section filling in the IAT manually before/while destroying all the evidence in the IDATA area.
If this isn't right so far, then perhaps I have the wrong end of the stick entirely.
My problem is the apparent simplicity with which this IDATA section could be reconstructed. My conceptual panacaea program would attach itself to the target app once it has been unpacked; dump the relevant sections, then scan the code area for CALL commands that point to memory locations known to be imports. It will keep a record of all such CALLs, noting all relevant details before going on to redirect them in the dump as necessary and manually adding the entries into the IDATA section of the dumped PE header. Failing that, more elegant examples exist in which the app is loaded as a debugged process and all calls to LoadLibrary are logged etc etc.
If this was possible then surely somebody would already have implemented it, so what am I missing?