How would I do Export Address Table (EAT) Hooking?
I'm able to do IAT (Import Address Table) hooking.
Can someone give me a example?
Thank You!
EAT hooking follows a very similar method to IAT hooking, the major difference is a change in where you look, have a look at the PE File Exports section of the Win32 PE format.
A very simple (although in C) example can be found here, just compile and disassemble if you really need it in assembly form.
Related
First of - Hello and thank you for reading this,
I have one DLL which I do not have the source code but need to add some functionalities into it.
I made up another DLL implementing all these needed functionalities in C - using Visual Studio.
Now I need to insert the generated code from this new DLL into the target DLL (it has to be done at the file level {not at runtime}).
I am probably creating a new PE section on the target DLL and put there all the code/data/rdata from the dll I made up. The problem is that I need somehow to fix the IAT and the relocs relative to this new inserted code on the target DLL.
My question is:
What is the best way to do it?
It would be nice if Visual Studio came up with an option to build using only (mostly) relative addressing - This would save me a lot when dealing with the relocs.
I guess I could encapsulate all my vars and constants into a struct, hopefully MSVC would then only need to relocate the address of this "container" struct and use relative addressing to access its members. But don't know if this is a good idea.
I could even go further and get rid of the IAT by making a function pointer which would dynamically load the needed function module (kind of the Delay Load Module). And again, put this function pointer inside the "container" struct I said before.
The last option I have is to make it all by hand, manually editing the binary in hex... which I really didn`t want to do, because it would take some good time to do it for every single IAT entry and reloc entry. I have already written a PE file encryptor some time ago so I know most of the inner workings and know it can be done, just want to know your thoughts and maybe a tool already exists to help me out?
Any suggestions is highly appreciated!
Thanks again for your time for reading this!
Since you are asking for suggestions, take a look at the very good PORTABLE EXECUTABLE FILE FORMAT – A REVERSE ENGINEER VIEW PDF Document. The Section "Adding Code to a PE File" describes some techniques (and presents Tools) to add code to an existing PE image without having the code of the target image (your scenario) by manipulation the IAT table and Sections tables.
I just changed from (F)ASM to C and saw that I get for a MessageBox 25kb (vs 3kb). I just included windows.h, but I see that windows.h includes about 22kb that I don't need ;).
At ASM I'm able to define the IAT (Import Address Table) and this I want to do with the GCC to reduce the oversized executable.
SO does anyone know how I can do this? Is it possible?
PS: If you know a solution for an other compiler please post it too (then I'll use the other one).
OK because I can't find any way to do it, I read about shell code (which has to be small and position independend).
harmonysecurity.com wrote about this and so I would solve my problem with inline-ASM.
This is the blog.
I hope that helps.
I've been looking recently into creating a new native language. I understand the (very) basics of the PE format and I've grabbed an assembler with a fairly kind interface off the webs, which I've successfully used to implement some simple functions. But I've run into a problem using functions from a library. The only way that I've called library functions from a dynamically compiled function previously is to pass in the function pointer manually- something I can't do if I create PE files and execute them in their own process. Now, I'm not planning on using the CRT, but I will need access to the Win API to implement my own standard libraries. How do I generate a reference to a WinAPI function so that the PE loader will patch it up?
You need to write an import table. It's basically a list of function names that you wish to use in your application. It's pointed to by the PE header. The loader loads the DLL files into the process memory space for you, finds the requested function in their export table and leaves the address for it in the import table. You then usually dereference that and jmp there.
Check out Izelion's assembly tutorial for the full details and for asm examples.
How about starting by emitting C instead of assembly? Then writing directly to ASM is just an optimization.
I'm not being facetious: most compilers turn out some kind of intermediate code before the final native code pass.
I realize you're trying to get away from all the null-delmited rigmarole, but you'll need that for the WinAPI functions anyway.
Re-reading your question: you do realize that you can get the WinAPI function addresses by calling LoadLibrary(), then calling GetProcAddress(), and then setting up the call...right?
If you want to see how to bootstrap this from pure assembly: the old SDKs had ASM sample code, probably the new ones still do. If they don't, the DDK will.
Dependency walker (depends.exe) shows a 'Hint' column for exported functions. As far as I understand the Portable Executable format, exported functions do not have hint. Can someone tell me whether or not exported functions have hint? Actually, only imported functions should have hint..
I finally found the answer to my question...:
In dependency Walker (as well as in Dumpbin), the "Hint" is the position of the Exported Function in the EAT (Export Address Table)! This position has been named "Hint" since the the Loader will use this position when searching for the Functions from the IAT (Import Address Table). As, simple as that!
thanks.
Apparently not - see here. I suspect Dependency Walker is calculating the hint for the export 'to be nice'.
I've been looking into the implementation of a device library that doesn't explicitly support my operating system. In particular, I have a disassembled DLL, and a fair amount of supporting source code. Now, how is the function table/export table structured?
My understanding is that the first structure of the .data section is a table of RVAs. Next is a table of strings linked by index to that first address table. This makes sense to me, as a linker could translate between symbols and addresses.
How do functions referenced by ordinals fit into this picture? How does one know which function has such and such ordinal number, and how does the linker resolve this? In other words, given that some other DLL imports SOME_LIBRARY_ordinal_7, how does the linker know which function to work with?
Thanks, all!
edit
More information...
Im working with the FTDI libraries, and would like to resolve which function is being invoked. In particular, I see something like:
extern FTD2XX_Ordinal_28: near
how might I go about determining which function is being referenced, and how does the linker do this?
To learn how the linkers and the loader works on Windows, probably the most accessible information comes from a set of columns Matt Pietrek did more than a decade ago:
July 1997: http://www.microsoft.com/msj/0797/hood0797.aspx
April 1998: http://www.microsoft.com/msj/0498/hood0498.aspx
September 1999: http://www.microsoft.com/msj/0999/hood/hood0999.aspx
And the biggest and best one:
Peering Inside the PE: A tour of the Win32 Portable Executable File Format (from 1994!)