Wallhacking Toolkit

[Sydr4]

Heyho,

ich habe die letzen Tage an einem Toolkit gearbeitet, dass vielleicht auch für andere noch nützlich sein könnte. Deshalb wollte ich das hier einfach mal veröffentlichen.

Worum geht es?
Das Wallhacking Toolkit ermöglicht es, D3D-Wallhacks zu erstellen, ohne eine Programmiersprache zu beherrschen. Es lässt sich jedoch auch dazu benutzen, Strides oder NumVertices und PrimitiveCounts zu loggen.

Wie funktioniert das ganze?
Ein ausführliches HowTo in englisch ist schon mit dabei, aber ich werd' das ganze hier nochmal auf deutsch erklären:

Wallhacking Toolkit

• Vorwort
• Logging
• Hack erstellen
• Nachwort

[*] Vorwort


Zunächst erkläre ich mal, wie genau die Wallhacks, die das Toolkit erstellt, damit man versteht, was man hier genau tun muss.

Was sind Wallhacks? Ich denke, das sollte jedem klar sein, der sich das hier durchliest. Wallhacks erlauben es einem Spieler (meistenst in Shootern) andere Spieler durch Wände zu sehen, was ein großer Vorteil ist, da er dann schneller reagieren kann.
Aber wie funktioniert das ganze?
Das Toolkit ist momentan nur für D3D9-Spiele geschreiben. Alles andere funktioniert momentan noch nicht. Ich denke aber, dass ich in den nächsten Tagen, noch einen Support für D3D8-Spiele einbauen werde.

D3D9-Spiele haben eine sogenannte Methode, mit der sie Objekte auf den Bildschirm zeichnen. Diese nennt sich: IDirect3DDevice9::DrawIndexedPrimitive()
Diese wird von Direct3D bereitgestellt und das Spiel ruft sie mit bestimmten Parametern auf. Wenn man diese Parameter überwacht, kann man feststellen, was gerade denn genau auf den Bildschirm gezeichnet wird. Ein Wallhack setzt nun genau hier an. Er überwacht die Parameter und sollte er feststellen, dass ein Spieler gezeichnet wird, so zeichnet er diesen immer in den Vordergrund (vor Wände etc.).
Nun ist es allerdings so, dass diese Parameter von Spiel zu Spiel unterschiedlich sind. Deshalb muss man, um einen Wallhack zu erstellen, diese erst herausfinden und den Wallhack dann anweisen, genau diese zu verwenden.
Ein bisschen konkreter: Die Parameter (die der Wallhack hier verwendet) heißen UINT NumVertices und UINT PrimitiveCount.

Diese beiden Parameter sind nicht die einzige Möglichkeit zu überprüfen, was gerade gezeichnet wird. Es gibt noch einen weiteren und zwar UINT stride. In manchen Fällen ist es wesentlich einfacher diesen zu verwenden, in manchen nutzt er allerdings garnichts. Wenn man stride verwendet ist die Wahrscheinlichkeit groß, dass man mit einem stride-Parameter alle Spieler auf einmal markieren kann (bei NumVertices und PrimitiveCount benögt man mehrere Werte). Es kann jedoch auch passieren, dass ALLE Objekte eines Spiels mit einem Stridewert gedrawt werden, was zu Folge hat, dass einfach der komplette Bildschirm einfarbig ist. Außerdem ist es öfter so, dass bei stride einige Objekte in den Vordergurnd gebracht werden, die keine Spieler sind.

Genug Theorie, jetzt geht's los !

[*] Logging


Als Logging bezeichnet man den Prozess des Herausfindens der Parameter.
Ich werde zuerst das StrideLogging erklären. PrimitiverCount und NumVertices geht ganz einfach anaolg dazu.

Der Vorteil dieses Toolkits ist der, dass es eine grafische Oberfläche bereitstellt. Die macht das Loggen wesentlich schneller, als wenn man nur einzelne Tasten ingame benutzen kann. Das Problem dabei: Viele D3D-Spiele laiufen im Vollbildmodus. Wie komm ich dann an die GUI?
Um dieses Problem zu umgehen, hab ich in das ganze remote gemacht. Das heißt, man kann nun einfach das Spiel auf einem PC laufen lassen und die GUI auf einem anderen PC. So kann man sehr schnell alle Werte loggen. Das ganze auf einem Rechner auszuführen macht nur dann Sinn, wenn man das Spiel im Fenstermodus starten kann.
Gut, dann mal los.

