Games for Windows LIVE trainen

[Acubra]

Der “All you need to know about xlive.dll” Guide

Dieses Tutorial wurde exklusiv für http://www.homeofgamehacking.de geschrieben und darf ohne meine Zustimmung nicht auf anderen Seiten veröffentlicht werden.
Dieses Tutorial dient ausschliesslich zu lernzwecken und der Autor übernimmt keine Haftung für ,gegebenenfalls durch dieses Tutorial, beim Anwender entstandene Schäden. Ausserdem distanziert er sich von jeglichen illegalen Taten, die durch Hilfe dieses Tutorials begangen werden konnten und können.

• 1. Einleitung
  
• 2. Ziel
  
• 3. Vorraussetzungen
  
• 4. Theoretische Überlegungen
  
• 4.1 Debuggerchecks
  
• 4.2 Debugger verstecken
  
• 4.3 Xlive.dll vom Laden abhalten
  
• 4.4. Integritychecks der Xlive.dll umgehen
  
• 5. Anwendung
  
• 6. Schlusswort
  

1. Einleitung
Hey,
Da in letzter Zeit vermehrt Fragen auftauchen zum Thema xlive.dll, insbesondere wie man die Debugger- und Integritychecks dieser umgeht, habe ich mir gedacht das ich ein Tutorial zu dieser Thematik schreibe. Ich werde versuchen so gut wie möglich auf die einzelnen Funktionen der xlive.dll einzugehen und diese auch zu erläutern.

2. Ziel
Ziel dieses Tutorials soll es sein, das ihr in der Lage seid mit dem Debugger eurer Wahl das jeweilige Spiel genauer unter die Lupe zu nehmen, ohne das ihr Probleme mit der dem Schutz der xlive.dll bekommt. Ausserdem hoffe ich das das Tutorial euer allgemeines Verständnis was Gamehacking und Schutzmechanismen angeht erweitern wird.

3. Vorraussetzungen
Obwohl ich das Tutorial so einfach und anfängerfreundlich wie möglich gestalten will, dürft ihr dennoch kein völliger „Noob“ in Sachen Gamehacking sein. Es ist definitiv von Vorteil wenn ihr schon eure eigenen Erfahrungen mit dem ein oder anderem Spiel gemacht habt und euch auch vllt. Schon an die xlive Spiele herangewagt habt. Des Weiteren müsst ihr eine ordentliche Portion Spass und Zeit mitbringen und dürft nicht gleich frustriert aufgeben wenn etwas mal nicht klappt. Der Umgang mit einem Debugger wie OllyDBG sollte euch vertraut sein und ihr solltet selbst ein wenig technisches Verständnis und Eigeninitiative mitbringen.

4. Theoretische Überlegung
Gut, dann wollen wir mal. Was wissen wir? Wir wissen das die xlive.dll nur bei sogenannten GFWL(Games for Windows LIVE) Spielen zum Einsatz kommt. Des Weiteren wissen wir das die Xlive.dll essentiell wichtig für das Spiel ist um die Spielstände korrekt zu laden und zu speichern.
Soweit so gut. Wenn wir nun versuchen ein Spiel zu trainen und die richtigen Opcodes, die auf die gefunden Adressen zugreifen, zu finden, stürzt das Spiel in den meisten Fällen schier grundlos ab. D.h., dass die Xlive.dll ständig überprüft ob das Spiel in irgendeiner Weise von außen beeinflusst wird oder in einem Debugger läuft.
Dies kann man auf viele verschieden Arten prüfen. Die gängigste und einfachste Variante ist die Returnvalue des IsDebuggerPresent Aufrufes zu checken.

Auszug aus der MSDN :

Zitat:If the current process is running in the context of a debugger, the return value is nonzero.
If the current process is not running in the context of a debugger, the return value is zero.

Natürlich gibt es noch weitere Methoden, wie zum Beispiel zu checken ob ein Breakpoint auf der ReadFile API gesetzt wurde.
Dies bringt uns zum ersten Ansatz die Xlive.dll „unschädlich“ zu machen. Wir können die .dll auf alle möglichen Debuggerchecks durchsuchen und diese unwirksam machen, bevor sie unseren Debugger bemerken und das Spiel zum Absturz bringen. Da dies jedoch sehr schwer und zeitaufwändig ist und ein sehr hohes technisches Know How vorraussetzt, sehen wir uns erst einmal nach anderen Methoden um.

