Hooking with DLL/ASI - c++

Good afternoon all, I have a slight problem.
I'm using Microsoft Detours 3.0 to hook a game, call my function and change some data.
Now, When I load the game, it's like my ASI file doesn't even exist.
Now, I'm wondering weather this is because I'm hooking the wrong address or the way I've wrote the hook does not work.
Here's my Dllmain:
BOOL APIENTRY dllmain(HINSTANCE hinstDLL, DWORD nReason, LPVOID lpvReserved)
{
switch(nReason)
{
case DLL_PROCESS_ATTACH:
OriginalFunction = (int(_cdecl*)(int))DetourFunction((PBYTE)GameLoading, (PBYTE)ChangeLoadingBarColor);
case DLL_PROCESS_DETACH:
break;
case DLL_THREAD_ATTACH:
break;
case DLL_THREAD_DETACH:
break;
}
return TRUE;
}
My Hook function is here:
BYTE ChangeLoadingBarColor(int a, DWORD Bar_color_R,DWORD Bar_color_G,DWORD Bar_color_B,BYTE Bar_color_set_R,BYTE Bar_color_set_G,BYTE Bar_color_set_B)
{
return *(BYTE*)Bar_color_R;
return *(BYTE*)Bar_color_G;
return *(BYTE*)Bar_color_B;
*(BYTE*)Bar_color_R = Bar_color_set_R;
*(BYTE*)Bar_color_G = Bar_color_set_G;
*(BYTE*)Bar_color_B = Bar_color_set_B;
return OriginalFunction(a);
}
And here's the defined addresses and pointer to the original function:
DWORD Bar_color_R = 0x4A6B80;
DWORD Bar_color_G = 0x4A6B7E;
DWORD Bar_color_B = 0x4A6B7C;
DWORD Bar_color_set_R = {5};
DWORD Bar_color_set_G = {54};
DWORD Bar_color_set_B = {250};
DWORD GameLoading = 0x587F00;
int (_cdecl* OriginalFunction) (int);
Is my code correctly hooking the specified GameLoading address or is it wrong?

Related

MS Detours detoured function not being called

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?

thread hungs,high cpu, c++

i have code like this:
bool isActive = false;
DWORD WINAPI 123Thread(LPVOID);
DWORD WINAPI 123Thread(LPVOID)
{
while (1)
{
if (GetAsyncKeyState(VK_NUMPAD1))
{
MessageBox(0,L"1234456",L"6544321", MB_OK);
}
return 1;
}
}
DWORD APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved)
{
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
CreateThread(NULL, NULL, 123Thread, NULL, NULL, NULL);
case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
case DLL_PROCESS_DETACH:
break;
}
return true;
}
everything works ok,but CPU initilization is very high,and app crashes after 5-10 min work.in Proccess Explorer my dll state everytime is "Running" with extremly number of cycles,but others similiar dll show state like "Wait:WrUserRequest".how can i solve this problem?
Your 123 tread is looping infinitely keeping the cpu busy all the time. Put a sleep after GetAsyncKeyState call:
std::this_thread::sleep_for(std::chrono::milliseconds(x));
While sleeping, your process won't consume CPU resources. There might be some overhead since the kernel has to juggle processes around, but that is very insignificant.

Call function from thread created via CreateRemoteThread

I'm studying dll injection and so far I managed to inject a dll in a process causing the message box to show up.
The part I didn't quite understand, even after tons of readings and research, is how I pass a parameter to the dll, or call a specific function within it.
The dll:
extern "C" __declspec(dllexport) bool WINAPI
DllMain(HINSTANCE hInstDll, DWORD fdwReason, LPVOID lpvReserved)
{
switch (fdwReason)
{
case DLL_PROCESS_ATTACH:
{
MessageBoxA(NULL, "Hello World!", "Dll says:", MB_OK);
break;
}
case DLL_PROCESS_DETACH:
break;
case DLL_THREAD_ATTACH:
break;
case DLL_THREAD_DETACH:
break;
}
return true;
}
The injection:
char dllPath[] = "sampleDll.dll";
// For dll path injection.
int memAmountToAllocate = strlen(dllPath);
LPVOID dllPathAddress = VirtualAllocEx(procHandle, 0, memAmountToAllocated, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
FARPROC loadLibraryAddr = GetProcAddress(GetModuleHandle("kernel32.dll"), "LoadLibraryA");
WriteProcessMemory(procHandle, dllPathAddress, dllPath, memAmountToAllocated, 0);
// creating a thread that will call LoadLibraryA with allocMemAddress as argument
CreateRemoteThread(procHandle, 0, 0, loadLibraryAddr, dllPathAddress, 0, 0);
As I said, the injection works fine, i.e. the message box appears.
But say I have a method in the dll foo(LPVOID ptrToData). How can I call the foo function?
I have the address of the function I want to execute on the target process, it is an adding function, so I need to pass x and y.
I can call the function like this
_asm
{
push 0;
push 0x7;
mov ecx, esi;
mov eax, 0x41367C;
call eax;
}
however the values for push must come from the injecting process.
How can I do that?
The solution to my problem was to use an IPC mechanism to allow my main application and dll to communicate.
I used a named pipe.
I created the pipe in C# and then when I inject the dll I connect to the pipe.

process crashes when I read/write memory with dll injection

I wrote a hackme program and I want to hook it and make bruteforce to crack it (with dll injection).
the problem is when I'm trying to write or read the memory, the process crashes (its happens to me not only with the hackme program, but every program), although I give myself writing and reading privilleges with VirtualProtect.
If I add messagebox to the dll, the messagebox works.
here is the dll that supposed to prevent from the process to print something (with NOPing):
#include "DLL.h"
#include <windows.h>
#include <tlhelp32.h>
BOOL APIENTRY DllMain(HINSTANCE hInst, DWORD reason, LPVOID reserved)
{
switch (reason)
{
case DLL_PROCESS_ATTACH:
DWORD threadId;
CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)&ThreadProc, NULL, 0, &threadId);
break;
case DLL_PROCESS_DETACH:
break;
case DLL_THREAD_ATTACH:
break;
case DLL_THREAD_DETACH:
break;
}
return true;
}
DWORD ThreadProc(LPVOID lpdwThreadParam)
{
VirtualProtect((LPVOID)0x00417D10, 5, PAGE_EXECUTE_READWRITE, NULL);
*(char *)0x00417D10 = 0x90;
*(char *)0x00417D11 = 0x90;
*(char *)0x00417D12 = 0x90;
*(char *)0x00417D13 = 0x90;
*(char *)0x00417D14 = 0x90;
return 0;
}
here's the information about the address in the process that I'm writing to:
http://prntscr.com/2bveja (with IDA)
the dll, the injector and the hackme are compiled for 32bit.
I'm using win7 64b.
There were 2 problems:
VirtualProtect can not receive NULL in the last parameter (old privilege).
Therefore I gave it pointer to DWORD variable.
I gave the VirtualProtect a permanent address, but it was not good, since in windows 7 the image base changes every execution, so I found out the process image base and added it the offset 0x12d1.
HMODULE hand = GetModuleHandle(L"HackMe.exe");
VirtualProtect((LPVOID)((DWORD)hand + (DWORD)0x12d1), 6, PAGE_EXECUTE_READWRITE, &oldp);

MS Detours 2.1 - Popping out of stack

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".