Als erstes müsst ihr das Spiel starten, für das ihr den Wallhack erstellen wollt.
Anschließend müsst ihr die StrideLogger.dll in den Prozess injizieren. Das könnt ihr mit einem beliebigen DLL-Injector machen. Ich benutze hier Winject.



Als nächstes wird die StrideLoggerGUI.exe auf dem zweiten Rechner gestartet. Dort einfach die IP des Rechners eingeben, auf dem das Spiel läuft, API auswählen und auf "Connect" klicken. Solltet ihr das ganze auf dem gleichen Rechner laufen lassen, einfach die 127.0.0.1 stehen lassen.



Wartet nun, bis dieses Fenster aufgeht:



Das ist das Hauptfenster. Hier eine kurze Erklärung:

1. Hier kann man Listen einsehen, speichern oder Elemente löschen
2. Farbe und Z-Buffer Einstellungen
3. Der Startpunkt beim NumVertices-Logging
4. Der Maximalwert für "Start". Dieser wird benutzt, damit die TrackBar richtig verwendet werden kann
5. Öffnet die "ZoomBar". Wird gleich noch genauer eklärt.
6. Fügt die aktuelle NumVertices/PrimitiveCount-Kombination hinzu
7. Setzt primitveCount-Start auf 0 und primitiveCount-Range auf 10000, so dass alle primitiveCount Werte markiert werden
8. Das gleiche für NumVerticves
9. Setzt alle Werte zurück

Um einen Stride zu loggen, muss als erstes "Range" gesetzt werden. Range gibt an, wie viele Strides ab Start markiert weden sollen. Ein Beispiel:

Start = 52
Range = 19
Alle Objekte mit einem Stride von 52 bis 71 werden markiert.

Range sollte einen Wert haben, der es erlaubt, einigermaßen Schnell auf der TrackBar zu scrollen, aber dennoch nicht so groß ist, dass zu viele Strides markiert werden.
Anfangs würde ich da vielleicht 20 empfehlen.
Nachdem Range gesetzt ist, kann man anfangen den "Strart"-Balken langsam nach oben zu ziehen, bis die gesuchten Objekte (Spieler) markiert werden.
Wenn das der Fall ist, ganze einfach auf "Zoom" klicken und auf diesem Balken wieder scrollen, bis die Player wieder markiert werden. Dann nur noch auf Set klicken.
Jetzt muss dieser Stride in die Stride-Liste hinzugefügt werden. Das geht ganz einfach mit einem Klick auf "Add".
Dieser Prozess muss nun wiederholt werden, bis alle Spieler markiert werden (meistens reicht 1 Stride).
Jetzt müssen die geloggten Strides gespeichert werden. Einfach auf "Lists->Stride List->Save" klicken und einen Ort auswählen.

Wie bereits gesagt, kann man alternativ auch primVerts (also eine Kombination aus NumVertices und PrimitiveCount) geloggt werden. Diese haben den Nachteil, dass jedes Playermodel einen eigenen hat und deshalb der Loggingaufwand um einiges größer ist. Dafür funktioniert das immer und man hat im Normalfall keine anderen Objekte, die auch noch in den Vordergund gezeichnet werden.

Zuerst muss der NumVertices Wert geloggt werden. Dazu klickt man auf "All Prim", was dafür sorgt, dass jedes Objekt, egal welchen PrimitiveCount-Wert es hat, markiert wird (natürlich nur, wenn es in der NumVertices-Reichweite liegt).
Dann einfach analog zum Strideloggen, den NumVertices-Wert loggen. Allerdings würde ich hierbei den Rangewert auf 100 bis 150 setzen, je nach dem, wie schnell die Verbindung zwischen den 2 PC's und euer Auge ist.
Wenn ihr nach dem "Zoom"-Klicken den exakten Wert habt, macht das gleiche mit PrimitiveCount. Range auf 100 setzen, scrollen bis das Objekt markiert wird, Zoomen und den exakten Wert herausfinden.
Schließlich, wenn ihr den NumVertices UND den PrimitveCount-Wert habt, noch auch "Add" drücken.
Auch das muss nun wiederholt werden, bis alle Spieler markiert sind (kann eine Weie dauern).
Dann wieder auf "Lists->PrimVert List->Save".

Das war das Logging.


[*] Hack erstellen


Das ist ein sehr einfacher Schritt. Startet einfach WallhackMaker.exe. Es sollte sich nun dieses Fenster öffnen:



