I have a driver code with the following line
hKernel32DLL = LoadLibrary( "Kernel32.dll" );
Now someone reviewed my code and suggested to load the DLL with full path.
I did a quick search online about loading kernel32.dll but no one really use a full path.
Can someone explain to me why I should specify the absolute path of kernel32.dll?
It is safer to load .DLLs with a full path. Kernel32 is already loaded because you statically linked to LoadLibrary so in your specific case it does not matter. (On all versions of Windows except 2000, CreateProcess will load Kernel32 into the process before it even starts but this does not apply to other core .DLLs like Gdi32 and User32.)
If you are worried about .DLL hijacking attacks then you can call SetDefaultDllDirectories with the LOAD_LIBRARY_SEARCH_SYSTEM32 flag, this forces all .DLLs with a relative path to load from the system directory.
Related
Often one wants to LoadLibrary a system DLL like Kernel32.dll, handily LoadLibraryEx has a dwFlags parameter that allows you to specify LOAD_LIBRARY_SEARCH_SYSTEM32.
For security reasons, this can be very important as malicious attackers can subvert the default search paths that LoadLibrary looks through.
However Windows XP, which I must still support, cannot use LOAD_LIBRARY_SEARCH_SYSTEM32 as it didn't exist eons ago. This leads me to the following conclusion: I need to come up with a fully qualified path and pass that to LoadLibrary.
However, a robust implementation of this is tricky due to WoW64 and file-system redirection.
I have to worry about this possibility because the code in question lives in a library and can be called in strange environments.
My current thoughts are something like the following pseudo-code:
string Path;
BOOL Wow64Process;
if (IsWow64Process(CurrentProcess(), &Wow64Process) && Wow64Process &&
WoW64FSRedirectionIsDisabled)
Path = GetSystemWow64Directory();
else
Path = GetSystemDirectory();
Path += "\Kernel32.dll";
LoadLibrary(Path);
I have considered, and rejected using Wow64DisableWow64FsRedirection and Wow64RevertWow64FsRedirection but this is problematic as it will leave FS redirection disabled in the library's DLLMain.
Given the above, what's the best way to go about what I am trying to do?
Thanks!
In terms of loading a DLL without dependencies, you are over thinking this. If the user has disabled file system redirection in a WOW64 process then LoadLibraryEx will attempt to load the DLLs from the 64 bit system32 folder. So you can simply do exactly the same and remove all that WOW64 code.
However, the documentation says (emphasis mine):
If this value is used, %windows%\system32 is searched for the DLL and its dependencies.
So, your approach cannot replicate LOAD_LIBRARY_SEARCH_SYSTEM32 because you can only supply the full path for the DLL you load, but not for its dependencies.
The only way to hope to replicate this is to force system32 to be at the head of the DLL search path. Specifying a full path won't help you.
Finally, are you sure that LOAD_LIBRARY_SEARCH_SYSTEM32 is not available on XP64?
As an alternative to the other answers use SetDlldirectory.
The advantage ist that the current Directory isn't checked for a DLL-load.
Still open is the search via PATH... but this is in the last Position, so your DLL located in the SYSTEM32 directoryies should be loaded first using SettDllDirectory.
Also it is supported since XP SP1
My code is using a library which is a static/implicitly linked DLL (let's call it DLLB) but on runtime it can't find it.
This is despite locating DLLB in the same directory as the code that calls it. (The calling code is itself a DLL, DLLA which is called from python, which is called from arcpy. I'm not quite sure why the python finds DLLA fine but DLLA doesn't find DLLB, despite them being in the same directory).
If I put the library DLL somewhere on the system path, everything works just fine.
But what's the best approach for deployment? Add an entry to the system path on the client machine, at install time? Modify the system path at runtime, from python, before loading the DLL? Something else?
Python must be specifying the full path to the DLL in the LoadLibrary call. This is recommended practice. If you specify only a module name, there is a risk of loading the wrong DLL, possibly introducing a binary planting vulnerability.
Note that although the default search path includes the directory the executable was loaded from, it does not include the directory other DLLs were loaded from. So the behaviour you're seeing is as expected.
If you can use dynamic loading, you can look up the path to DLLA and use it to construct the path to DLLB.
To get a module handle for DLLA, call GetModuleHandleEx. To get the full path to DLLA from the module handle, call GetModuleFileName. Check that the last element is DLLA.dll and replace it with DLLB.dll. You can then call LoadLibrary.
Why doesn't Windows require a full file path when calling LoadLibrary, or for CLSIDs w/ registered DLLs, etc. In what situation would someone benefit from having to fall back on the DLL Search Order to find a dll?
I mean, variables such as %SystemRoot% or %ProgramFiles% could get you to the appropriate folder, and .\ would leave you in your current directory.. So why allow the vagueness?
For explicit linking with GetProcAddress() I would argue that one should use the absolute path to the DLL if at all possible.
For implicit linking with .lib files then the name of the DLL has to be determined at link time which rules out absolute paths.
It is safest to put the DLL in the same directory as the executable, under %Program Files% and protected by UAC, and to use the new DLL search order.
I want to make a dll with an exposed C function accessible to applications on the system.
Is there a better way to make it available than modifying %PATH%?
Because people don't like adding it to %PATH% here.
You have three options if you want to allow implicit linking to the dll :-
Create a native Win32 assembly that contains the dll and install it to WinSxS. This requires creating a simple .manifest file, the use of some crypto tools to sign the assembly (being the manifest file and the dll), and creating an MSI installer - or call IAssemblyCache directly to perform the actual install.
Install the dll to System32 - with this option you need to ensure the dll has a relativly unique name.
Ad the path to the dll to the someplace on the PATH (or modify path to point to the dll).
Other options if implicit linking to the C Function isn't critical:-
Create an COM interface that exposes the c-method. Register the path to the dll in the registry and users of the dll use CoCreateInstance to get the interface containing the function.
Store the path to the dll in the registry, and expect users of the dll to use that path with LoadLibrary, and GetProcAddress to load the dll.
Put it somewhere in your PATH. (C:\Windows\System32\ comes to mind). If it's only needed by one application, just stick it in the same directory.
If you call the DLL using an import library, then it looks in the current directory, and then in the PATH.
But, you don't need to call it that way. You can use LoadLibrary() and GetProcAddress() yourself and then do whatever you want. If you call LoadLibrary with just the dll name, it uses the same algorithm as with the import library (current dir + PATH) -- if you pass a full path, it will use it.
COM uses this technique to load a DLL based on a full path to the DLL which is in the registry -- you could do this too without COM.
You could search for it in some other way besides the PATH -- you could call with no path, see if it finds it, and then try the registry, and then look elsewhere (every drive's program files directory, etc).
Basically, if you call LoadLibrary and GetProcAddress yourself, you can do whatever you want.
I guess that it would be best to install it into system32 folder and forget about %PATH% modification...
I have a question about getting DLL's directory on Windows system.
The situation is like this :
I have a DLL and an EXE file. The exe file must load the DLL to run.
These 2 modules are in different directories.
Moreover, the directory of the DLL is changeable.
Now I have to get the directory of the DLL in "run time".
How could I do this?
Thanks in advance.
Do you need to find where the DLL is to load it or find the the path where it was loaded from?
The DLL path search algorithm is documented on MSDN and you can use the SearchPath function to search the system path.
If you need to find the path where a DLL was loaded, after it was loaded, use the GetModuleFileName function. That takes the module handle that is returned by LoadLibrary, GetModuleHandle, or passed in as hinstDLL to DllMain and returns the full path to the DLL.
I guess you need to implement some custom search algorithm. Only your exe knows which one DLL is needed and where it can be. So find the path and use it with LoadLibrary().
BTW, if possible, I would consider using COM. In this way you will use DLL stuff by some CLSID, which is completely independent from file path.