DllMain wird nicht ausgeführt

[2n0w]

Hi,
hab hier folgendes Problem, will MessageBoxW hooken, allerdings wird scheinbar DllMain nicht mal ausgeführt.. da denke ich jetzt versteh ich das Hooken einmal, dann scheitere ich schon am erstellen einer DLL xD
Nach dem Injecten passiert einfach nichts o.0
Habs bei einem selbst erstellten Programm getestet, das in einem Endlosloop MessageBoxW aufruft.
Verwende VS2010.
Hab Win32 Project -> DLL ausgewählt (mit precompiled header).
Hab jetzt echt keine Ahnung an was es scheitert.
Bitte helft mir ^^
Danke im Voraus.
Hier wäre der Source:

// dllmain.cpp : Defines the entry point for the DLL application.
#include "stdafx.h"

#define SIZE 6

typedef int (WINAPI *pMessageBoxW) (HWND, LPCWSTR, LPCWSTR, UINT);
int WINAPI MyMessageBoxW(HWND, LPCWSTR, LPCWSTR, UINT);

void BeginRedirect(LPVOID);

pMessageBoxW pOrigMBAdress = NULL;
BYTE oldBytes[SIZE] = {0};
BYTE JMP[SIZE] = {0};
DWORD oldProtect, myProtect = PAGE_EXECUTE_READWRITE;


BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
					 )
{
	switch (ul_reason_for_call)
	{
	case DLL_PROCESS_ATTACH:
		pOrigMBAdress = (pMessageBoxW) GetProcAddress(GetModuleHandle(L"user32.dll"), "MessageBoxW");
		if(pOrigMBAdress != NULL)
		{
			BeginRedirect(MyMessageBoxW);
		}else
		{
			OutputDebugString(L"Failed to get Procadress");
		}
		break;
	case DLL_THREAD_ATTACH:
	case DLL_THREAD_DETACH:
	case DLL_PROCESS_DETACH:
		memcpy(pOrigMBAdress, oldBytes, SIZE);
		break;
	}
	return TRUE;
}

void BeginRedirect(LPVOID newFunction)
{
	OutputDebugString(L"Beginning Redirect");
	BYTE tempJMP[SIZE] = {0xe9, 0x90, 0x90, 0x90, 0x90, 0xc3};
	memcpy(JMP, tempJMP, SIZE);
	DWORD JMPSize((DWORD) newFunction - (DWORD)pOrigMBAdress - 5);
	VirtualProtect((LPVOID)pOrigMBAdress, SIZE, myProtect, &oldProtect);
	memcpy(oldBytes, pOrigMBAdress, SIZE);
	memcpy(&JMP[1], &JMPSize, 4);
	memcpy(pOrigMBAdress, JMP, SIZE);
	VirtualProtect((LPVOID)pOrigMBAdress, SIZE, oldProtect, NULL);
}

int WINAPI MyMessageBoxW(HWND hWnd, LPCWSTR lpText, LPCWSTR lpCaption, UINT uiType)
{
	OutputDebugString(L"Hook func called");
	//Unhook
	VirtualProtect((LPVOID)pOrigMBAdress, SIZE, myProtect, NULL);
	memcpy(pOrigMBAdress, oldBytes, SIZE);
	//TODO: Add code here
	int retValue = MessageBoxW(hWnd, L"Hooked Messagebox", lpCaption, uiType);
	memcpy(pOrigMBAdress, JMP, SIZE);
	VirtualProtect((LPVOID)pOrigMBAdress, SIZE, oldProtect, NULL);
	return retValue;
}

[Nightblizard]

Sweet Jesus, you're doing it totally wrong!

Du hast da hochexplosiven Code geschrieben und ich würde fast darauf wetten, dass es sich hierbei um ein Deadlock handelt (ohne mir auch nur eine Zeile genauer angesehen zu haben).

Ein wenig Lektüre zum Thema Programmcode in DllMain:






Du solltest dein Programm auf jeden Fall entsprechend anpassen!
Mein Rat: Die Finger komplett von der DllMain lassen, wenn du nicht gerade Variablen in ihr initialisierst. Das Teil ist eine Zeitbombe!

Und selbst wenn es nicht daran liegt, du hast dann immerhin sauberen Code geschrieben.

[2n0w]

Mir reicht's für heute
Werde ich morgen versuchen.
Danke für deine Antwort!

[Dr. Coxxy]

debugger dranhängen und gucken ob die outputdebugstrings worken?

