Checking for exported symbols/functions in a DLL without loading it

You can find out if a DLL exports some symbols/functions without calling LoadLibrary() on it

The tip/trick title speaks for itself. I give you a simple function that takes a file name and a list of symbols/function names, and it returns true if the specified file is a DLL that exports all of the specified symbols. Detecting exports by ordinal numbers are not supported because I wasn't in need of that, but if someone needs it and I have the time, then I can put it in easily because it's easier to check than the exports by names. All this is done without loading the DLL, thus avoiding execution of a possibly dangerous DllMain() of an unwanted DLL in your process. It works with both 32 and 64 bit binaries. I used it in a plugin system to safely detect some plugins of older versions in a program. Use this code only when reasonable because checking all DLLs with this before all LoadLibrary() calls can slow down your plugin initialization code in a system with lot of plugins (eg.: GIMP)!!!That's all folks! :D

stdafx.h:

#pragma once
#include<windows.h>#include<winnt.h> // must be after windows.h
#include<vector>#include<set>#include<string>#include<cassert>

Comments and Discussions

Reason for my vote of 5Very nicely done! I using the same technique in a library to detect the presence and version of plug-ins in a bigger project. It's much faster than loading the DLL, even with the DONT_RESOLVE_DLL_REFERENCES switch. With a couple more lines you can even inspect the data contents of global symbols and version resources. That's a very powerful tool.

@SledgeHammer01: Actually you pointed out something that was missing from the article. The reasoning part was patched into the tip yesterday. Anyway, calling LoadLibrary() and GetProcAddress() are indeed much simpler than spending at least days to research the PE format. @Member 4320844: I can detect only that is found in the DLL export table. That consists of a list of names, and associated addresses (RVAs that point to something, actually these can point to anything but they are usually function entrypoints or variables).

Another thing that isn't handled by the code is exports by ordinals, not by names. Actually this would be easier to implement than checking for export by names, but I wasn't in need of that, I can implement it if someone needs the stuff. And, yes, checking all your plugins with this function before loading then can make plugin loading much slower (for example in a system with billions of plugins like GIMP). But if you have such a system then design your plugs to support versioning somehow, maybe with the filename, or append a few bytes to the end of your binaries, or something else... And use this only if its reasonable.

I used this to detect older versions of some plugins in a system that supported plugins of the previous versions of the program. Some of the older version plugins were dangerous to load because of their activity in their DllMain() that is executed in your process before LoadLibrary() returns. In that case this is the good solution and not LoadLibrary().

Your are right. I didn't know this flag, but probably because according to MSDN it is present only in Win2000 and newer. Our prog was an old Win95 compatible workhorse. Haven't tried it, but if it acts as the MSDN doc claims, then this is a valid alternative solution!

I wished if your code has the ability to find out the contents of DLL's, such that one could be able to seek and run what ever likely functions(methods with parameters) found in any searched DLL. For example System DLL's and any other Networking or security dll's. Thanks very much. I don't know if your code is able to do that? ... It will be great. My best Vote for you 4 .

All you can find out from the export table of a DLL is some symbol names, and some ordinals, each of them having an address associated. Unfortunately we don't have extra info like parameter names or variable types like in .Net assemblies, unless you have some debug info in the DLL.

Thanks for your nice reply. Still I wish if any one who finds out away to extract complete information s about the functions(& parameters) in DLL's to inform me, I will be thank full. Thanks again, and wish you more success.With Best Regards.

Sure, you are right, but my question may not be understood. Actually I wanted to know that:

How one can extract and print a list of names & parameters of what ever functions available inside any DLL ?, so that we can use them by calling them in a test to know their capabilities .. and so on, & that will be great. Thanks in advance for reply.kind regards.

But not all of the information you want is present in the DLL.You can discover the function name and the number of arguments, but not what argument data types are expected, or what their expected values are.

Technologies that address these issues get more complicated, see CORBA, COM, DCOM...