Wenn man die Debuggerchecks unwirksam machen kann, müsste man doch eigtl. auch in der Lage sein seinen Debugger zu „verstecken“, oder? Genau. Und genau dieses Feature bietet der Allrounder unter den Memoryscannern, die CheatEngine. Durch Aktivieren der Option „Enable use of the process watcher“ im Extra Tab der Settings, lassen wir die Cheatengine einen Treiber laden, welcher sämtliche Usermodefunktionen in eine virtuelle Umgebung verlegt. Allerdings muss man um dieses Feature unter Windows 7 benutzen zu können beim Booten F8 drücken und Windows mit der Option starten, dass auch von Microsoft unsignierte Treiber geladen werden können.
Dies sollte jedoch das geringste Problem darstellen.

Eine mögliche dritte Methode ist einfach die XLive.dll daran zu hindern geladen zu werden, bzw. sie einfach zu verändern, sodass sie nicht geladen wird. Die Xlive.dll hat wie schon erwähnt einige Integritychecks, welcher checken ob das Spiel, welches sie schützen soll verändert wurde oder nicht. Ausserdem wird beim Laden der .dll geguckt, ob diese von außen schon vor dem Start des Spiels verändert wurde. Wenn sie verändert wurde, wird sie einfach nicht geladen. Die logische Schlussfolgerung daraus ist, dass zwar die Spielstände nicht geladen werden können, jedoch die Schutzmechanismen der Xlive.dll auch nicht in Kraft treten. Viel einfacher geht es ja jetzt nicht mehr.

Welche dieser Methoden ihr jetzt benutzt ist euch überlassen, nur bedenkt das bei der letzten eben die Savegames nicht mehr funktionieren.

Nun zum letzten Teilpunkt. Der Integritycheck der XLive.dll.
Da ihr ja nun wisst wie man erfolgreich das GFWL debuggt und man so relativ leicht die Ansatzpunkte für eine CodeInjection findet, zeige/sage ich euch nun wie man umgeht das die XLive.dll merkt das man den Code des Spiels verändert hat. Dazu muss ich Credits an Psych geben, welcher sich sehr viel Arbeit gemacht hat um eine Bytesequenz herauszufinden, nach der man suchen kann und welche einen an den Anfang einer Routine führt. Diese ist dafür zuständig um zu prüfen ob irgendwelche Codeabschnitte im Spiel geändert wurden.
Die Bytesequenz ist folgende.

Code:

8B EC 83 EC 20 53 56 57 8D 45 E0 33 F6 50 FF 75 0C 8B F9

---

Wenn wir dieser folgen, sollten wir zu dem Anfang der Routine kommen, welche etwa so aussehen sollte.

Code:

1 2 3 4 5 6 7 8

68A3EF52 /$ 8BFF MOV EDI,EDI 68A3EF54 |. 55 PUSH EBP 68A3EF55 |. 8BEC MOV EBP,ESP 68A3EF57 |. 83EC 20 SUB ESP,20 68A3EF5A |. 53 PUSH EBX 68A3EF5B |. 56 PUSH ESI 68A3EF5C |. 57 PUSH EDI 68A3EF5D |. 8D45 E0 LEA EAX,[LOCAL.8]

---

Jetzt einfach am Anfang die Befehle „mov edi, edi“ und „push ebp“ mit „retn 0c“ überschreiben, sodass wir einfach direkt nach dem Betreten der Routine wieder herausspringen, sodass nichts gecheckt wird. Damit sollten eure CodeInjections unerkannt bleiben.

