I`d like to ask a question regarding IAT hooking on my own process .
I am currently trying to hook ExitProcess so it would run a certain function before any ExitProcess call, and I am facing some troubles .
I am traversing the PE at runtime, going through the IMAGE_IMPORT_DESCRIPTOR ,
after finding kernel32.dll there (which is the first .dll) I am traversing it THUNK_DATA-s by name, trying to find ExitProcess there, though with no luck.
Logging the functions, those are the functions which are found there -
GetModuleHandleA
GetProcAddress
LoadLibraryA
GetModuleFileNameW
FreeLibrary
VirtualQuery
GetProcessHeap
HeapFree
HeapAlloc
GetSystemTimeAsFileTime
GetCurrentThreadId
GetCurrentProcessId
QueryPerformanceCounter
IsProcessorFeaturePresent
WideCharToMultiByte
MultiByteToWideChar
LoadLibraryW
lstrlenA
LoadLibraryExW
GetLastError
RaiseException
IsDebuggerPresent
DecodePointer
EncodePointer
GetModuleHandleW
Though ExitProcess is nowhere within .
I have tried enumerating by function pointers instead of the names (using thunkdata instead of originalthunkdata) though it has failed as well.
GetProcAddress for ExitProcess does return a pointer within the PE, and I have tried to load kernel32.dll forcefully (though it should be loaded automatically) by loadlibrary, though the result is the same.
What could be the problem ?
HMODULE hMod = GetModuleHandle(NULL);
PIMAGE_DOS_HEADER pImgDosHeaders = (PIMAGE_DOS_HEADER)hMod;
PIMAGE_NT_HEADERS pImgNTHeaders = (PIMAGE_NT_HEADERS)((LPBYTE)pImgDosHeaders + pImgDosHeaders->e_lfanew);
PIMAGE_IMPORT_DESCRIPTOR pImgImportDesc = (PIMAGE_IMPORT_DESCRIPTOR)((LPBYTE)pImgDosHeaders + pImgNTHeaders->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress);
UINT indx = 0;
while(strcmpi((PCHAR)((LPBYTE)pImgDosHeaders + pImgImportDesc[indx].Name), "kernel32.dll")) { ++indx; };
PIMAGE_THUNK_DATA pImgThunkData = (PIMAGE_THUNK_DATA)((LPBYTE)pImgDosHeaders +pImgImportDesc[indx].OriginalFirstThunk);
PIMAGE_IMPORT_BY_NAME pImgImportByName = NULL;
for(;pImgThunkData->u1.Function; ++pImgThunkData)
{
pImgImportByName = (PIMAGE_IMPORT_BY_NAME)((LPBYTE)pImgDosHeaders + pImgThunkData->u1.AddressOfData);
!strcmpi("ExitProcess",pImgImportByName->Name) ? cout << "ExitProcess Found" : false;
}
return true;
Thank you so very much and have a great day !
If your app does not call ExitProcess() statically, such as if it is not called at all (not even by your app's RTL) or if it is loaded dynamically via GetProcAddress(), then it will not be present in your app's IMPORTS table. The IMPORTS table only lists functions that your app statically links to. That is likely why your code does not find it. Use a utility like PEDUMP or DependancyWalker to make sure your app is actually statically linking to ExitProcess(). For example, in my dev environment (C++Builder XE2), if I create a console project, ExitProcess() is not found in the IMPORTS table, but if I create a GUI project instead then it is found. The difference is that the two types of project use different RTLs under the hood, so apparently the console RTL does not use ExitProcess() when the app terminates.
Related
I am debugging a process in Visual Studio 2017 that loads many modules, I have set a function breakpoint on the CreateFile of Kernel32.dll.
This breakpoint hits many times, but I want to break the execution if a specific module makes call to the CreateFile function.
Passing unwanted breaks with F5 is not possible (there are too many of them).
There is no any code, all are just assemblies.
I want to see when "bcript.dll" (one of items in modules window) calls "CreateFile" from "Kernel32.dll".
As I didn't find any solution for my question, I decided to use other tools than Visual Studio, then I found some useful tools that I want to share:
1- In my case I used windows hooks:
void CInstallerDlg::OnBnClickedInstall()
{
if (m_hHook == INVALID_HANDLE_VALUE)
{
CString strTarget;
GetDlgItem(IDC_TARGET)->GetWindowText(strTarget);
HMODULE hDll = LoadLibrary(L"Dll.dll");
if (hDll)
{
HOOKPROC hProc = (HOOKPROC)GetProcAddress(hDll, (char*)1);
if (hProc)
{
FARPROC SetTarge = GetProcAddress(hDll, (char*)2);
if (SetTarge)
{
((void (CALLBACK *) (CString))SetTarge)(strTarget);
m_hHook = SetWindowsHookEx(WH_CALLWNDPROC, hProc, hDll, 0);
}
}
}
}
}
2- sysinternals have lots of analyzing tools.
3- winapioverride32 allows monitoring and overriding api calls.
4- snowman is a PE decompiler.
5- LordPE: download link allows to view and edit binary data in PE sections, along with general details about PE.
I sometimes have a problem where dynamic libraries fail to load at customer sites. This is usually because their system is configured wrong.
I need to be able to get the name of the dependent module that is missing so I can log it, and make fixing their systems much easier.
How can I accomplish this?
Note that I need an answer I can put in my code, this means I cannot use Dependency Checker, or Process Monitor, or any other tool to work out the problem.
I really do need a way to do it programatically.
The fact that Dependency Checker can do it means there is a way.
begin from win7 ntdll.dll export next api:
struct FAILUREDATA
{
NTSTATUS status;
WCHAR DllName[0x20];
WCHAR FunctionName[0x20];
};
extern "C" NTSYSCALLAPI FAILUREDATA* NTAPI LdrGetFailureData();
ntdll.dll Ldr-subsystem log failure in 2 case - GetProcAddress fail (in this case FunctionName filled) or if DLL load fail. but with one exception - if top-level (i.e. LibFileName which you use in LoadLibrary[Ex] call) not found - failure not logged. but if dependent DLL not found (or fail initialize) - this error will be logged and name of dependent DLL recorded in FAILUREDATA.DllName (if it longer than 31 symbol - it will be truncated) - usual status in this case STATUS_DLL_NOT_FOUND or STATUS_DLL_INIT_FAILED. also if top-dll found but fail initialize - this also will be logged. if some function will be not resolved during dll load - the FunctionName will be valid and usual status in this case - STATUS_ENTRYPOINT_NOT_FOUND or STATUS_ORDINAL_NOT_FOUND
unfortunately LdrGetFailureData not included in ntdll[p].lib - so need use GetProcAddress for get it. you can declare next global data:
static union {
FAILUREDATA* (NTAPI *LdrGetFailureData)();
PVOID pvLdrGetFailureData;
};
and on start call
pvLdrGetFailureData = GetProcAddress(GetModuleHandle(L"ntdll"), "LdrGetFailureData");
then implement next function:
void OnLdrFail(PCWSTR TopDllName)
{
if (LdrGetFailureData)
{
FAILUREDATA* pfd = LdrGetFailureData();
if (NTSTATUS status = pfd->status)
{
DbgPrint("%x loaded DLL <%S> fail DLL <%S> %S\n", status, TopDllName, pfd->DllName, pfd->FunctionName);
}
else
{
// in case loaded(top) DLL not found
DbgPrint("%x loaded DLL <%S>\n", GetLastError(), TopDllName);
}
}
}
in place DbgPrint of course implement your real logging
and you call OnLdrFail after LoadLibraryW fail. say like this
#define CLEAR_FAILURE_DATA() if (LdrGetFailureData) LdrGetFailureData()->status = 0
CLEAR_FAILURE_DATA();
HMODULE hmod = LoadLibraryW(lpLibFileName);
if (!hmod)
{
OnLdrFail(lpLibFileName);
}
because how i say Ldr not fill FAILUREDATA in case lpLibFileName not found - it not clear previous state of this structure - so need do this yourself (here can be previous error saved, unrelated to current call) (however if dependent of lpLibFileName not found or any dll initialization fail - this will be logged)
for example:
A.DLL dependent from B.DLL and B.DLL not found will be next log
c0000135 loaded DLL <A.DLL> fail DLL <B.DLL>
if DllMain from B.DLL return FALSE
c0000142 loaded DLL <A.DLL> fail DLL <B.DLL>
if DllMain from A.DLL return FALSE
c0000142 loaded DLL <A.DLL> fail DLL <A.DLL>
if A.DLL import SomeFunc from B.DLL but B.DLL not export it
c0000139 loaded DLL <A.DLL> fail DLL <Unknown> SomeFunc
When using 'Load-Time Dynamic Linking'(using an import library .lib in compilation that loads a dll when the module is loaded) in a Win32 application, is it possible to affect the search order?
The goal is to have a library loaded using the normal search order, with a back-up path if one is not found on the normal path.
Example: foo.lib is linked in the project. At load time:
If foo.dll is present in the System path or any of the other paths mentioned in Dynamic-Link Library Search Order then it will be loaded.
Else mySpecifiedPath/foo.dll will be loaded.
Clarification: The back-up dll should only be loaded if no version of the dll is found in the standard LoadLibrary search paths.
Leaving the old answer at the bottom and adding a new one at the top:
The combination of delay-loading and the delay-load Failure Hook as described at provides a nice way to handle this.
Register the failure hook that loads the back-up dll before using any symbol from the library.
#include <Windows.h>
#include "foo.h"
#include <delayimp.h>
//access to set the failure hook
ExternC PfnDliHook __pfnDliFailureHook2;
const char* dllName = "foo.dll";
const char* dllBackupPath = "pathToBackup\\foo.dll";
FARPROC WINAPI DelayLoadHook(unsigned dliNotify, PDelayLoadInfo pdli)
{
//if the failure was failure to load the designated dll
if (dliNotify == dliFailLoadLib &&
strcmp(dllName, pdli->szDll) == 0 &&
pdli->dwLastError == ERROR_MOD_NOT_FOUND)
{
printf("loading back-up dll\n");
//return the successfully loaded back-up lib,
//or 0, the LoadLibrary fails here
HMODULE lib = LoadLibraryA(dllBackupPath);
return (FARPROC)lib;
}
return 0;
}
int main()
{
//set the Failure Hook
__pfnDliFailureHook2 = &DelayLoadHook;
//when this function is called the library will be loaded
//from standard paths. If it is not found the Failure Hook
//set above will be called.
int test = ::intReturningFuncFromFooDll();
printf("%d", test);
getchar();
return 0;
}
===========old answer below==============
Looks like what I was looking for is delay-loading, as mentioned in the comment by IInspectable. I found information regarding this:
Linker Support for Delay-Loaded DLLs
Here is some code demonstrating the usage I mentioned in the original post:
//load the dll using the normal search
HMODULE lib = LoadLibrary( L"foo.dll" );
//if unsuccessful, try a specified path
if (lib == NULL)
{
LoadLibrary( L"mySpecifiedPath/foo.dll" );
}
if (lib == NULL)
{
//make sure that the library is not used,
//or exit the application, as it was not found
}
Thanks for the help!
edit to old answer: This dynamic loading would be used before any symbol from the library is used. The delay loaded fills out the symbol addresses using the module loaded here the first time a symbol from the library is accessed.
Looking at the Dynamic-Link Library Search Order documentation, it should be obvious, that the final location searched is the PATH environment variable. Applying that knowledge, the easiest solution that meets all your requirements is to append the backup location to the PATH variable.
This could be done in two ways:
An external launcher: The CreateProcess API call allows an application, to pass a custom environment to the new process through the lpEnvironment argument. The current process' environment block can be queried by calling GetEnvironmentStrings.
Enable delay-loading of the desired DLL(s) using the /DELAYLOAD linker option, and modify the process' environment at application startup. After retrieving the PATH environment variable (using GetEnvironmentVariable), it can be modified and updated in the environment block by calling SetEnvironmentVariable.
Recently, some of our clients lost their XAudio2_7.dll from their C:/Windows/System32 directory, and now they can't hear any audio. Reinstalling DirectX or registering the dll normally would be sufficient enough to fix this problem, but we're looking for a solution that does not require admin rights. This is for Windows 7. Applications are written in CPP, and some of them are 32 bit and the rest are 64 bit.
There is a local copy of XAudio2_7.dll within the same directory of the exe, but that is not loaded unless that dll is registered since it's a COM dll. Registering for the current user (using "Regsvr32.exe /n /i:user XAudio2_7.dll") does not work since the dll does not implement a required interface "DllInstall".
One approach I've tried is to statically link a .lib of XAudio instead of using a dynamic link. Microsoft does not distribute XAudio2_7.lib with DirectX SDK. "No versions of the DirectX SDK contain the xaudio2.lib import library. DirectX SDK versions use COM to create a new XAudio2 object." msdn.microsoft.com/en-us/library/windows/desktop/microsoft.directx_sdk.xaudio2.xaudio2create%28v=vs.85%29.aspx
Granted, this suggests that it may not be possible to use a static XAudio library even if I created one since it sounds like it depends on external objects defined in other libraries. It was still worth testing in case my hypothesis is incorrect.
Following the steps mentioned in this link: adrianhenke.wordpress.com/2008/12/05/create-lib-file-from-dll/
I didn't get very far with this method. Outside of the articles being dated, there were a couple problems with this. The MS link within the blog mentions this is for 32-bit dlls. Even for 32-bit dlls, dumpbin didn't work since it only exported the interface functions.
Dump of file C:\XAudioTest\32Bit\XAudio2_7.dll
File Type: DLL
Section contains the following exports for xaudio2.dll
00000000 characteristics
4C064181 time date stamp Wed Jun 02 07:33:21 2010
0.00 version
1 ordinal base
4 number of functions
4 number of names
ordinal hint RVA name
1 0 00030AA0 DllCanUnloadNow
2 1 00031150 DllGetClassObject
3 2 00031470 DllRegisterServer
4 3 000314D0 DllUnregisterServer
Summary
C000 .data
1000 .no_bbt
4000 .reloc
1000 .rsrc
7B000 .text
Later, I found this quote from another MSDN article. "The COM standard requires that COM DLLs export DllCanUnloadNow, DllGetClassObject, DllRegisterServer and DllUnregisterServer. Typically they will export nothing else. This means that you cannot get COM object or method information using dumpbin.exe." msdn.microsoft.com/en-us/library/aa446532.aspx
I've also tried using a third party program that claims it's able to create a .lib from a COM dll. www.binary-soft.com/dll2lib/dll2lib.htm
Although this did generate a 32-bit .lib file, compiling with the lib file generated unresolved external symbols. This utility does come with methods to handle unresolved symbols, but entering anything within Symbol Finder or Advanced Conversion Options would crash. Looking in the latest release notes (3.00), I found that they added support for Vista and no mentions for Windows 7. Also this doesn't work for 64-bit dlls.
I've tried another approach is to change the initialization sequence to use a nonregistered COM DLL described in this link: Use COM Object from DLL without register
The initialization code looks similar to this:
HMODULE audioLib = LoadLibrary(TEXT("XAudio2_7.dll"));
if (audioLib == NULL)
{
debugf(TEXT("Failed to create COM object. Unable to load XAudio2_7.dll library. GetLastError: %d"), GetLastError());
return;
}
typedef HRESULT (WINAPI* Function_DllGCO) (REFCLSID, REFIID, LPVOID*);
Function_DllGCO processAddress = (Function_DllGCO)GetProcAddress(audioLib, "DllGetClassObject");
if (processAddress == NULL)
{
debugf(TEXT("COM DLL failed to find the process address to interface function 'DllgetClassObject' within the XAudio2_7.dll. GetLastError: %d"), GetLastError());
return;
}
class __declspec(uuid("{5a508685-a254-4fba-9b82-9a24b00306af}")) xAudioGUID;
REFCLSID classID = __uuidof(xAudioGUID);
class __declspec(uuid("{00000001-0000-0000-c000-000000000046}")) classFactoryGUID;
REFIID classFactoryID = __uuidof(classFactoryGUID);
IClassFactory* ClassFactory = NULL;
if (processAddress(classID, classFactoryID, reinterpret_cast<LPVOID*>(&ClassFactory)) != S_OK)
{
debugf(TEXT("Failed to execute function pointer to DLLGetClassObject. GetLastError: %d"), GetLastError());
return;
}
class __declspec(uuid("{00000000-0000-0000-C000-000000000046}")) unknownGUID;
REFIID unknownID = __uuidof(unknownGUID);
if (ClassFactory->CreateInstance(NULL, unknownID, reinterpret_cast<void**>(&ClassFactory)) != S_OK)
{
debugf(TEXT("Class factory for XAudio2_7 failed to create an object instance. GetLastError: %d"), GetLastError());
ClassFactory->Release();
return;
}
if( XAudio2Create( &XAudio2, 0, AUDIO_THREAD) != S_OK ) //Fails here with error number: 1008 (An attempt was made to reference a token that does not exist.)
{
debugf( NAME_Init, TEXT( "Failed to create XAudio2 interface: GetLastError: %d" ), GetLastError());
return;
}
//Do other things
All WinAPI function calls passed excluding the XAudio2Create function. I'm uncertain why XAudio2Create is not using the object created from the factory, and I don't know what I need to do to get it to use that object. I'm still investigating what I can do here, but it's difficult to debug closed source libraries.
Before I knew about COM DLLs, a method I've tried is to use DLL-Redirection to force an application to use a particular DLL. Using the process described here: DLL redirection using manifests
XAudio2Create still failed. I don't have a strong strategy in identifying what's wrong with the manifest. I also haven't found much up to date documentation regarding manifests for dll redirection. From the sounds of this is this mostly used to load a particular DLL version. I don't think DLL redirection is the method I need since there is already a local copy of XAudio2_7 within the same directory of the exe, which means it should take precedence over the XAudio2_7 within the system directory according to: msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx
Note: I removed the hyper links for some addresses since I don't have enough reputation points to post more than 2 links.
Have you tried registration-free activation?
I have an application (written in C++ with MFC, but I don't think that that's particularly relevant) that embeds the Internet Explorer ActiveX WebBrowser control for the purpose of showing some HTML pages. One requirement has always been to use the application's font name and size settings as the default settings for the HTML, rather than Internet Exporer's defaults.
To achieve this, the application implements the IDocHostUIHandler2 COM interface, which it passes to the WebBrowser control. This causes the control to call the application's implementation of GetOptionKeyPath, which lets the application set the registry location that the WebBrowser control gets its settings from. Armed with Sysinternals' tools to see which keys IE uses to find the font name and size, this has been sufficient to do what I need.
However, the appeareance of Internet Explorer 9 has come as a nasty surprise: on all machines that I've tested with that have IE9 installed, the WebBrowser control uses its own settings, ignoring the registry location from the application. Testing with a debugger shows that the WebBrowser control never calls the provided GetOptionKeyPath.
A bit more experimentation shows that the IE9 WebBrowser control is calling the similar (but not identical) GetOverrideKeyPath method: this allegedly provides a way to override IE settings, while falling back to IE's actual settings if nothing is found in the relevant part of the registry. Unfortunately this has two problems: 1) It's not quite what I want, and 2) IE9 doesn't always check under the GetOverrideKeyPath registry location before going to the IE default registry settings.
Looking at the GetOptionKeyPath MSDN page there are a few complaints along similar lines, but no solutions. Has anyone found a clean way to persuade the WebBrowser control to revert to the pre-IE9 behaviour of actually calling GetOptionKeyPath as documented?
I've come up with a hack to solve this problem, but I should warn you: it's not pretty. Stop reading now if you've easily offended ...
Since there seems to be no way of making IE9 use the IDocHostUIHandler::GetOptionKeyPath() method, I used SysInternals' tools to see which IE9 DLLs accessed the relevant parts of the registry to load the IE9 settings. This revealed the only culprits as "mshtml.dll" and "iertutil.dll", both of which call RegOpenKeyExW().
The plan was then to load these DLLs before initializing the WebBrowser control, and patch them so that calls are redirected to my code, where I can lie about what registry key I've opened, using dbghelp.dll. So, to start, before initializing the WebBrowser control:
if (theApp.GetIEVersion() >= 9.0)
{
HMODULE advadi = ::LoadLibrary("advapi32.dll");
HMODULE mshtml = ::LoadLibrary("mshtml.dll");
HookApiFunction(mshtml,advadi,"advapi32.dll","RegOpenKeyExW",(PROC)HookRegOpenKeyExW);
HMODULE iertutil = ::LoadLibrary("iertutil.dll");
HookApiFunction(iertutil,advadi,"advapi32.dll","RegOpenKeyExW",(PROC)HookRegOpenKeyExW);
}
And now, the code that does the evil work of scanning the DLLs import address tables, and patching the requested function (error handling omitted to keep the code size down):
void HookApiFunction(HMODULE callingDll, HMODULE calledDll, const char* calledDllName, const char* functionName, PROC newFunction)
{
// Get the pointer to the 'real' function
PROC realFunction = ::GetProcAddress(calledDll,functionName);
// Get the import section of the DLL, using dbghelp.dll's ImageDirectoryEntryToData()
ULONG sz;
PIMAGE_IMPORT_DESCRIPTOR import = (PIMAGE_IMPORT_DESCRIPTOR)
ImageDirectoryEntryToData(callingDll,TRUE,IMAGE_DIRECTORY_ENTRY_IMPORT,&sz);
// Find the import section matching the named DLL
while (import->Name)
{
PSTR dllName = (PSTR)((PBYTE)callingDll + import->Name);
{
if (stricmp(dllName,calledDllName) == 0)
break;
}
import++;
}
if (import->Name == NULL)
return;
// Scan the IAT for this DLL
PIMAGE_THUNK_DATA thunk = (PIMAGE_THUNK_DATA)((PBYTE)callingDll + import->FirstThunk);
while (thunk->u1.Function)
{
PROC* function = (PROC*)&(thunk->u1.Function);
if (*function == realFunction)
{
// Make the function pointer writable and hook the function
MEMORY_BASIC_INFORMATION mbi;
::VirtualQuery(function,&mbi,sizeof mbi);
if (::VirtualProtect(mbi.BaseAddress,mbi.RegionSize,PAGE_READWRITE,&mbi.Protect))
{
*function = newFunction;
DWORD protect;
::VirtualProtect(mbi.BaseAddress,mbi.RegionSize,mbi.Protect,&protect);
return;
}
}
thunk++;
}
Finally, the function that I have patched the DLLs to call in my code, in place of RegOpenKeyExW():
LONG WINAPI HookRegOpenKeyExW(HKEY hKey, LPCWSTR lpSubKey, DWORD ulOptions, REGSAM samDesired, PHKEY phkResult)
{
static const wchar_t* ieKey = L"Software\\Microsoft\\Internet Explorer";
// Never redirect any of the FeatureControl settings
if (wcsstr(lpSubKey,L"FeatureControl") != NULL)
return ::RegOpenKeyExW(hKey,lpSubKey,ulOptions,samDesired,phkResult);
if (wcsnicmp(lpSubKey,ieKey,wcslen(ieKey)) == 0)
{
// Redirect the IE settings to our registry key
CStringW newSubKey(m_registryPath);
newSubKey.Append(lpSubKey+wcslen(ieKey));
return ::RegOpenKeyExW(hKey,newSubKey,ulOptions,samDesired,phkResult);
}
else
return ::RegOpenKeyExW(hKey,lpSubKey,ulOptions,samDesired,phkResult);
}
Amazingly enough, this horrible hack actually works. But please, Microsoft, if you're listening, please fix this properly in IE10.