Klickt auf "Browse Template" und wählt ein beliebiges Template aus. Welches sollte ich nehmen? Nun, die Unterschiede sind folgende: Es gibt verschiedene Tempates für D3D8 und D3D9. Für ein D3D9 Spiel muss auch ein D3D9-Template gewählt werden. Zu erkennen sind diese am Namen.
Als nächstes gibt es noch SINGLEDRAW und DOUBLEDRAW Templates. SINGLEDRAW Templates sind ganz normale Wallhacks. Bei DOUBLEDRAW Templates wird jeder Spieler zweimal in verschiedenen Farben gezeichnet. Einmal mit und einmal ohne Z-Buffer. Das hat zur Folge, dass die Teile eines Spielers, die sich vor einer Wand befinden, in einer anderen Farbe gezeichnet werden, als die, die sich hinter einer Wand befinden.
Nachdem ihr euer Template geöffnet habt müsst ihr einen .psf oder .ssf file öffnen. Das ist das, was bei eurem Logging herausgekommen ist. Ihr könnt auch sowohl einen .psf, als auch einen .ssf file verwenden.
Jetzt nur noch auf "Make" klicken und einen Speicherort klicken.
Jetzt habt ihr einen fertigen Wallhack in Form einer DLL. Diese einfach noch mit einem DLL-Injector ins Spiel injizieren und euer Wallhack sollte funktionieren


[*] Nachwort


Hoffentlich hilft dieses Toolkit jemandem und spart Zeit.
Momentan wird nur D3D9 unterstützt. Ich denke, dass ich in das ganze noch ein wenig erweitern werde.
Aus irgendeinem Grund funktioniert das nicht, mit CS:S. Es scheint ein paar Probleme mit den Hooks zu geben. Je nach dem wie viel Zeit ich habe, werde ich mal schauen, dass das wieder läuft.
Ich werde wahrscheinlich auch noch den Sourcecode zu dem Projekt veröffentlichen. Ganz einfach aus dem Grund, dass sobald ein Spiel irgendeine Protection (meinetwegen gegen D3D-Hooking hat) das ganze Projekt für dieses Spiel völlig nutzlos ist. Wenn ich allerdings den Sourcecode veröffentliche, besteht die Möglichkeit, das ganze mit einem Bypass neu zu kompilieren.
Falls ihr den fertigen Wallhack irgendwie transportieren wollt (auf einen Server hochladen, auf einen USB-Stick ziehen) achtet darauf, dass die ADS nicht verloren gehen. Deshalb sicherheitshalber zippen.

Viel Spaß damit,

