[C++] Eigene Detours Teil2

xNopex · 04/06/2010, 11:49

Ein zweites dickes Hallo an Alle,

Nachdem wir uns in Teil 1 des Tutorials darum gekümmert haben, die Detour Funktion zu programmieren, geht’s in Teil 2 darum, diese Funktion richtig anzuwenden. Dazu schreiben wir uns zuerst ein „Opfer“-Programm:

Code:

#include <iostream>
#include <windows.h>

using namespace std;

void NormaleFunc()
{
    cout << "Von EXE\n";
}

int main( int argc, char** argv )
{
    while( true )
    {
        NormaleFunc();
        Sleep( 250 );
    }

    return 0;
}

Es sollte klar sein, was das Programm macht: Es wird in einer Endlosschleife die Funktion NormaleFunc() aufgerufen, die den Text „Von EXE“ in die Konsole schreibt. Genau diese Funktion wollen wir jetzt mit einem Detour versehen. Damit unsere Detour-Funktion korrekt arbeitet, müssen wir sie in Form einer DLL in den Zielprozess injezieren. Also erstellen wir nun diese DLL:

Code:

#include <windows.h>
#include <iostream>

DWORD WINAPI Thread( LPVOID lpParam )
{
	return 0;
}


BOOL APIENTRY DllMain( HMODULE hModule, DWORD  ul_reason_for_call, LPVOID lpReserved )
{
	if( ul_reason_for_call == DLL_PROCESS_ATTACH )
	{
		HANDLE hThread = CreateThread( NULL, 0, Thread, NULL, 0, NULL );
		CloseHandle( hThread );
	}

	return TRUE;
}

Viel ist noch nicht passiert. Wir erstellen in der DLL-Main einen Thread, der sich aber auch gleich wieder schließt, nachdem er gestartet wurde. In diesem Thread werden wir später unsere Detour-Funktion aufrufen. Wenn wir sie aufrufen wollen, müssen wir sie ja auch erstmal definieren:

Code:

#include <windows.h>
#include <iostream>

bool DetourFunc( BYTE* oldFunc, BYTE* newFunc, DWORD len )
{
    BYTE* newMem4base = NULL;
    DWORD dwOld;

    newMem4base = ( BYTE* )malloc( 5+len );

    if( newMem4base == NULL )
        return false;

    for( DWORD i = 0; i < ( len+5 ); i++ )
        newMem4base[i] = 0x90;

    VirtualProtect( oldFunc, len, PAGE_READWRITE, &dwOld );

    memcpy( newMem4base, oldFunc, len );
    oldFunc[0] = 0xE8;
    *( DWORD* )( oldFunc+0x01 ) = DWORD( newFunc-oldFunc-5 );
    oldFunc[5] = 0xE9;
    *( DWORD* )( oldFunc+0x06 ) = DWORD( newMem4base-( oldFunc+0x5 )-5 );
    newMem4base += len;
    newMem4base[0] = 0xE9;
    *( DWORD* )( newMem4base+0x01 ) = DWORD( ( oldFunc+10 )-newMem4base-5 );

    for( DWORD i = 10; i <len; i++ )
        oldFunc[i] = 0x90;

    return true;
}


DWORD WINAPI Thread( LPVOID lpParam )
{
	return 0;
}


BOOL APIENTRY DllMain( HMODULE hModule, DWORD  ul_reason_for_call, LPVOID lpReserved )
{
	if( ul_reason_for_call == DLL_PROCESS_ATTACH )
	{
		HANDLE hThread = CreateThread( NULL, 0, Thread, NULL, 0, NULL );
		CloseHandle( hThread );
	}

	return TRUE;
}

So nun müssen wir uns so langsam mal Gedanken über die Parameter unserer Detour-Funktion machen. Als erstes benötigen wir die Adresse der Funktion, die mit unserem Detour versehen werden soll. Also die Adresse der Funktion aus unserem Opfer-Programm, die nichts weiter macht, als den Text „Von EXE“ in das Konsolenfenster zu schreiben. Erinnerst du dich? Frage: Wie kommen wir an diese Adresse? Antwort: OllyDbg  Diesen tollen Debugger wirst du dir jetzt herunterladen. Wenn er startbereit ist, starte Olly.
Drücke jetzt F3. Es öffnet sich ein kleines Fenster mittels dem du unsere Opfer-Exe öfnen musst. Hast du das Programm in Olly geöffnet, sollte sich das Fenster mit vielen Zahlen und Buchstaben gefüllt habe

Es sieht ungefähr so aus:

Klicke nun mit der rechten Maustaste auf das obere linke Fenster, das ich im Bild (s.o.) als „Für uns interssanter Teil“ gekennzeichnet habe. In dem sich öffnenden Dialog gehst du auf „Search For“ und dort auf „All referenced text strings“. Das Fenster sollte sich ein bisschen verändern. Lass uns nun kurz daran erinnern, was unsere Ur-Funktion macht. *Überleg* Genau, sie schreibt den Text „Von EXE“ in unsere Konsole. Also sollte die Startadresse unserer Funktion in der Nähe dieses Strings sein. Wir haben nun das Programm nach Strings absuchen lassen. Gefundene Zeichenketten zeigt uns Olly in dem neuen Fenster an. Und was ist denn das?

