IAT Emulation & Redirection

[yogi_saw]

Hi friends
most often I have heard of IAT Emulation & Redirection but searching lot could not make me understand them clearly...
I would really appreciate if somebody could point me or post more info on this
and also the ways to remove IAT Emulation & Redirection and difference in both techniques

[Kerlingen]

Since I don't know how much you know about IATs, I start at the very beginning.

The IAT contains pointers to functions imported from other DLLs. Since the DLLs will most likely use a different address each time they are loaded, it's not possible to call a function exported from a DLL directly by it's address.

For example, "KERNEL32.dll" exports "CreateFileA". In the EXE file the IAT is a table which tells the OS loader which DLLs should be loaded before executing the EXE and which functions the EXE needs to be able to run.

An IAT entry contains 5 dwords. One of them is a pointer to the string "KERNEL32.dll", an other one points to a list of pointers with function names. One of the pointers in this list points to the string "CreateFileA".

When the OS loads the EXE file into memory, it also loads the "KERNEL32.dll". When it is loaded, it scans the DLL's export table to find out at what memory address the function "CreateFileA" is currently loaded. If the "KERNEL32.dll" for example was loaded at memory address 0x10000000, then the address of "CreateFileA" might be 0x10047820. So when the OS loader has found the memory location of the imported function, it replaces the pointer to the string "CreateFileA" with the current memory address 0x10047820.

When the EXE now wishes to call the function "CreateFileA", it just calls the pointer from the list of imported functions, since it will point to the correct memory address of the function.

Since this pointer now points to 0x10047820, any tool which tries to rebuild the original IAT knows that the pointer points somewhere into "KERNEL32.dll" memory, so it will be an import from this DLL. It also can find out that the memory location "DLL base + 0x47820" belongs to the export "CreateFileA". So it can rebuild the IAT. Together with a dump of the EXE which was made at OEP we now have a fully working EXE file again.

IAT Redirection

Protectors try to prevent rebuilding packed/protected EXE files. One thing they do to prevent this is IAT redirection. This means the protected EXE has no information any more telling the OS loader that it wishes to import "CreateFileA" from "KERLNEL32.dll". Loading the DLL and finding the correct memory address of "CreateFileA" is now done completely by the protection code.

Since the protector wants to prevent IAT rebuilding, it just builds some own code which it inserts into the import table of the EXE. So when the EXE tries to call "CreateFileA", it will not call 0x10047820, since it doesn't know this information. It will call the memory location which the protector has created and inserted into the import table.

The code the protector created will finally jump to the real code of "CreateFileA" somewhere, but first it will execute some or even much trash code which does nothing. The reason behind this is that an import rebuilding tool is now missing the two things it needs to know in order to rebuild the import entry. First it will not know any more that the function which is executed belongs to "KERNEL32.dll" address space, since the code address will be some address outside of any DLL. Second it will not know which function is called at all, since the protector code tries to hide this information as good as possible.

IAT Emulation

While IAT redirection is a good thing to fool IAT rebuilding tools, it has one major problem. After all memory redirecting and trash code the protector always has to call the original code somewhere. This means somebody could just set a breakpoint on all functions, call the protectors fake code and would still see which function is called in the end.

This is where IAT emulation comes. As the name suggest, the protector doesn't call the original "KERNEL32.dll" function any more, but completely emulates what it does. For a complex function like "CreateFileA" this is nearly impossible, since any Windows version, any service pack or any security hotfix might change the internal workings of the function. But there are some functions which can be emulated better.

One example would be "GetVersion". The function just returns the current Windows version in EAX. The protector could just call "GetVersion" once, store the return value and create a new function which only returns the correct value in EAX, but never calls the original "GetVersion" code inside "KERNEL32.dll". Any IAT rebuilding tool would fail to restore the "GetVersion" IAT entry, since it has no clues where it is called.

But since the number of functions which can be emulated without breaking compatibility with past and future Windows versions is limited, it is still easy to rebuild the few IAT entries which the rebuilding tool wasn't able to restore by hand.

[yogi_saw]

WOW amazing info, I really wanted to know this...
few questions although
1) what the tracers (level1,2,3) in ImpREC exactly do?
2) how to find redirected api if tracers could not trace them
3) how to find the emulated APIs?
thanks for the information, I never knew I would get such wonderful information in first answer.

[Kerlingen]

1.) As far as I remember, lvl1 tries to find the correct API by disassmbling the code and looking for some jump to the original API. lvl2 and lvl3 single step the protector's trash code until they end up somewhere in a loaded DLLs code section, which will most likely be the correct imported function.

2.) Write some tool by hand which finds the correct APIs or prevent the protector from redirecting the imports at all (must be done somewhere deep in the protector's code, while it is still decrypting and unpacking the code).

3.) Since there are very few possible emulated APIs, they are the ones left when all other imports where rebuild. You have to manually look at them in a debugger or disassembler and guess what they do.

For example, if you're running Windows 7 build 7600, the return value of GetVersion will be "0x1DB00106" (version 6, subversion 1, build 0x1DB0 (7600 decimal)). So if you see some code which does only "MOV EAX, 0x1DB00106; RET" (maybe inside of some trash code), it is likely that you've found the emulated "GetVersion" call.