I've looked at __attribute__((constructor)) equivalent in VC? and CRT Initialization, which were both helpful regarding the gcc-specific __attribute__((constructor)). But what about __attribute__((destructor))? Is there a VC equivalent?
If you're making a dynamic link library, you can make your DllMain entry point handle this:
BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
if (fdwReason == DLL_PROCESS_ATTACH)
{
// equivalent of __attribute__((constructor))...
// return TRUE if succeeded, FALSE if you failed to initialize properly
return TRUE; // I'm assuming you succeeded.
}
else if (fdwReason == DLL_PROCESS_DETACH)
{
// equivalent of __attribute__((destructor))...
}
// Return value is ignored when fdwReason isn't DLL_PROCESS_ATTACH, so we'll
// just return TRUE.
return TRUE;
}
Related
I'm trying to inject the DLL into my other program and hook the win32 API function SetConsoleTitle so I can read what parameters are being passed. Everything seems to work except that the strings appear to be unreadable.
When I was hooking my function (non winapi) everything worked just fine.
SetConsoleTitle export and hooked functions:
typedef BOOL(WINAPI* SetConsole)(LPCTSTR str);
BOOL SetConsoleHooked(LPCTSTR str)
{
//im checking the string here in the vs debugger
SetConsole s = (SetConsole)ConsoleAddress;
return s(str);
}
"Error reading characters of string"
The string is showing as nonreadable and I don't know how to access it.
And here is my DLLMain function:
BOOL WINAPI DllMain(
HINSTANCE hinstDLL, // handle to DLL module
DWORD fdwReason, // reason for calling function
LPVOID lpvReserved) // reserved
{
if (fdwReason == DLL_PROCESS_ATTACH)
{
HMODULE hModule = GetModuleHandle(L"SomeFile.exe");
HandleAddress = (DWORD)hModule + (DWORD)0x51D05;
ConsoleAddress = (DWORD)hModule + (DWORD)0x55ACA;
DetourTransactionBegin();
DetourUpdateThread(GetCurrentThread());
DetourAttach(&(LPVOID&)ConsoleAddress, &SetConsoleHooked);
DetourTransactionCommit();
while (true) {}
return true;
}
}
And lastly function from IDA that I've been trying to hook
I'm working with MS detours 4.0, compiled in VS2005 on Windows 10 (Updating an older application).
I'm trying to detour the WriteProfileStringA function normally found in the kernel32.dll with a DLL injection.
The DLL injects just fine, I can debug the target process and can step through the detouring functions.
DetourTransactionBegin, DetourUpdateThread, DetourAttach and DetourTransactionCommit all pass with flying colours returning 0 each time.
typedef BOOL (__stdcall * WriteProfileStringAType)(CHAR *,LPCSTR,LPCSTR);
static WriteProfileStringAType OriginalWriteProfileStringA = NULL;
BOOL WINAPI DetouredWriteProfileStringA(CHAR * lpAppName,
LPCSTR lpKeyName,
LPCSTR lpString)
{
FILE* file = fopen("c:\\temp\\testdetour.txt","w");
fprintf(file,"DetouredWriteProfileStringA");
fclose(file);
return OriginalWriteProfileStringA(lpAppName,lpKeyName, lpString);
}
...
BOOL WINAPI DllMain(HINSTANCE hinst, DWORD dwReason, LPVOID reserved)
{
if (DetourIsHelperProcess()) {
return TRUE;
}
if (dwReason == DLL_PROCESS_ATTACH) {
...
DetourTransactionBegin();
long update = DetourUpdateThread(GetCurrentThread());
OriginalWriteProfileStringA = (WriteProfileStringAType)GetProcAddress(GetModuleHandle("kernel32"),
"WriteProfileStringA");
long attach = DetourAttach(&(PVOID&)OriginalWriteProfileStringA, DetouredWriteProfileStringA);
long commit = DetourTransactionCommit();
...
}
else if (dwReason == DLL_PROCESS_DETACH) {
DetourTransactionBegin();
DetourUpdateThread(GetCurrentThread());
DetourDetach(&(PVOID&)OriginalWriteProfileStringA, DetouredWriteProfileStringA);
DetourTransactionCommit();
}
return TRUE;
}
BUT when the target application calls the WriteProfileStringA function, the registry is updated but the detour function is never called, break points are ignored and the testdetour.txt isn't created in the c:\temp directory(which does exist)...
Anybody have any ideas?
Before my dll file gets injected to a process, I want to check if it actually is the process I want it to inject. Is there a way to achieve this, so I could abort the injection process if its the wrong process?
Thank you in advance for any help!
int APIENTRY DllMain(HMODULE hModule, DWORD reason, LPVOID reserved)
{
if (reason == DLL_PROCESS_ATTACH)
{
if (process == theprocessiwant)
{
//call my stuff....
}
}
return true;
}
GetModuleFileNameA will give you the complete path of the executable of whose process you have injected into. Compare this path against your predefined executable path.
Okay thank you for your suggestions, I found a working way!
DWORD targetProcessId;
int APIENTRY DllMain(HMODULE hModule, DWORD reason, LPVOID reserved)
{
PROCESSENTRY32 entry;
entry.dwSize = sizeof(PROCESSENTRY32);
HANDLE snapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, NULL);
if (Process32First(snapshot, &entry) == TRUE)
{
while (Process32Next(snapshot, &entry) == TRUE)
{
if (_stricmp(entry.szExeFile, "target.exe") == 0)
{
targetProcessId = entry.th32ProcessID;
}
}
}
CloseHandle(snapshot);
if (reason == DLL_PROCESS_ATTACH)
{
if (GetCurrentProcessId() == targetProcessId)
{
//MY Code
}
}
return true;
}
I wont to detour PlaySoundW function inside Minesweeper.
Game is crashing as soon as it calls PlaySoundW function.
If I uncomment Beep inside my code, game beeps and than crashes.
Now code is calling original function from hooked function so it should't do anything. But it is crashing anyway.
Can you tell me what is wrong?
After debugging app in Olly I found that when detour is active not all rubbish is popped out of stack.
How to fix it?
This is my code:
#include <Windows.h>
#include <tchar.h>
#include <detours.h>
namespace Hooks
{
BOOL(__stdcall *OrgPlaySoundW)(LPCTSTR pszSound, HMODULE hmod, DWORD fdwSound) = &PlaySoundW;
BOOL HookPlaySoundW(LPCTSTR pszSound, HMODULE hmod, DWORD fdwSound)
{
//Beep(1000, 250);
//return TRUE;
return OrgPlaySoundW(pszSound, hmod, fdwSound);
}
void DetourPlaySoundW(BOOL disable)
{
if(!disable)
{
DetourTransactionBegin();
DetourUpdateThread(GetCurrentThread());
DetourAttach(&(PVOID&)OrgPlaySoundW, &HookPlaySoundW);
DetourTransactionCommit();
} else
{
DetourTransactionBegin();
DetourUpdateThread(GetCurrentThread());
DetourDetach(&(PVOID&)OrgPlaySoundW, &HookPlaySoundW);
DetourTransactionCommit();
}
}
}
BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
switch(fdwReason)
{
case DLL_PROCESS_ATTACH:
Hooks::DetourPlaySoundW(FALSE);
break;
case DLL_PROCESS_DETACH:
Hooks::DetourPlaySoundW(TRUE);
break;
}
return TRUE;
}
Try setting the calling convention of HookPlaySoundW to __stdcall (because the CC of PlaySoundW is also __stdcall (from Windows.h): WINMMAPI BOOL WINAPI PlaySoundW( __in_opt LPCWSTR pszSound, __in_opt HMODULE hmod, __in DWORD fdwSound);).
I have worked with detours before and after a casual glance everything looks correct except what I mentioned above. If this doesn't resolve your problem I'd be glad to do some further investigation.
The default setting for Visual C++ is __cdecl in which the call*er* cleans up the stack, but in __stdcall the call*ee* cleans up the stack. This is probably (i.e. might possibly be) the reason for all the "rubbish being popped off the stack".
I want to have a static global std::unordered_map in the cpp of my entry point for my COM server.
relevant header code:
typedef unordered_map<HWND,IMyInterface*> MyMapType;
relevant body:
static MyMapType MyMap;
void MyFunction(HWND hWnd, IMyInterface* pObj){
MyMap[hWnd] = pObj;
}
HINSTANCE g_hInstModule = NULL;
BOOL WINAPI DllMain ( __in HINSTANCE hInstDLL, __in DWORD fdwReason, __in LPVOID lpvReserved )
{
if( fdwReason == DLL_PROCESS_ATTACH )
{
g_hInstModule = hInstDLL;
return true;
}
else if( fdwReason == DLL_PROCESS_DETACH )
{
return true;
}
return false;
}
MyCoClass::MyCoClass()
{
DRM_Refcount = 1;
}
HRESULT STDMETHODCALLTYPE MyCoClass::InitMyCoClass()
{
CoInitializeEx(NULL, COINIT_APARTMENTTHREADED);
//replace with make window code
MyFunction(hWnd,ISomeInterface);
return S_OK;
}
The only way I can get this to work is be making a map_type pointer and creating an instance of map_type on the heap and pointing at it with the global pointer. :/
WHY?
You need to modify DllMain to explicitly initialize the C runtime: http://support.microsoft.com/kb/814472
Search for "To Modify COM-based DLL"
Static objects with constructors usually get initialized through the CRT entry point which for .exes then calls your program's main function. With DLLs, you have to the work yourself.