EDIT:
ihr immer mit eurem deadlock...
werden nur funcs aus kernel benutzt und die funktion hängt auch nicht, also kein grund sich künstlich aufzuregen.
ist natürlich nicht sauber aber kein grund für panikmache.

[MrSm!th]

Nö, ein Deadlock sollte es da nicht geben.

Dennoch:


Nimm MS Detours anstatt solcher eigenen Kopievorgänge.

Du solltest dein Programm auf jeden Fall entsprechend anpassen!
Mein Rat: Die Finger komplett von der DllMain lassen, wenn du nicht gerade Variablen in ihr initialisierst. Das Teil ist eine Zeitbombe!

Und wie soll es deiner Meinung nach gehen, wenn man nichtmal nen Thread erstellen darf?

[2n0w]

Funktioniert jetzt, vielen Dank für die Antworten!
Ob das sauber ist, ist jetzt ne andere Sache.. da schaue ich morgen weiter :P
Eigentlich wollte ich das ja absichtlich manuell machen, damit ich verstehe wie das funktioniert, werde es morgen auch noch mit Detours versuchen.

BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
					 )
{
	DisableThreadLibraryCalls(hModule);
	switch (ul_reason_for_call)
	{
	case DLL_PROCESS_ATTACH:
		CreateThread(NULL, NULL,(LPTHREAD_START_ROUTINE)&initHook, NULL, NULL, NULL); 
		return TRUE;
	case DLL_THREAD_ATTACH:
	case DLL_THREAD_DETACH:
	case DLL_PROCESS_DETACH:
		memcpy(pOrigMBAdress, oldBytes, SIZE);
		break;
	}
	return TRUE;
}

[Nightblizard]

Originally Posted by MrSm!th

Und wie soll es deiner Meinung nach gehen, wenn man nichtmal nen Thread erstellen darf?

Eine Funktion exportieren und diese dann aufrufen.

In der Dll:

void __declspec(dllexport) Start()
{
     std::cout << "foo" << std::endl;
}

In deinem Programm:

__declspec(dllimport) void Start();

int main()
{
     //...
     Start();
}

Solltest du die dll in einen fremden Prozess injizieren, kannst du die Adresse der Funktion über GetProcAddress oder über die EAT herausfinden. Ziemlich straight forward.

Originally Posted by Dr. Coxxy

werden nur funcs aus kernel benutzt

-> User32.dll
Aber du hast recht, es handelt sich hier fast nur um Funktionen aus Kernel32.dll, da habe ich ein wenig überreagiert, dennoch ist das absolut nicht empfehlenswert!
Meine Devise lautet Fehlerquellen aus den Weg räumen und nicht sie lediglich zu umgehen.

[Dr. Coxxy]

Originally Posted by Nightblizard

-> User32.dll

ruft er ja nirgends auf, holt sich mit getprochandle die adresse und prüft diese sogar.

[MrSm!th]

Originally Posted by 2n0w

Funktioniert jetzt, vielen Dank für die Antworten!
Ob das sauber ist, ist jetzt ne andere Sache.. da schaue ich morgen weiter :P
Eigentlich wollte ich das ja absichtlich manuell machen, damit ich verstehe wie das funktioniert, werde es morgen auch noch mit Detours versuchen.

BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
					 )
{
	DisableThreadLibraryCalls(hModule);
	switch (ul_reason_for_call)
	{
	case DLL_PROCESS_ATTACH:
		CreateThread(NULL, NULL,(LPTHREAD_START_ROUTINE)&initHook, NULL, NULL, NULL); 
		return TRUE;
	case DLL_THREAD_ATTACH:
	case DLL_THREAD_DETACH:
	case DLL_PROCESS_DETACH:
		memcpy(pOrigMBAdress, oldBytes, SIZE);
		break;
	}
	return TRUE;
}

Wehe initHook ist vom Typen void!

Originally Posted by Nightblizard

Eine Funktion exportieren und diese dann aufrufen.

Klasse! Wir reden hier von Dll-Injection.

Solltest du die dll in einen fremden Prozess injizieren, kannst du die Adresse der Funktion über GetProcAddress oder über die EAT herausfinden. Ziemlich straight forward.

Ja, oder man lässt es und nutzt die dafür gedachte DllMain.
Normalerweise gehören in diese nur die allernötigsten Initialisierungen und die Erstellung eines neuen Threads und genau das passiert hier.
Solange man auf diesen nicht wartet, kann es auch nicht zu einem Deadlock kommen.
Und im Gamehacking, wo es sowieso schmutzig zugeht, kann man sich sowas ruhig erlauben.
Und nebenbei hilft DisableThreadLibraryCalls da ja auch ab.

Ergänzend noch:

