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.
Related
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.
I posted a recent question on SO about code injection, this one is similar but not the same. I am injecting dll into Firefox, it injects successfully but the code in the DLL doesn't run. If i inject the same code into a custom application, it works. Why might that be. This is the code that I'm using.
Injector.exe // the file that's injecting the code
#include <stdio.h>
#include <windows.h>
#define procId 2844
#define dllname "dllinject.dll" // located in same directory
int main()
{
HANDLE hProc = OpenProcess(PROCESS_ALL_ACCESS, false, procId);
LPVOID allocated = (LPVOID)VirtualAllocEx(hProc, NULL, strlen(dllname), MEM_RESERVE|MEM_COMMIT, PAGE_READWRITE);
WriteProcessMemory(hProc, (LPVOID)allocated, dllname, strlen(dllname), NULL);
LPVOID libaddr = (LPVOID)GetProcAddress(GetModuleHandle("kernel32.dll"), "LoadLibraryA");
CreateRemoteThread(hProc, NULL, NULL, (LPTHREAD_START_ROUTINE)libaddr, NULL, NULL);
CloseHandle(hProc);
return 0;
}
Simpleinjected.exe // the file being injected
#include <stdio.h>
int main()
{
printf("Hello");
return 0;
}
dllinject.dll
#include <windows.h>
int message(const char *msg)
{
MessageBox(NULL, msg, "Message from Dll", MB_OK);
return 0;
}
BOOL WINAPI DLLMain(HINSTANCE hInstDll, DWORD ulReason, LPVOID lpReserved)
{
switch(ulReason)
{
case DLL_PROCESS_ATTACH:
message("process attach");
break;
case DLL_THREAD_ATTACH:
message("thread attach");
break;
case DLL_PROCESS_DETACH:
message("process detach");
break;
case DLL_THREAD_DETACH:
message("thread detach");
break;
}
return true;
}
It works when injected into simpleinjected.exe but when injected in Firefox, nothing happens even though the dll is injected successfully.
I cannot reproduce your observations. I was able to inject dllinject.dll into other processes (also firefox) but I've never seen a message box.
After a bit of digging I found that your DLLMain is spelled wrong. Change it into DllMain and you'll see message boxes in Firefox.
By the way: You propably want to change MessageBox into MessageBeep since FireFox creates/destroys a lot of threads... (this is annoying even for a quick test!)
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);
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?
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".