5. Anwendung
Soweit so gut. Nun zum praktischen Teil des Tutorials. Ich werde hier eine CodeInjection in dem Spiel „Alarm für Cobra 11 – Das Syndikat“ durchführen und euch somit zeigen wie ihr die XLive.dll aushebelt.
Zunächst starten wir das Spiel und haben die nötigen Vorbereitungen getroffen, dass die Xlive.dll unseren Debugger (den wir zwangsläufig attachen müssen) nicht erkennt (ich habe die dritte von mir beschriebene Methode benutzt).
Wir starten das Spiel und öffnen den Prozess des Spiels in der Cheatengine(bei mir CrashTime4Hi.exe). Startet ein Einzelspieler Spiel.
Wir wollen nach der Adresse für den Boost suchen, also wählt als Datentyp Float und sucht zunächst bei vollem Boost nach dem exakten Wert 1.
Wir bekommen ein paar Millionen Ergebnisse, welche uns aber nicht weiter stören sollen. Boostet ein wenig und sucht dann nach „decreased value“. Wartet bis sich euer boost ein wenig aufgeladen hat und sucht nach „increased value“. Wiederholt das ganze solange, bis ihr nur noch zwei Adressen gefunden habt. Diese sollten den gleich Wert besitzen. Eine von beiden ist grün, also eine statische Adresse, und die andere ist schwarz.

Doppelklick auf die grüne Adresse und sie landet unten im Adressenfenster der Cheatengine. Nun rechtsklick auf die Adresse und „Find out what accesses this address“. Ein bisschen mit dem Boost durch die Gegend fahren, und wir sollten schon so allerhand Opcodes gefunden haben. Ich habe meine CodeInjection an dieser Stelle angesetzt :

Code:

0048934E - f3 0f 5c c2 - subss xmm0,xmm2

---

Sie sieht folgendermaßen aus:

Code:

Jump zur Cave mov [esi+000031a8],3f800000 subss xmm0,xmm2 mulss xmm0,[esi+00001688] Jump zum Originalcode.

---

Aber das ist nur mein Beispielcode.

Damit diese, von uns vorgenommene, Modifikation nun nicht erkannt wird müssen wir noch die Xlive.dll bearbeiten. Dazu einfach die Bytesequenz suchen und aus der VA und der BaseAddress des Moduls (also in dem Falle die Xlive.dll) das Offset berechnen. Es ist BEF52. Also einfach in dem MemoryViewer der Cheatengine zur Adresse xlive.dll+BEF52 gehen und dort die ersten beiden Befehle durch „ret 0c“ ersetzen. Nun sollte das Spiel wie gewohnt weiterlaufen und ihr habt unbegrenzt Boost zur Verfügung.

6. Schlusswort
Zunächst einmal Glückwunsch an jeden der bis hierhin gelesen hat. Wer ein supercooles Tutorial mit vielen Bildchen und Schritt für Schritt Anleitung gesucht hat, wurde natürlich enttäuscht, doch ein bisschen Eigeninitiative ist doch wohl nicht zu viel verlangt oder?! Wer weiterhin Probleme mit der Xlive.dll hat, kann natürlich gerne seine Fragen stellen und ich werde sie nach bestem Gewissen beantworten.

Ich grüße insbesondere (Reihenfolge ist zufällig) :
- Maluc
- sILeNt heLLsCrEAm
- fr33k
- DNA
- Psych
- Dr.olle
- Homeofgamehacking.de

Acubra

[iNvIcTUs oRCuS]

Ok, wie ich die XLive Checks umgehe wusste ich zwar schon aber trotzdem ist das ein gutes Tutorial geworden. Vielleicht solltest Du aber noch erwähnen das dass Offset nicht bei jedem gleich sein muss da es verschiedene Versionen der XLive Software gibt. Villeicht schreibst Du am besten noch dazu welche Version Deine XLive.dll hat.

grEEtZ sILeNt heLLsCrEAm

[Acubra]

Hey,
danke erstmal für dein Feedback.
Das mit der Xlive Version hast du ja mit deinem Post schon erledigt. Ich habe momentan die Dateiversion 3.2.3.0 (Produktversion 3.2.0003.0).

[iNvIcTUs oRCuS]

Ok vielleicht sollte man der Richtigkeit halber erwähnen das CE so nicht wirklich im Kernelmode arbeitet. Der Treiber der von CE geladen wird ist mehr einer VM (Virtualisierungssoftware) gleich. Sagt eigentlich auch schon der Name - DBVM.

[reptile]

thx , werd das mir in ruhe mal durchlesen ....