Sollte man vielleicht aber doch mal tun.

Wie schon gesagt wurde, MessageBox ruft er in der DllMain nicht auf.

[Tyrar]

mit exportierten funktionen zu arbeiten is auch bei injections kein problem D:

mein M2XT v2 läuft komplett sauber (mit allem was dazu gehört) - ohne DllMain!

[Nightblizard]

Originally Posted by MrSm!th

Klasse! Wir reden hier von Dll-Injection.

Und? Selbst dann ist es kein Problem mit exportierten Funktionen zu arbeiten!

Originally Posted by MrSm!th

Und im Gamehacking, wo es sowieso schmutzig zugeht, kann man sich sowas ruhig erlauben.

Das ist doch kein Argument... Schreib du nochmal irgendwo etwas gegen system() oder void main, ich werde darauf zurückkommen!

Originally Posted by MrSm!th

Sollte man vielleicht aber doch mal tun.

Wie schon gesagt wurde, MessageBox ruft er in der DllMain nicht auf.

Ja, sollte man.
Dennoch, in der DllMain arbeiten ist unklug und ausgehend von der Tatsache, dass das Programm noch wachsen wird, ist der Gedanke auch nicht falsch.
Und am Ende habe ich mir ja noch die Türe mit dem "fast" offen gehalten, der Satz hat so gar keine Gewichtung.

Originally Posted by HeavyHacker

mein M2XT v2 läuft komplett sauber (mit allem was dazu gehört) - ohne DllMain!

Meine Library erfordert das exportieren einer Funktion mit dem Namen "Start", wenn du eine Dll injizieren möchtest. Es gibt keinen Grund DllMain in die .dll zu schreiben.

[2n0w]

Für den Anfang ist das dann doch ein bisschen viel für mich, ich bleibe erstmal dabei in DllMain nen Thread zu starten.
@MrSm!th
Natürlich ist initHook BOOL

Danke für die Hilfe

[MrSm!th]

Originally Posted by Nightblizard

Und? Selbst dann ist es kein Problem mit exportierten Funktionen zu arbeiten!

Es macht unnötige Arbeit.

Das ist doch kein Argument... Schreib du nochmal irgendwo etwas gegen system() oder void main, ich werde darauf zurückkommen!

void main ist schlicht und ergreifend falsch.
system() sehe ich selten in Hacks, eher in normalen Programmen und den Anfänger-Tools und gerade Anfänger sollten es sich gerade nicht angewöhnen.
Ein Hacker sollte wissen, dass er sich sowas nicht angewöhnt. Außerdem ist zwischen Gamehacking im Sinne von ein Konsolentool, das mit WriteProcessMemory 1-2 Werte umschreibt und Gamehacking mit Dll-Injection, viel lowlevel Arbeit und am besten noch inline ASM nochmal ein Unterschied. Dll-Injection selbst ist schon ein Exploit und nicht gerade sauber. Da pfeife ich doch darauf, ob es gut oder schlecht ist, die Dll Main zu nutzen.
Die Standardprozedur sieht so aus, dass man einen neuen Thread erstellt, quasi den eigentlichen Main Thread der Dll. Dort findet alles weitere statt. Egal, wie sehr er die Dll noch erweitert, das sollte sich niemals verändern und demnach geht davon auch keine Gefahr aus.
Und wie gesagt, es gibt immer noch DisableThreadLibraryCalls.

Meine Library erfordert das exportieren einer Funktion mit dem Namen "Start", wenn du eine Dll injizieren möchtest. Es gibt keinen Grund DllMain in die .dll zu schreiben.

Genau so gibt es auch keinen sich die Extra-Arbeit zu machen.

Natürlich ist initHook BOOL

Dafuq? Ich hoffe das ist Ironie.
Ich habs doch nicht so mit Ironie

[2n0w]

Originally Posted by MrSm!th

Dafuq? Ich hoffe das ist Ironie.
Ich habs doch nicht so mit Ironie

Mit void war nicht der Rückgabetyp gemeint, oder?
Es sieht so aus:

BOOL initHook()
{}

Sollte ich's so machen?

LPTHREAD_START_ROUTINE initHook()
{}

Oder hat das was mit Funktionszeiger zu tun? ^^
Mit denen kenne ich mich leider nicht aus, programiere eigentlich fast nie in C.. sollte ich mir wohl mal genauer anschauen.

[Nightblizard]

Originally Posted by MrSm!th

Es macht unnötige Arbeit.

Sicheren, sauberen Code zu schreiben ist unnötige Arbeit? Uff, unsere Ansichten sind doch sehr verschieden!

