We are trying to understand some of the finer details of locating a symbol at runtime. I've already reviewed Jeffrey Richter's Programming Applications for Microsoft Windows, Chapters 19 (DLL Basics) and 20 (DLL Advanced). Richter is a bit more comprehensive and more cohesive than MSDN.
We are trying to combine implicit library linking with dynamic symbol location. We want to avoid calls to LoadLibrary because of some of the potential security hazards. We are also trying to avoid loader lock issues if a user wanders into doing too much in a DllMain function.
#include <windows.h>
#pragma comment(lib, "kernel32")
extern "C" {
typedef BOOL (WINAPI * PFN_GOR)(HANDLE, LPOVERLAPPED, LPDWORD, BOOL);
typedef BOOL (WINAPI * PFN_GORX)(HANDLE, LPOVERLAPPED, LPDWORD, DWORD, BOOL);
}
int main(int argc, char* argv[])
{
HINSTANCE hInst = GetModuleHandle("kernel32");
PFN_GOR pfn1 = hInst ? (PFN_GOR)GetProcAddress(hInst, "GetOverlappedResult") : NULL;
PFN_GORX pfn2 = hInst ? (PFN_GORX)GetProcAddress(hInst, "GetOverlappedResultEx") : NULL;
std::cout << "kernel32: " << std::hex << (void*)hInst << std::endl;
std::cout << "GetOverlappedResult: " << std::hex << (void*)pfn1 << std::endl;
std::cout << "GetOverlappedResultEx: " << std::hex << (void*)pfn2 << std::endl;
return 0;
}
We kind of got lucky with GetOverlappedResult and GetOverlappedResultEx because kernel32.dll provides both of them regardless of the platform. kernel32.dll has another nice property because every Windows application links to it, and there's no way to disgorge it.
Random numbers from the platform appear to be a little more troublesome. On Windows 7 and below we have CryptGenRandom from advapi32.dll; while Windows 10 and above uses BCryptGenRandom from bcrypt.dll. Windows 8 is a grey area because some versions, like Windows Phone 8, do not offer anything. We believe we can guard inclusion of a library based on WINVER or _WINNT_VER.
I feel like the pattern of implicit library linking combined with GetModuleHandle and GetProcAdress is unusual but it meets our requirements. Its unusual because it uses implicit linking and GetModuleHandle rather than LoadLibrary. I also cannot find text that forbids implicit linking and GetModuleHandle.
It meets our requirements because we will not be responsible for insecure library loading due to binary planting and other DLL redirection tricks. We will also avoid DoS'es from accidental mis-use by doing too much in a DLLmain.
My question is, is the code a legal combination or pattern. If its a defective pattern, then what is the defect?
We support Windows XP and Visual Studio .Net through Windows 10/Phone 10/Store 10 using Visual Studio 2015.
On Windows XP the code produces the following result:
>cl.exe /TP /EHsc test.cxx /Fetest.exe
...
>.\test.exe
kernel32: 7D4C0000
GetOverlappedResult: 7D52E12C
GetOverlappedResultEx: 00000000
On Windows 7 the code produces the following result:
>cl.exe /TP /EHsc test.cxx /Fetest.exe
...
>.\test.exe
kernel32: 772A0000
GetOverlappedResult: 772CCC69
GetOverlappedResultEx: 00000000
On Windows 8 the code produces the following result (Windows 10 is similar):
>cl.exe /TP /EHsc test.cxx /Fetest.exe
...
>.\test.exe
kernel32: 74FD0000
GetOverlappedResult: 74FEF8C0
GetOverlappedResultEx: 7675C4D0
On Windows 8 and 10 we can only test the cross-compile and link with ARM Developer Prompt. We test the compile for Desktop, Phone and Store using the following additional CXXFLAGS:
- To test Desktop app, add the following
CXXFLAGS:/DWINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP
- To test Windows Store app, add the following
CXXFLAGS:/DWINAPI_FAMILY=WINAPI_FAMILY_APP
- To test Windows Phone, add the following
CXXFLAGS:/DWINAPI_FAMILY=WINAPI_FAMILY_PHONE_APP
- To test Surface RT (ARM tablet), add the following
CXXFLAGS:/D_ARM_WINAPI_PARTITION_DESKTOP_SDK_AVAILABLE=1 /DWINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP
I'm finding lots of hits like Implicit vs. Explicit linking to a DLL, but I have not been able to find one that examines some of the security issues that LoadLibrary can impose, and how to avoid LoadLibrary altogether.