Der rot-Umrahmte String ist genau der, den wir gesucht haben. Klick doppelt auf ihn drauf und wir gelangen zurück zu dem Startfenster an die Adresse, an der der String steht. Wir haben bereits festgestellt, dass in der Nähe des Strings die Startadresse unserere Funktion liegen muss, also srollen wir ein bisschen hoch. Olly macht es uns insgesamt noch einfacher und setzt eine dicke, schwarze Klammer um den Adressenbereich, der zu einer Funktion gehört. Also schauen wir, wo diese Klammer beginnt und das ist exakt drei Zeilen weiter oben der Fall, bei mir die Adresse 0x004013EE. Bei dir muss es nicht zwangsläufig die gleiche Adresse sein:

Damit haben wir nun die Startadresse. Lass Olly aber nochmal offen, wir werden ihn gleich nochmal um Hilfe fragen müssen

Aber erstmal lass uns weiter programmieren:

Code:

#include <windows.h>
#include <iostream>

bool DetourFunc( BYTE* oldFunc, BYTE* newFunc, DWORD len )
{
    BYTE* newMem4base = NULL;
    DWORD dwOld;

    newMem4base = ( BYTE* )malloc( 5+len );

    if( newMem4base == NULL )
        return false;

    for( DWORD i = 0; i < ( len+5 ); i++ )
        newMem4base[i] = 0x90;

    VirtualProtect( oldFunc, len, PAGE_READWRITE, &dwOld );

    memcpy( newMem4base, oldFunc, len );
    oldFunc[0] = 0xE8;
    *( DWORD* )( oldFunc+0x01 ) = DWORD( newFunc-oldFunc-5 );
    oldFunc[5] = 0xE9;
    *( DWORD* )( oldFunc+0x06 ) = DWORD( newMem4base-( oldFunc+0x5 )-5 );
    newMem4base += len;
    newMem4base[0] = 0xE9;
    *( DWORD* )( newMem4base+0x01 ) = DWORD( ( oldFunc+10 )-newMem4base-5 );

    for( DWORD i = 10; i <len; i++ )
        oldFunc[i] = 0x90;

    return true;
}