Originally Posted by MrSm!th

void main ist schlicht und ergreifend falsch.

Das hatten wir erst vor kurzem und es ist zumindest mit dem Windows Compiler nicht falsch.

Originally Posted by MrSm!th

system() sehe ich selten in Hacks, eher in normalen Programmen und den Anfänger-Tools und gerade Anfänger sollten es sich gerade nicht angewöhnen.

Ersetze system() mit DllMain. system hat "lediglich" Performanceschwächen, DllMain kann dir dein Programm killen. Keine Ahnung wie du gewichtest, aber wenn ich die Wahl hätte buße ich lieber etwas performance ein, als mit der Möglichkeit eines Deadlocks weiterarbeiten zu müssen.

Originally Posted by MrSm!th

Ein Hacker sollte wissen, dass er sich sowas nicht angewöhnt.

Aber genau das tuen sie nicht. Viele haben deine Einstellung und sagen "schmutziges Geschäft, schmutziger Programmcode" (so kommt zumindest deine Aussage rüber) und arbeiten dementsprechend. Da muss man einfach hart bleiben und die Leute zum Einlenken bewegen.

Originally Posted by MrSm!th

Außerdem ist zwischen Gamehacking im Sinne von ein Konsolentool, das mit WriteProcessMemory 1-2 Werte umschreibt und Gamehacking mit Dll-Injection, viel lowlevel Arbeit und am besten noch inline ASM nochmal ein Unterschied.

Das stimmt nicht. Ich kann beides sehr gewissenhaft, robust und performant gestalten. Der Kosten/Nutzen Faktor rechnet sich, nach meinen Erfahrungen, _immer_ in der Programmierung!

Originally Posted by MrSm!th

Dll-Injection selbst ist schon ein Exploit und nicht gerade sauber. Da pfeife ich doch darauf, ob es gut oder schlecht ist, die Dll Main zu nutzen.

Siehe oben. Aus "schmutziges Geschäft, schmutziger Programmcode" wächst Code wie dieser:
Das bezieht sich nicht unbedingt auf dich, aber de facto sind viele Anfänger davon betroffen.

Originally Posted by MrSm!th

Die Standardprozedur sieht so aus, dass man einen neuen Thread erstellt, quasi den eigentlichen Main Thread der Dll. Dort findet alles weitere statt. Egal, wie sehr er die Dll noch erweitert, das sollte sich niemals verändern und demnach geht davon auch keine Gefahr aus.

Doch, tut es. Wartet er auf Beendigung des Threads ist feierabend. Aber ich bezog mich auch gar nicht auf das Erstellen eines Threads in DllMain. Das ist zwar auch nicht ganz so schön, aber so lange man wirklich nur den Thread erstellt okay.
Schaue dir seinen ursprünglichen Code an, da erstellt er noch keinen Thread und daher auch die ganzen Links mit Infomaterial.
Er hat es auch sofort abgeändert, sprich er hat verstanden worum es geht! Ziel erreicht, mehr wollte ich nicht.

Originally Posted by MrSm!th

Und wie gesagt, es gibt immer noch DisableThreadLibraryCalls.

Darum geht es mir nicht, da auch das nicht im ursprünglichen Quellcode drinnen war.

Originally Posted by MrSm!th

Genau so gibt es auch keinen sich die Extra-Arbeit zu machen.

Wie bereits gesagt, unsere Ansichten scheinen recht verschieden zu sein. Ich versuche so sauber wie möglich zu arbeiten und da meine Lib open source ist, sitzt der angestrebte Level nocheinmal etwas höher.
Und am Ende war es lediglich mehr Aufwand für mich, der User merkt davon kaum etwas. Das läuft dann so ab:

//user .dll

void __declspec(dllexport) Start()
{
    //programmcode. läuft in einem eigenen thread
}

//user injector
void foo()
{
     Module loadedDll;
     auto startAddress = Injector::Inject(process, _T("dllPath.dll"), loadedDll);
     Injector::CallStart(process, startAddress);
     //...
     Injector::UnloadDll(process, loadedDll);
}

Das ist nicht nur sicherer, sondern auch viel flexibler als Code in DllMain zu packen! So kann ich bestimmen wann das Ganze starten soll!
Und wenn Sicherheit und Flexibilität für mich ein paar Zeilen Code mehr bedeuten (ich glaube es waren ca. 5 Stück), dann gehe ich den Deal ohne nachzudenken ein!
Die Arbeit sieht der User gar nicht.


@2n0w:

DWORD WINAPI initHook(LPVOID lpThreadParameter)