Can anybody provide a definitive description of what an "exported symbol" is with respect to an executable binary, and NOT a library?
They are the same thing. You export a procedure in a dll so other code can call that procedure by name/ordinal from the dll/lib. You do the same thing with an exe, you can export functions to be used the same way.
Related
i have used CLIPSWIN32.DLL in my program,and the functions in the dll is so limited.I even can not find the AssertString() Addrouter() functions in the dll.
the question is :
if there is a dll that contains the factions?
if not,is there a function that can repalce the twos above?
If you download clipsnet from the CLIPS SourceForge Files area (http://sourceforge.net/projects/clipsrules/), there are examples included that utilize the AssertString and AddRouter methods. Search the project to find the methods.
I have a DLL that I want to use/debug. I don't have the source.
Looking at it with IDA, I found 3 things :
DllMain does nothing
The code I need is self contained in a function that only calls a few Windows API. It does not reference anything else in that DLL.
That self contained function is not exported
I could extract the assembly code and link it to a C program, but I wonder:
Is it possible to (and how should I) add an entry to the export table of an existing DLL without recompiling it?
Yes, you can do that but most tools don't support this. For example using CFF Explorer, it's easier to convert an existing export to what you want it to be. Just edit the function RVA and exported name. Since you only need the one thing, it shouldn't be a problem that you're removing some other export.
You could even do it with a hex editor since it doesn't involve moving anything rebuilding the header, it's just an in-place edit.
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!)
What is the correct way to use GetProcAddress() on a 32 bit DLL? On win32, there are three calling conventions, cdecl, stdcall and fastcall. If the function in the DLL is foo they will decorate the name in the following ways _foo, _foo#N and #foo#N.
But if the author of the dll has used a .def file, then the exported name will be changed to just "foo" without any decoration.
This spells trouble for me because if I want to load foo from a dll that is using stdcall, should I use the decorated name:
void *h = LoadLibraryEx(L"foo.dll", NULL, 0);
GetProcAddres((HMODULE)h, L"_foo#16");
Or the undecorated one:
void *h = LoadLibraryEx(L"foo.dll", NULL, 0);
GetProcAddres((HMODULE)h, L"foo");
? Should I guess? I've looked at lots of 32 bit DLL files (stdcall and cdecl) and they all seem to export the undecorated name. But can you assume that is always the case?
There's really no shortcut or definitive rule here. You have to know the name of the function. The normal scenario is that you know at compile time the name of the function. In which case it does not matter whether the exported name is mangled, decorated, or indeed completely unrelated to the semantic name. Functions can be exported without names, by ordinal. Again, you need to know how the function was exported.
If you are presented with a header file for a library, and want to link to it with explicit linking (LoadLibrary/GetProcAddress) then you will need to find out the names of the function. Use a tool like dumpbin or Dependency Walker to do that.
Now, the other scenario which might lead to you asking the question is that you don't know the name at compile time. For instance, the name is provided by the user of your program in one way or another. Again, it is quite reasonable to require the user to know the exported name of the function.
Finally, you can parse the PE meta data for the executable file to enumerate its exported function. This will give you a list of exported function names, and exported function ordinals. This is what tools like dumpbin and Dependency Walker do.
If __declspec(dllexport) is used during compilation and __declspec(dllimport) in header file, as well as extern "c", then you do not need to decorate those functions. The __declspec helps in using the undecorated names, but function overloads, namespaces, and classes still require same way to distinguish them.
Usually, object oriented functions are exported using function ordinals instead of their decorated names. Cast the ordinal as (char*)(unsigned short)ordinal, thus, GetProcAddress(module, (char*)(unsigned short)ordinal);
Edit: while most of Windows use UTF-16, GetProcAddress uses UTF-8, so it cannot use a wide character string.
GetProcAddress(module, L"foo") is identical to GetProcAddress(module, "f");