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!)
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 would like to know any difference between ordinal and hint value in the native dlls? Anyone knows?
Ordinals can be thought of as the alternative (internal) name of a exported function (All exports have a ordinal and some only have the ordinal a.k.a. NONAME). They were common in 16-bit windows but not so much these days (The import/export tables are smaller if you don't include the "string name"). They are slightly faster for the loader to look-up and are often used for undocumented functions. The downside is that they might not be stable from release to release.
The hint is used by the loader as a shortcut into the dll export table, if the hint offset does not match the expected function name the normal search is used.
Take a look at An In-Depth Look into the Win32 Portable Executable File Format for more details about the different PE sections.
tools like dependencywalkers and PeStudio show the relation between ordinals and hints.
I need to port snprintf() to another platform that does not fully support GLibC.
I am looking for the underlying declaration in the Glibc 2.14 source code. I follow many function calls, but get stuck on vfprintf(). It then seems to call _IO_vfprintf(), but I cannot find the definition. Probably a macro is obfuscating things.
I need to see the real C code that scans the format string and calculates the number of bytes it would write if input buffer was large enough.
I also tried looking in newlib 1.19.0, but I got stuck on _svfprintf_r(). I cannot find the definition anywhere.
Can someone point me to either definition or another one for snprintf()?
I've spent quite a while digging the sources to find _svfprintf_r() (and friends) definitions in the Newlib. Since OP asked about it, I'll post my finding for the poor souls who need those as well. The following holds true for Newlib 1.20.0, but I guess it is more or less the same across different versions.
The actual sources are located in the vfprintf.c file. There is a macro _VFPRINTF_R set to one of _svfiprintf_r, _vfiprintf_r, _svfprintf_r, or _vfprintf_r (depending on the build options), and then the actual implementation function is defined accordingly:
int
_DEFUN(_VFPRINTF_R, (data, fp, fmt0, ap),
struct _reent *data _AND
FILE * fp _AND
_CONST char *fmt0 _AND
va_list ap)
{
...
http://www.ijs.si/software/snprintf/ has what they claim is a portable implementation of snprintf, including vsnprintf.c, asnprintf, vasnprintf, asprintf, vasprintf. Perhaps it can help.
The source code of the GNU C library (glibc) is hosted on sourceware.org.
Here is a link to the implementation of vfprintf(), which is called by snprintf():
https://sourceware.org/git/?p=glibc.git;a=blob;f=stdio-common/vfprintf.c
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.
I have a dll that I need to make use of. I also have a program that makes calls to this dll to use it. I need to be able to use this dll in another program, however previous programmer did not leave any documentation or source code. Is there a way I can monitor what calls are made to this dll and what is passed?
You can't, in general. This is from the Dependency Walker FAQ:
Q: How do I view the parameter and
return types of a function?
A: For most functions, this
information is simply not present in
the module. The Windows' module file
format only provides a single text
string to identify each function.
There is no structured way to list the
number of parameters, the parameter
types, or the return type. However,
some languages do something called
function "decoration" or "mangling",
which is the process of encoding
information into the text string. For
example, a function like int Foo(int,
int) encoded with simple decoration
might be exported as _Foo#8. The 8
refers to the number of bytes used by
the parameters. If C++ decoration is
used, the function would be exported
as ?Foo##YGHHH#Z, which can be
directly decoded back to the
function's original prototype: int
Foo(int, int). Dependency Walker
supports C++ undecoration by using the
Undecorate C++ Functions Command.
Edit: One thing you could do, I think, is to get a disassembler and disassemble the DLL and/or the calling code, and work out from that the number and types of the arguments, and the return types. You wouldn't be able to find out the names of the arguments though.
You can hook the functions in the DLL you wish to monitor (if you know how many arguments they take)
You can use dumpbin (Which is part of the Visual Studio Professional or VC++ Express, or download the platform kit, or even use OpenWatcom C++) on the DLL to look for the 'exports' section, as an example:
dumpbin /all SimpleLib.dll | more
Output would be:
Section contains the following exports for SimpleLib.dll
00000000 characteristics
4A15B11F time date stamp Thu May 21 20:53:03 2009
0.00 version
1 ordinal base
2 number of functions
2 number of names
ordinal hint RVA name
1 0 00001010 fnSimpleLib
2 1 00001030 fnSimpleLib2
Look at the ordinals, there are the two functions exported...the only thing is to work out what parameters are used...
You can also use the PE Explorer to find this out for you. Working out the parameters is a bit tricky, you would need to disassemble the binary, and look for the function call at the offset in the file, then work out the parameters by looking at the 'SP', 'BP' registers.
Hope this helps,
Best regards,
Tom.