DWORD WINAPI Thread( LPVOID lpParam )
{
	DetourFunc( ( BYTE* )0x004013EE,
	return 0;
}


BOOL APIENTRY DllMain( HMODULE hModule, DWORD  ul_reason_for_call, LPVOID lpReserved )
{
	if( ul_reason_for_call == DLL_PROCESS_ATTACH )
	{
		HANDLE hThread = CreateThread( NULL, 0, Thread, NULL, 0, NULL );
		CloseHandle( hThread );
	}

	return TRUE;
}

Ich habe mal angefangen die Detour-Funktion aus unserem Thread aufzurufen. Bis jetzt haben wir ja nur die Adresse der Ur-Funktion. Der zweite Parameter ist die Adresse der neuen Funktion. Dazu müssen wir jetzt erstmal die neue Funktion definieren:

Code:

#include <windows.h>
#include <iostream>

bool DetourFunc( BYTE* oldFunc, BYTE* newFunc, DWORD len )
{
    BYTE* newMem4base = NULL;
    DWORD dwOld;

    newMem4base = ( BYTE* )malloc( 5+len );

    if( newMem4base == NULL )
        return false;

    for( DWORD i = 0; i < ( len+5 ); i++ )
        newMem4base[i] = 0x90;

    VirtualProtect( oldFunc, len, PAGE_READWRITE, &dwOld );

    memcpy( newMem4base, oldFunc, len );
    oldFunc[0] = 0xE8;
    *( DWORD* )( oldFunc+0x01 ) = DWORD( newFunc-oldFunc-5 );
    oldFunc[5] = 0xE9;
    *( DWORD* )( oldFunc+0x06 ) = DWORD( newMem4base-( oldFunc+0x5 )-5 );
    newMem4base += len;
    newMem4base[0] = 0xE9;
    *( DWORD* )( newMem4base+0x01 ) = DWORD( ( oldFunc+10 )-newMem4base-5 );

    for( DWORD i = 10; i <len; i++ )
        oldFunc[i] = 0x90;

    return true;
}

void MyFunction()
{
	std::cout << "Von DLL. HGW dein Detour funktioniert :)\n";
}


DWORD WINAPI Thread( LPVOID lpParam )
{
	DetourFunc( ( BYTE* )0x004013EE,
	return 0;
}


BOOL APIENTRY DllMain( HMODULE hModule, DWORD  ul_reason_for_call, LPVOID lpReserved )
{
	if( ul_reason_for_call == DLL_PROCESS_ATTACH )
	{
		HANDLE hThread = CreateThread( NULL, 0, Thread, NULL, 0, NULL );
		CloseHandle( hThread );
	}

	return TRUE;
}

Direkt über unseren Thread habe ich die neue Funktion definiert. Sie macht auch nicht viel mehr als unsere Ur-Funktion. Auch sie schreibt nur einen Text in unser Konsolenfenster. Spannende Frage: Wie kommen wir an die Adresse der neuen Funktion? Brauchen wir dafür wieder Olly? Antwort: Nein. An die Adresse kommen wir viel leichter

Code:

#include <windows.h>
#include <iostream>

bool DetourFunc( BYTE* oldFunc, BYTE* newFunc, DWORD len )
{
    BYTE* newMem4base = NULL;
    DWORD dwOld;

    newMem4base = ( BYTE* )malloc( 5+len );

    if( newMem4base == NULL )
        return false;

    for( DWORD i = 0; i < ( len+5 ); i++ )
        newMem4base[i] = 0x90;

    VirtualProtect( oldFunc, len, PAGE_READWRITE, &dwOld );

    memcpy( newMem4base, oldFunc, len );
    oldFunc[0] = 0xE8;
    *( DWORD* )( oldFunc+0x01 ) = DWORD( newFunc-oldFunc-5 );
    oldFunc[5] = 0xE9;
    *( DWORD* )( oldFunc+0x06 ) = DWORD( newMem4base-( oldFunc+0x5 )-5 );
    newMem4base += len;
    newMem4base[0] = 0xE9;
    *( DWORD* )( newMem4base+0x01 ) = DWORD( ( oldFunc+10 )-newMem4base-5 );

    for( DWORD i = 10; i <len; i++ )
        oldFunc[i] = 0x90;

    return true;
}

void MyFunction()
{
	std::cout << "Von DLL. HGW dein Detour funktioniert :)\n";
}


DWORD WINAPI Thread( LPVOID lpParam )
{
	DetourFunc( ( BYTE* )0x004013EE, ( BYTE* )&MyFunction
	return 0;
}


BOOL APIENTRY DllMain( HMODULE hModule, DWORD  ul_reason_for_call, LPVOID lpReserved )
{
	if( ul_reason_for_call == DLL_PROCESS_ATTACH )
	{
		HANDLE hThread = CreateThread( NULL, 0, Thread, NULL, 0, NULL );
		CloseHandle( hThread );
	}

	return TRUE;
}

Ist äquivalent wie die Adressierung eines Zeigers auf eine Variable

Zu guter letzt brauchen wir noch die Anzahl der zu sichernden Bytes. Diese Größe kann auf keinsten Fall beliebig gewählt werden. Wenn du Glück hast läuft u.U. alles Glatt aber mit hoher Wahrscheinlichkeit wird es einige Probleme geben, wenn du die Größe beliebig festlegst! Zu allererst beträgt die Mindestgröße 10Bytes. Diese setzt sich zusammen aus dem CALL Befehl+Adresse (=5Bytes) und dem JMP Befehl+Adresse (=5Bytes). Beide zusammen machen eben 10Bytes. Jetzt kannst du aber auch nicht einfach immer die mindestgröße wählen, sondern das muss von Fall zu Fall angepasst werden. Warum? Das hat einen einfachen Grund. Ein paar Fakten: Der PUSH EBP (Das Ablegen eines Registers auf den Stack) nimmt genau die Größe von einem Byte ein. JMP und CALL nehmen jeweils 5Bytes ein. So haben wir z.B. folgende Befehlsreihe in unserer Funktion am Anfang:

PUSH EBP
JMP 32000000
CALL 4400000000

Dann machen alle drei Befehle insgesamt eine Größe von 11Bytes.Würden wir jetzt nur die ersten 10Bytes sichern und überschreiben, dann bleibt in der Ur-Funktion das letzte Byte übrig (0x00). Wir sichern ja die alten Bytes auf einem neuen Speicherblock. Und nach der Sicherung springen wir zurück zur Ur-Funktion. Gehen wir das mal durch. PUSH EBP braucht ein Byte. Bleiben noch 9 aus unserer Sicherung. JMP braucht 5Bytes. Bleiben noch 4Bytes aus der Sicherung. CALL braucht aber auch 5Bytes! Es sind aber nur noch 4übrig, da wir das letzte nicht mit gesichert haben. Problem! CALL nimmt sich aber 5Bytes. Was kam nach der Sicherung? Richtig der Jump zurück. Also nimmt sich CALL einfach das E9-Byte aus unserem Jump. Nicht gut. Damit kehren wir von unserem Speicherblock nichtmehr zurück zu unserer Ur-Funktion und landen irgendwo im Speicher-Nirvana… Ich hoffe du hast das bis jetzt einigermaßen verstanden

Ich fasse es mal zusammen:

Regeln für die Anzahl Bytes, die gesichert werden sollen:

1. Es müssen mindestens 10Bytes sein
2. Es müssen alle zu einem Befehl gehörigen Bytes gesichert werden

Schauen wir uns in Olly mal unsere Ur-Funktion an. Der erste Befehl ist PUSH EBP. Links neben dem Befehl können wir die Bytes zu dem Befehl sehen. Und es ist ein Byte. Zu wenig, wir brauchen mind. 10Bytes. Der nächste Befehl ist MOV EBP, ESP. Dieser ist 2Bytes groß. Insgesamt haben wir 3Bytes, immer noch zu wenig. Der nächste Befehl ist SUB ESP, 8. Dieser ist 3Bytes groß. Nun haben wir schon 6Bytes. Immer noch zu wenig. Ui der nächste Befehl ist lang

MOV blabla, blub. Dieser nimmt insgesamt 8Bytes ein. Wow. Mit den 6Bytes von vorhin haben wir 14Bytes. Das ist größer als 10. Damit hätten wir die Größe und wir könne sie als Parameter unserer Funktion übergeben:

Code:

#include <windows.h>
#include <iostream>

bool DetourFunc( BYTE* oldFunc, BYTE* newFunc, DWORD len )
{
    BYTE* newMem4base = NULL;
    DWORD dwOld;

    newMem4base = ( BYTE* )malloc( 5+len );

    if( newMem4base == NULL )
        return false;

    for( DWORD i = 0; i < ( len+5 ); i++ )
        newMem4base[i] = 0x90;

    VirtualProtect( oldFunc, len, PAGE_READWRITE, &dwOld );

    memcpy( newMem4base, oldFunc, len );
    oldFunc[0] = 0xE8;
    *( DWORD* )( oldFunc+0x01 ) = DWORD( newFunc-oldFunc-5 );
    oldFunc[5] = 0xE9;
    *( DWORD* )( oldFunc+0x06 ) = DWORD( newMem4base-( oldFunc+0x5 )-5 );
    newMem4base += len;
    newMem4base[0] = 0xE9;
    *( DWORD* )( newMem4base+0x01 ) = DWORD( ( oldFunc+10 )-newMem4base-5 );

    for( DWORD i = 10; i <len; i++ )
        oldFunc[i] = 0x90;

    return true;
}

void MyFunction()
{
	std::cout << "Von DLL. HGW dein Detour funktioniert :)\n";
}


DWORD WINAPI Thread( LPVOID lpParam )
{
	DetourFunc( ( BYTE* )0x004013EE, ( BYTE* )&MyFunction, 14 );
	return 0;
}


BOOL APIENTRY DllMain( HMODULE hModule, DWORD  ul_reason_for_call, LPVOID lpReserved )
{
	if( ul_reason_for_call == DLL_PROCESS_ATTACH )
	{
		HANDLE hThread = CreateThread( NULL, 0, Thread, NULL, 0, NULL );
		CloseHandle( hThread );
	}

	return TRUE;
}

Hui endlich fertig mit der DLL

Jetzt müssen wir diese nur noch in unser Zielprozess injezieren. Wie man einen Injektor programmiert, findest du

beschrieben.

Ich wünsche euch viel Spaß beim Programmieren

Wie immer wenn ihr Fehler findet, melden, ansonsten viel Spaß damit, würde mich über Feedback freuen.

Credits:
Nope

HardCore.1337 · 04/06/2010, 14:15

Auch wenn ich´s schon kenne, sieht sehr gut aus!

MrSm!th · 04/06/2010, 17:07

Quote:
Originally Posted by xNopex
Spoiler
Ein zweites dickes Hallo an Alle,

Nachdem wir uns in Teil 1 des Tutorials darum gekümmert haben, die Detour Funktion zu programmieren, geht’s in Teil 2 darum, diese Funktion richtig anzuwenden. Dazu schreiben wir uns zuerst ein „Opfer“-Programm:
Code:
#include <iostream>
#include <windows.h>

using namespace std;

void NormaleFunc()
{
    cout << "Von EXE\n";
}

int main( int argc, char** argv )
{
    while( true )
    {
        NormaleFunc();
        Sleep( 250 );
    }

    return 0;
}
Es sollte klar sein, was das Programm macht: Es wird in einer Endlosschleife die Funktion NormaleFunc() aufgerufen, die den Text „Von EXE“ in die Konsole schreibt. Genau diese Funktion wollen wir jetzt mit einem Detour versehen. Damit unsere Detour-Funktion korrekt arbeitet, müssen wir sie in Form einer DLL in den Zielprozess injezieren. Also erstellen wir nun diese DLL:
Code:
#include <windows.h>
#include <iostream>

DWORD WINAPI Thread( LPVOID lpParam )
{
	return 0;
}


BOOL APIENTRY DllMain( HMODULE hModule, DWORD  ul_reason_for_call, LPVOID lpReserved )
{
	if( ul_reason_for_call == DLL_PROCESS_ATTACH )
	{
		HANDLE hThread = CreateThread( NULL, 0, Thread, NULL, 0, NULL );
		CloseHandle( hThread );
	}

	return TRUE;
}
Viel ist noch nicht passiert. Wir erstellen in der DLL-Main einen Thread, der sich aber auch gleich wieder schließt, nachdem er gestartet wurde. In diesem Thread werden wir später unsere Detour-Funktion aufrufen. Wenn wir sie aufrufen wollen, müssen wir sie ja auch erstmal definieren:
Code:
#include <windows.h>
#include <iostream>

bool DetourFunc( BYTE* oldFunc, BYTE* newFunc, DWORD len )
{
    BYTE* newMem4base = NULL;
    DWORD dwOld;

    newMem4base = ( BYTE* )malloc( 5+len );

    if( newMem4base == NULL )
        return false;

    for( DWORD i = 0; i < ( len+5 ); i++ )
        newMem4base[i] = 0x90;

    VirtualProtect( oldFunc, len, PAGE_READWRITE, &dwOld );

    memcpy( newMem4base, oldFunc, len );
    oldFunc[0] = 0xE8;
    *( DWORD* )( oldFunc+0x01 ) = DWORD( newFunc-oldFunc-5 );
    oldFunc[5] = 0xE9;
    *( DWORD* )( oldFunc+0x06 ) = DWORD( newMem4base-( oldFunc+0x5 )-5 );
    newMem4base += len;
    newMem4base[0] = 0xE9;
    *( DWORD* )( newMem4base+0x01 ) = DWORD( ( oldFunc+10 )-newMem4base-5 );

    for( DWORD i = 10; i <len; i++ )
        oldFunc[i] = 0x90;

    return true;
}


DWORD WINAPI Thread( LPVOID lpParam )
{
	return 0;
}


BOOL APIENTRY DllMain( HMODULE hModule, DWORD  ul_reason_for_call, LPVOID lpReserved )
{
	if( ul_reason_for_call == DLL_PROCESS_ATTACH )
	{
		HANDLE hThread = CreateThread( NULL, 0, Thread, NULL, 0, NULL );
		CloseHandle( hThread );
	}

	return TRUE;
}
So nun müssen wir uns so langsam mal Gedanken über die Parameter unserer Detour-Funktion machen. Als erstes benötigen wir die Adresse der Funktion, die mit unserem Detour versehen werden soll. Also die Adresse der Funktion aus unserem Opfer-Programm, die nichts weiter macht, als den Text „Von EXE“ in das Konsolenfenster zu schreiben. Erinnerst du dich? Frage: Wie kommen wir an diese Adresse? Antwort: OllyDbg  Diesen tollen Debugger wirst du dir jetzt herunterladen. Wenn er startbereit ist, starte Olly.
Drücke jetzt F3. Es öffnet sich ein kleines Fenster mittels dem du unsere Opfer-Exe öfnen musst. Hast du das Programm in Olly geöffnet, sollte sich das Fenster mit vielen Zahlen und Buchstaben gefüllt habe Es sieht ungefähr so aus:

Klicke nun mit der rechten Maustaste auf das obere linke Fenster, das ich im Bild (s.o.) als „Für uns interssanter Teil“ gekennzeichnet habe. In dem sich öffnenden Dialog gehst du auf „Search For“ und dort auf „All referenced text strings“. Das Fenster sollte sich ein bisschen verändern. Lass uns nun kurz daran erinnern, was unsere Ur-Funktion macht. *Überleg* Genau, sie schreibt den Text „Von EXE“ in unsere Konsole. Also sollte die Startadresse unserer Funktion in der Nähe dieses Strings sein. Wir haben nun das Programm nach Strings absuchen lassen. Gefundene Zeichenketten zeigt uns Olly in dem neuen Fenster an. Und was ist denn das?

Der rot-Umrahmte String ist genau der, den wir gesucht haben. Klick doppelt auf ihn drauf und wir gelangen zurück zu dem Startfenster an die Adresse, an der der String steht. Wir haben bereits festgestellt, dass in der Nähe des Strings die Startadresse unserere Funktion liegen muss, also srollen wir ein bisschen hoch. Olly macht es uns insgesamt noch einfacher und setzt eine dicke, schwarze Klammer um den Adressenbereich, der zu einer Funktion gehört. Also schauen wir, wo diese Klammer beginnt und das ist exakt drei Zeilen weiter oben der Fall, bei mir die Adresse 0x004013EE. Bei dir muss es nicht zwangsläufig die gleiche Adresse sein:

Damit haben wir nun die Startadresse. Lass Olly aber nochmal offen, wir werden ihn gleich nochmal um Hilfe fragen müssen Aber erstmal lass uns weiter programmieren:
Code:
#include <windows.h>
#include <iostream>

bool DetourFunc( BYTE* oldFunc, BYTE* newFunc, DWORD len )
{
    BYTE* newMem4base = NULL;
    DWORD dwOld;

    newMem4base = ( BYTE* )malloc( 5+len );

    if( newMem4base == NULL )
        return false;

    for( DWORD i = 0; i < ( len+5 ); i++ )
        newMem4base[i] = 0x90;

    VirtualProtect( oldFunc, len, PAGE_READWRITE, &dwOld );

    memcpy( newMem4base, oldFunc, len );
    oldFunc[0] = 0xE8;
    *( DWORD* )( oldFunc+0x01 ) = DWORD( newFunc-oldFunc-5 );
    oldFunc[5] = 0xE9;
    *( DWORD* )( oldFunc+0x06 ) = DWORD( newMem4base-( oldFunc+0x5 )-5 );
    newMem4base += len;
    newMem4base[0] = 0xE9;
    *( DWORD* )( newMem4base+0x01 ) = DWORD( ( oldFunc+10 )-newMem4base-5 );

    for( DWORD i = 10; i <len; i++ )
        oldFunc[i] = 0x90;

    return true;
}


DWORD WINAPI Thread( LPVOID lpParam )
{
	DetourFunc( ( BYTE* )0x004013EE,
	return 0;
}


BOOL APIENTRY DllMain( HMODULE hModule, DWORD  ul_reason_for_call, LPVOID lpReserved )
{
	if( ul_reason_for_call == DLL_PROCESS_ATTACH )
	{
		HANDLE hThread = CreateThread( NULL, 0, Thread, NULL, 0, NULL );
		CloseHandle( hThread );
	}

	return TRUE;
}
Ich habe mal angefangen die Detour-Funktion aus unserem Thread aufzurufen. Bis jetzt haben wir ja nur die Adresse der Ur-Funktion. Der zweite Parameter ist die Adresse der neuen Funktion. Dazu müssen wir jetzt erstmal die neue Funktion definieren:
Code:
#include <windows.h>
#include <iostream>

bool DetourFunc( BYTE* oldFunc, BYTE* newFunc, DWORD len )
{
    BYTE* newMem4base = NULL;
    DWORD dwOld;

    newMem4base = ( BYTE* )malloc( 5+len );

    if( newMem4base == NULL )
        return false;

    for( DWORD i = 0; i < ( len+5 ); i++ )
        newMem4base[i] = 0x90;

    VirtualProtect( oldFunc, len, PAGE_READWRITE, &dwOld );

    memcpy( newMem4base, oldFunc, len );
    oldFunc[0] = 0xE8;
    *( DWORD* )( oldFunc+0x01 ) = DWORD( newFunc-oldFunc-5 );
    oldFunc[5] = 0xE9;
    *( DWORD* )( oldFunc+0x06 ) = DWORD( newMem4base-( oldFunc+0x5 )-5 );
    newMem4base += len;
    newMem4base[0] = 0xE9;
    *( DWORD* )( newMem4base+0x01 ) = DWORD( ( oldFunc+10 )-newMem4base-5 );

    for( DWORD i = 10; i <len; i++ )
        oldFunc[i] = 0x90;

    return true;
}

void MyFunction()
{
	std::cout << "Von DLL. HGW dein Detour funktioniert :)\n";
}


DWORD WINAPI Thread( LPVOID lpParam )
{
	DetourFunc( ( BYTE* )0x004013EE,
	return 0;
}


BOOL APIENTRY DllMain( HMODULE hModule, DWORD  ul_reason_for_call, LPVOID lpReserved )
{
	if( ul_reason_for_call == DLL_PROCESS_ATTACH )
	{
		HANDLE hThread = CreateThread( NULL, 0, Thread, NULL, 0, NULL );
		CloseHandle( hThread );
	}

	return TRUE;
}
Direkt über unseren Thread habe ich die neue Funktion definiert. Sie macht auch nicht viel mehr als unsere Ur-Funktion. Auch sie schreibt nur einen Text in unser Konsolenfenster. Spannende Frage: Wie kommen wir an die Adresse der neuen Funktion? Brauchen wir dafür wieder Olly? Antwort: Nein. An die Adresse kommen wir viel leichter
Code:
#include <windows.h>
#include <iostream>

bool DetourFunc( BYTE* oldFunc, BYTE* newFunc, DWORD len )
{
    BYTE* newMem4base = NULL;
    DWORD dwOld;

    newMem4base = ( BYTE* )malloc( 5+len );

    if( newMem4base == NULL )
        return false;

    for( DWORD i = 0; i < ( len+5 ); i++ )
        newMem4base[i] = 0x90;

    VirtualProtect( oldFunc, len, PAGE_READWRITE, &dwOld );

    memcpy( newMem4base, oldFunc, len );
    oldFunc[0] = 0xE8;
    *( DWORD* )( oldFunc+0x01 ) = DWORD( newFunc-oldFunc-5 );
    oldFunc[5] = 0xE9;
    *( DWORD* )( oldFunc+0x06 ) = DWORD( newMem4base-( oldFunc+0x5 )-5 );
    newMem4base += len;
    newMem4base[0] = 0xE9;
    *( DWORD* )( newMem4base+0x01 ) = DWORD( ( oldFunc+10 )-newMem4base-5 );

    for( DWORD i = 10; i <len; i++ )
        oldFunc[i] = 0x90;

    return true;
}

void MyFunction()
{
	std::cout << "Von DLL. HGW dein Detour funktioniert :)\n";
}


DWORD WINAPI Thread( LPVOID lpParam )
{
	DetourFunc( ( BYTE* )0x004013EE, ( BYTE* )&MyFunction
	return 0;
}


BOOL APIENTRY DllMain( HMODULE hModule, DWORD  ul_reason_for_call, LPVOID lpReserved )
{
	if( ul_reason_for_call == DLL_PROCESS_ATTACH )
	{
		HANDLE hThread = CreateThread( NULL, 0, Thread, NULL, 0, NULL );
		CloseHandle( hThread );
	}

	return TRUE;
}
Ist äquivalent wie die Adressierung eines Zeigers auf eine Variable Zu guter letzt brauchen wir noch die Anzahl der zu sichernden Bytes. Diese Größe kann auf keinsten Fall beliebig gewählt werden. Wenn du Glück hast läuft u.U. alles Glatt aber mit hoher Wahrscheinlichkeit wird es einige Probleme geben, wenn du die Größe beliebig festlegst! Zu allererst beträgt die Mindestgröße 10Bytes. Diese setzt sich zusammen aus dem CALL Befehl+Adresse (=5Bytes) und dem JMP Befehl+Adresse (=5Bytes). Beide zusammen machen eben 10Bytes. Jetzt kannst du aber auch nicht einfach immer die mindestgröße wählen, sondern das muss von Fall zu Fall angepasst werden. Warum? Das hat einen einfachen Grund. Ein paar Fakten: Der PUSH EBP (Das Ablegen eines Registers auf den Stack) nimmt genau die Größe von einem Byte ein. JMP und CALL nehmen jeweils 5Bytes ein. So haben wir z.B. folgende Befehlsreihe in unserer Funktion am Anfang:

PUSH EBP
JMP 32000000
CALL 4400000000

Dann machen alle drei Befehle insgesamt eine Größe von 11Bytes.Würden wir jetzt nur die ersten 10Bytes sichern und überschreiben, dann bleibt in der Ur-Funktion das letzte Byte übrig (0x00). Wir sichern ja die alten Bytes auf einem neuen Speicherblock. Und nach der Sicherung springen wir zurück zur Ur-Funktion. Gehen wir das mal durch. PUSH EBP braucht ein Byte. Bleiben noch 9 aus unserer Sicherung. JMP braucht 5Bytes. Bleiben noch 4Bytes aus der Sicherung. CALL braucht aber auch 5Bytes! Es sind aber nur noch 4übrig, da wir das letzte nicht mit gesichert haben. Problem! CALL nimmt sich aber 5Bytes. Was kam nach der Sicherung? Richtig der Jump zurück. Also nimmt sich CALL einfach das E9-Byte aus unserem Jump. Nicht gut. Damit kehren wir von unserem Speicherblock nichtmehr zurück zu unserer Ur-Funktion und landen irgendwo im Speicher-Nirvana… Ich hoffe du hast das bis jetzt einigermaßen verstanden Ich fasse es mal zusammen:

Regeln für die Anzahl Bytes, die gesichert werden sollen:

1. Es müssen mindestens 10Bytes sein
2. Es müssen alle zu einem Befehl gehörigen Bytes gesichert werden

Schauen wir uns in Olly mal unsere Ur-Funktion an. Der erste Befehl ist PUSH EBP. Links neben dem Befehl können wir die Bytes zu dem Befehl sehen. Und es ist ein Byte. Zu wenig, wir brauchen mind. 10Bytes. Der nächste Befehl ist MOV EBP, ESP. Dieser ist 2Bytes groß. Insgesamt haben wir 3Bytes, immer noch zu wenig. Der nächste Befehl ist SUB ESP, 8. Dieser ist 3Bytes groß. Nun haben wir schon 6Bytes. Immer noch zu wenig. Ui der nächste Befehl ist lang MOV blabla, blub. Dieser nimmt insgesamt 8Bytes ein. Wow. Mit den 6Bytes von vorhin haben wir 14Bytes. Das ist größer als 10. Damit hätten wir die Größe und wir könne sie als Parameter unserer Funktion übergeben:
Code:
#include <windows.h>
#include <iostream>

bool DetourFunc( BYTE* oldFunc, BYTE* newFunc, DWORD len )
{
    BYTE* newMem4base = NULL;
    DWORD dwOld;

    newMem4base = ( BYTE* )malloc( 5+len );

    if( newMem4base == NULL )
        return false;

    for( DWORD i = 0; i < ( len+5 ); i++ )
        newMem4base[i] = 0x90;

    VirtualProtect( oldFunc, len, PAGE_READWRITE, &dwOld );

    memcpy( newMem4base, oldFunc, len );
    oldFunc[0] = 0xE8;
    *( DWORD* )( oldFunc+0x01 ) = DWORD( newFunc-oldFunc-5 );
    oldFunc[5] = 0xE9;
    *( DWORD* )( oldFunc+0x06 ) = DWORD( newMem4base-( oldFunc+0x5 )-5 );
    newMem4base += len;
    newMem4base[0] = 0xE9;
    *( DWORD* )( newMem4base+0x01 ) = DWORD( ( oldFunc+10 )-newMem4base-5 );

    for( DWORD i = 10; i <len; i++ )
        oldFunc[i] = 0x90;

    return true;
}

void MyFunction()
{
	std::cout << "Von DLL. HGW dein Detour funktioniert :)\n";
}


DWORD WINAPI Thread( LPVOID lpParam )
{
	DetourFunc( ( BYTE* )0x004013EE, ( BYTE* )&MyFunction, 14 );
	return 0;
}


BOOL APIENTRY DllMain( HMODULE hModule, DWORD  ul_reason_for_call, LPVOID lpReserved )
{
	if( ul_reason_for_call == DLL_PROCESS_ATTACH )
	{
		HANDLE hThread = CreateThread( NULL, 0, Thread, NULL, 0, NULL );
		CloseHandle( hThread );
	}

	return TRUE;
}
Hui endlich fertig mit der DLL Jetzt müssen wir diese nur noch in unser Zielprozess injezieren. Wie man einen Injektor programmiert, findest du beschrieben.

Ich wünsche euch viel Spaß beim Programmieren Wie immer wenn ihr Fehler findet, melden, ansonsten viel Spaß damit, würde mich über Feedback freuen.

Credits:
Nope

Ahh, das ist doch mal was.
Ist ein wenig schade, da man immer auf Olly angewiesen ist, aber naja^^ eine komplette Disassmbler Lib würde den Rahmen sprengen.
Ansonsten sehr gut für Anfänger beschrieben, wenn sie zumindest schonmal ein bisschen mit Olly zutun hatten.
2 kleine Anmerkungen:

1. Du solltest evtl. erklären, was das mit den 0x90 soll, denn damit wird ja, falls man mehr gesichert hat als man überschrieben hat, der überschüssige Code mit NOPs überschrieben; das weiß ein Anfänger nicht unbedingt.
2. Ich würde lieber mit einem E9, heißt Jump, als mit einem Call detouren.
Mit einem Call könnte das problematisch betreffend der Parameter sein.
Gut, hier in diesem Beispiel gibts keine, aber normalerweise schon.
Du nutzt ja in der eigenen Funktion dann die Parameter, die vom Caller der Opferfunktion gepusht wurden.
Wenn deine Funktion nun mit inline ASM arbeitet, ok, dann musst du dich aber selbst darum kümmern, dass der ESP Wert nun um 4 zu klein ist, weil die neue Rücksprungadresse da ist.
Wenn du ganz normal auf die Parameter zugreifst, in C++, dann wird das (entschuldige wenn ich falsch liege o.O Aber wenn ich das logisch mal so durch gehe, ist das so; kannst mich gerne korrigieren) Probleme geben.
Der Compiler geht davon aus, dass die Funktion ganz normal aufgerufen wird, d.h. die Parameter werden vor dem Call gepusht und generiert den Code, der auf den ESP Value vor der eigenen Rücksprungadresse zugreift.
Nun wird aber nichts davor gepusht, denn die Parameter wurden ja schon vor der Opferfunktion gepusht.
Das heißt die 1. Rücksprungadresse liegt dazwischen, was der Compiler aber nicht weiß.
Lösung:
Entweder du nimmst E9, was nicht umsonst die gängigere Praktik ist oder du pusht die Parameter noch mal vor dem Detour, was aber Speicherplatzverschwendung und nervig beim Zusammenrechnen der Bytes ist.
Was mir sonst noch einfällt:
Am Anfang deiner Funktion und am Ende nutzt du kurz ein wenig inline ASM und popst die Rücksprungadresse in eine lokale Variable.
Diese pusht du dann wieder vor dem return, damit du auch richtig zurück springst.
Wäre aber zu umständlich, nimm einfach E9

xNopex · 04/06/2010, 17:26

Ich hab mir das alles mehr oder weniger selber zusammengereimt gehabt. Deswegen habe ich E8 bevorzugt, weil ich nicht wusste, wie ich, wenn ich einen JMP verwende, von meiner Funktion wieder zurück zur Ur-Funktion komme... Aber das mit den Parametern, da haste recht. Hab das selber schon mitbekommen

MrSm!th · 04/06/2010, 18:37

Quote:

Originally Posted by xNopex

Ich hab mir das alles mehr oder weniger selber zusammengereimt gehabt. Deswegen habe ich E8 bevorzugt, weil ich nicht wusste, wie ich, wenn ich einen JMP verwende, von meiner Funktion wieder zurück zur Ur-Funktion komme... Aber das mit den Parametern, da haste recht. Hab das selber schon mitbekommen

wu meine Logik war richtig *g*

Du hast doch da dein Trampolin.
Von da jumpst du ja zurück zum originalen Code.
Warum returnst du bool?
Machs wie Microsoft und return eine Pointer zum Trampolin; dann musste eben am Ende deiner Funktion callst du das Trampolin, das jumpt zum originalen Code, dann wird von da zum Ende deiner Funktion returnt und du returnst zum Caller der Originalfunktion.
(lässt sich eben durch return blablubbTrampolinPointer(arg1,arg2,...); in deiner funktion vereinfachen. so werden die parameter zwar dann doch 2 mal gepusht, aber wenigstens nicht in der originalfunktion, sodass du nun auch mit 5 bytes rechnen kannst, da der call überflüssig ist.)

Das Ergibt dann:

-sichern der bytes an der opferfunktion
-schreiben der bytes in ein trampolin
-jump ans ende des trampolins
-jump in die opferfunktion zur eigenen funktion
-eigene funktion callt am ende das trampolin mit den parametern

Dann ist es wie bei Microsoft Detours (klingt doof, dass fast 1:1 nachzumachen, die struktur ist aber sehr sinnvoll), außer dass man selbst die richtige Anzahl an Bytes sichern muss.

juRiii · 04/18/2010, 00:54

Quote:

Schauen wir uns in Olly mal unsere Ur-Funktion an. Der erste Befehl ist PUSH EBP. Links neben dem Befehl können wir die Bytes zu dem Befehl sehen. Und es ist ein Byte.

woher weist du, dass es 1 byte ist? wie kommt man drauf?

bloodx · 04/18/2010, 03:48

links daneben steht 55 = 1 byte.
da unter steht dann XXXX = XX 1 Byte | XX 1 Byte = 2 Byte
usw...

MrSm!th · 04/18/2010, 04:20

Quote:

Originally Posted by juRiii

woher weist du, dass es 1 byte ist? wie kommt man drauf?

da stehen 2 zeichen (A-F, 0-9); 2 zeichen = 1 Byte

juRiii · 04/18/2010, 14:37

ok, vielen dank ;D habs endlich verstanden^^

juRiii · 04/20/2010, 00:22

den injektor den du oben genannt hast, bei mir funktioniert er nur bei consolen apps. ist das normal?!

xNopex · 04/20/2010, 07:21

Kommt drauf an. Es kann sein, dass der Injektor bei einigen Anwendungen nicht funktioniert. Dann musst du auf eine andere Methode zurückgreifen, globale Hooks, die ich jetzt aber nicht näher erläutern werde, weil ich jetzt in die Schule gehe^^

juRiii · 04/22/2010, 23:42

ich push hier mal

wo ist denn da der unterschied? wie gesagt, bei consolen apps funzt es wunderbar. jedoch bei KEINEM windows app.

wie sieht es eig. mitm injecten in games aus, wie in hl1? würde VAC sowas direkt erkennen, wenn man beim injecten nichts beachtet? glaube da würde es auf den detour drauf an kommen, or?

xNopex · 04/23/2010, 22:32

Ich habs unter verschiedenen GUI-Applikationen getestet, es geht dort auch, es geht nur nicht, wenn ReadProcessMemory() bzw. andere relevante API-Funktionen wie auch immer nicht ausführbar sind. Wenn dies der Fall ist, musst du über nen globalen Hook arbeiten, durch den deine DLL von jedem Prozess geladen wird. In der DLL filterst du dann durch GetCurrentProcessId() o.ä. die Anwendungen raus, in die die DLL wirklich injeziert werden soll, ansonsten kacken bei dir reihenweise die Prozesse ab, wenn du in der DLL Werteveränderung von statischen Adressen durchführst. Mittels dieser Methode kannst du dann aber nichtmehr "normale" DLL's injezieren, die noch mit den alten Methoden oder einer .NET Sprache arbeiten. Ich habe aber auch dafür eine Lösung gefunden und bin currently dabei, diese zu optimieren.

schrillismus · 04/17/2011, 23:46

Folgendes Problem:

Das Opferprogramm sieht so aus:

Mein Funktionsaufruf:
DetourFunc( ( BYTE* )0x01031470, ( BYTE* )&MyFunction, 11);
Ich habe es auch mit 10 und 12 Bytes versucht.

Da der Link auf den C++ Injektor down ist, habe ich die DLL mit winject injiziert.

Danach stürzt das Opferprogramm einfach ab. Was habe ich falsch gemacht?

MrSm!th · 04/18/2011, 00:16

Schau mal in Olly, ob die Bytes richtig überschrieben werden und da nicht irgendein Müll rauskommt; 10 sollte eigentlich keine Probleme bereiten.