Sydr4 [



Hier könnt ihr euch den Spaß downloaden:

[Zundras]

Sieht gut aus. Werde es mal testen

[MrSm!th]

Damit förderst du den Missbrauch von Compilern
Du kannst du nicht einfach C&P Code geben und die Leute müssen sich dann den Compiler laden und das Programm selbst kompilieren.
Dann wäre es doch schlauer, du machst einige Dll Templates, die einfach aus einer Konfigurationsdatei alle nötigen werte auslesen, dann ersparst du den Usern das Kompilieren.

Außerdem ist es nicht richtig, die Dll als Debug zu kompilieren, die wird dann nur auf dem eigenen PC laufen.
Und da Leute, die so ein Tool ernsthaft nutzen, hundertprozentig ihre coolen 1337 Hacks releasen wollen, werden sie sich dann wundern, wieso keiner ihre Hacks nutzen kann.
Daher immer als Release kompilieren.

[link]

Originally Posted by Sydr4

Genug Theorie, jetzt geht's los !

Seh ich anders.. Ich denke zwar nicht, dass dein Post ein Tutorial sein soll, nur zeigst du Ambitionen irgendwas erklären zu wollen, so wirklich tust du's dann aber doch nicht..
Mich erinnert das hier leicht an einen Post von SmackJew von vor ein, zwei Tagen..
Kommt mir nämlich irgendwie so vor als hätte jemand herausgefunden, wie man sich 'nen Chameleon-Hack macht, und muss das sofort in irgendein neues Programm stecken, um anderen zu zeigen, was er alles tolles Neues gelernt hat.

Tut mir Leid, wenn ich dir Unrecht tue, aber dein Tool kommt so zwanghaft herüber und die Idee erscheint mir unnötig und ein wenig amateurhaft.

LPBYTE InjectHook(LPBYTE target, const LPBYTE hookf){
	return DetourFunction(target, hookf);
}

Sinn?..

Ich weiß, dass in z.B. Delphi ein const den Unterschied macht, ob ein Exception Handler eingereiht und eine Referenz erhöht wird oder nicht.
Aber ob das in C/C++ notwendig ist? Außerdem ginge das doch auch als Makro, ohne einen neuen Stack-Frame zu erstellen und die Parameter doppelt und dreifach zu pushen, oder nicht?

[Sydr4]

Originally Posted by MrSm!th

Damit förderst du den Missbrauch von Compilern
Du kannst du nicht einfach C&P Code geben und die Leute müssen sich dann den Compiler laden und das Programm selbst kompilieren.
Dann wäre es doch schlauer, du machst einige Dll Templates, die einfach aus einer Konfigurationsdatei alle nötigen werte auslesen, dann ersparst du den Usern das Kompilieren.

Das mit dem C&P Code ist vielleicht wirklich keine allzu gute Idee. Alleine schon aus dem Grund, dass die Leute, die wirklich den generierten Sourcecode verwenden, an den Linkingerrors scheitern werden, da das man sich das DirectX SDK ja nicht nur installieren muss, sondern auch normalerweise noch die Pfade zu den Libraries explizit angeben musst.
Ursprünglich bestand das Projekt nur aus dem Logger, aber ein Programm, dass nicht viel mehr macht, als ein String.Replace(), ist kein großer Aufwand, weshalb ich das noch dazu geschrieben habe. Aber du hast Recht, es ist wahrscheinlich besser, wenn ich das ganze in eine Konfigurationsdatei auslagere oder den WallhackMaker gleich eine fertige DLL erstellen lasse.

Originally Posted by MrSm!th

Außerdem ist es nicht richtig, die Dll als Debug zu kompilieren, die wird dann nur auf dem eigenen PC laufen.
Und da Leute, die so ein Tool ernsthaft nutzen, hundertprozentig ihre coolen 1337 Hacks releasen wollen, werden sie sich dann wundern, wieso keiner ihre Hacks nutzen kann.
Daher immer als Release kompilieren.

Ich dachte, zusätzlich miteinkompilierte Debuginformationen würden nicht dafür sorgen, dass das auf einem anderen Rechner nicht mehr funktioniert, vorallem deshalb, weil ich auch beim Erstellen des Projekts als Debug kompilierte Dateien zwischen 2 Rechnern hin und her getauscht habe und sie trotzdem auf dem anderen Rechner gelaufen sind. Aber scheinbar kann es dabei wirklich zu Komplikationen kommen, deshalb werde ich das ändern.

Originally Posted by link

Seh ich anders.. Ich denke zwar nicht, dass dein Post ein Tutorial sein soll, nur zeigst du Ambitionen irgendwas erklären zu wollen, so wirklich tust du's dann aber doch nicht..

Ich hatte nicht vor, zu erklären, wie Wallhacks im Detail funktionieren. Ich wollte das ganze so erklären, dass ein normaler User hinterher weiß, was er zu tun hat. Findest du auch dafür reicht es nicht? Wenn ja, was genau ist denn nicht gut genug erklärt?

Originally Posted by link

Mich erinnert das hier leicht an einen Post von SmackJew von vor ein, zwei Tagen..
Kommt mir nämlich irgendwie so vor als hätte jemand herausgefunden, wie man sich 'nen Chameleon-Hack macht, und muss das sofort in irgendein neues Programm stecken, um anderen zu zeigen, was er alles tolles Neues gelernt hat.

Da muss ich dich enttäuschen. Jede Ähnlichkeit mit SmackJew ist rein zufällig. Wenn du auf meiner Homepage ein bisschen nach unten scrollst wirst du finden und wenn man da mal einen Blick auf's Datum wirft, sollte klar sein, dass ich das nicht erst, vor 2 Tagen gelernt hab.

Originally Posted by link

Sinn?..

Ich weiß, dass in z.B. Delphi ein const den Unterschied macht, ob ein Exception Handler eingereiht und eine Referenz erhöht wird oder nicht.
Aber ob das in C/C++ notwendig ist? Außerdem ginge das doch auch als Makro, ohne einen neuen Stack-Frame zu erstellen und die Parameter doppelt und dreifach zu pushen, oder nicht?

Kann ich dir sagen: Momentan muss das ganze mit der 1.5'er Detours Library gelinkt werden. Ich bin aber dabei das gesamte Projekt auf die 3'er Version umzustellen und da muss ich nicht nur eine Funktion callen, sondern mehrere (eine würde reichen, die restlichen aus Stabilitätsgründen). Deshalb dient das ganze als Platzhalter. Aber selbst wenn: Kompiliert man das ganze als Release, wie MrSm!th sagt, optimiert der Compiler das als inline weg und es wird erst garkein Stackframe ertsellt etc. Selbst wenn nicht, macht das ganze keine Millisekunde aus, was selbst wenn es das machen würde, völlig egal wäre, weil die Funktion nur einmal während der Initialisierung aufgerufen wird.

[link]

Originally Posted by Sydr4

Da muss ich dich enttäuschen. Jede Ähnlichkeit mit SmackJew ist rein zufällig.

Ich hab mich missverständlich ausgedrückt. Es ist nicht so als hättest du, dein Post oder dein Projekt Ähnlichkeit mit SmackJew, ich musste einfach nur an einen Hate-Post von SmackJew denken :P Ist aber auch nicht weiter wichtig.

Originally Posted by Sydr4

Ich wollte das ganze so erklären, dass ein normaler User hinterher weiß, was er zu tun hat. Findest du auch dafür reicht es nicht?

Wenn einem C&P reicht und einen gar nicht interessiert, was man da eigentlich macht, dann ist deine Einführung wunderbar.
Nur gerade weil du dir anscheinend viel Mühe alleine bei dem HowTo gegeben hast, hatte ich mehr hintergründige Informationen erwartet.

Originally Posted by Sydr4

Momentan muss das ganze mit der 1.5'er Detours Library gelinkt werden. Ich bin aber dabei das gesamte Projekt auf die 3'er Version umzustellen und da muss ich nicht nur eine Funktion callen, sondern mehrere (eine würde reichen, die restlichen aus Stabilitätsgründen)

Ah, ok.

Originally Posted by Sydr4

Kompiliert man das ganze als Release, wie MrSm!th sagt, optimiert der Compiler das als inline weg und es wird erst garkein Stackframe ertsellt etc.

Ob man sich auf sowas verlassen kann und sollte?

Originally Posted by Sydr4

Selbst wenn nicht, macht das ganze keine Millisekunde aus, was selbst wenn es das machen würde, völlig egal wäre, weil die Funktion nur einmal während der Initialisierung aufgerufen wird.

Und dennoch ist es unnötig.

[Sydr4]

Originally Posted by link

Ich hab mich missverständlich ausgedrückt. Es ist nicht so als hättest du, dein Post oder dein Projekt Ähnlichkeit mit SmackJew, ich musste einfach nur an einen Hate-Post von SmackJew denken :P Ist aber auch nicht weiter wichtig.

Okay, sorry, da hab ich dich wohl falsch verstanden :D

Originally Posted by link

Wenn einem C&P reicht und einen gar nicht interessiert, was man da eigentlich macht, dann ist deine Einführung wunderbar.
Nur gerade weil du dir anscheinend viel Mühe alleine bei dem HowTo gegeben hast, hatte ich mehr hintergründige Informationen erwartet.

Ich hab das Tutorial gestern unter ziemlichen Zeitdruck geschrieben, vielleicht werd ich das dann nochmal an manchen Stellen etwas mehr ausführen.

Originally Posted by link

Ob man sich auf sowas verlassen kann und sollte?
Und dennoch ist es unnötig.

Naja, es kommt ja ziemlich aufs gleiche raus, deshalb ist mir das egal :D
Aber du hast Recht. Ohne die restlichen Funktionen ist es unnötig.

Ich habe mich aber grade dazu entschieden, das ganze nochmal etwas umzuschreiben, so dass der WallhackMaker gleich eine fertige DLL erstellt. Ich werde es, sobald es feritg ist, hochladen und das Tutorial dann entsprechend anpassen.

Das ^ habe ich nun getan. Jetzt erstellt der WallhackMaker eine fertige DLL-Datei.

[Noa3]

hi habs mit den Spiel thehunter ausprobiert. leider stützt es immer gleich beim injekten ab und ich kann nicht mehr auf was reagieren.

EDIT:

Sooo Sry mit dem injekten klappt. problem ist nur das min PC auch gleichzeitig nen server ist und der port 8080 schon belegt ist.(angefangen für skype, aufgehört für Team foundation Server)
>>> Krieg ne rückmeldung Protocoll Mismatch

wie kann ich den port umbelegen?

[XxAlexX737]

Ich wollt mal fragen ob die Seite down ist weil ich immer so einen 500 Fehler bekomme.


OK geht wieder