Apex AntiCheat – Zwiebeln sorgen für Tränen

Weiter geht es direkt an der Stelle, an welcher der letzte Blogpost endete: Das Patchen der ersten Apex Schicht automatisieren und den Rest “debugbar” zu bekommen. Dazu werden wir einen eigenen Loader schreiben, der es uns erlaubt DLLs vor Programmstart zu Injecten und somit bequem Patches ermöglicht.

Erfahrenere Leser dieses Blogs werden sich wundern, warum der Umweg über einen Loader genommen wurde, statt die zu importierenden DLLs direkt in die ImportTable zu schreiben (von welcher sie direkt geladen werden). Nun, Apex schickt Hashsummenchecks der Wolfteam-Binary an den Gameserver, der uns einen Kick spendiert wenn die Checksumme nicht stimmt.

Das Prinzip des Loaders ist quasi von Opcode0x90 Blog geklaut. Die Idee dahinter ist simpel: Wir starten den Prozess im Status “SUSPENDED” und Patchen den Entry Point, welcher zuvor über die PE Header rausgeparst wird, mit EBFE. 0xEBFE ist Assembler-Code für eine Endlosschleife, also ein Sprung der immer auf sich zurückgeht. Somit haben wir ein “laufendes” Programm, welches aber noch nicht richtig gestartet ist. An diesem Punkt können wir bequem DLLs Injecten und im Anschluss den Prozess wieder anhalten. Der EntryPoint wird wiederhergestellt und der Prozess fortgesetzt, dieses mal allerdings mit einem richtigen Programmstart. Da der Blogpost zu dieser Injecten-Technique so gut geschrieben ist, spare ich mir Codesamples aus meinem Loader.

Das nächste Problem ist der Fenstermodus: Um bequem debuggen zu können ist ein Fenstermodus von nöten, da die maximized Fenster bei einem Breakpoint meist einfrieren und sich im Vordergrund befinden. So kann der Debugger unmöglich bedient werden. Das “rausspringen” aus dem Fenster über ALT+TAB liefert eine viel geringere Auflösung und einen nativen Fenstermodus bringt Wolfteam nicht mit. DxWnd, das Tool das bereits bei Sieder 3 gute Dienste geleistet hat, erkennt bei einem normalen Programmstart von Wolfteam das Fenster und setzt selbstständig die Hooks. Nicht so, wenn kein Child-Prozess verwendet wird (den wir ja durch Patchen der ersten Schicht “deaktivert” haben). So muss DxWnd zu seinem Glück gezwungen werden, d.h. wir injecten die DxWnd.dll einfach von “Hand”. Die Hooks werden dementsprechend gesetzt und das Fenster startet gepatched ebenfalls im Fenstermodus.

Ab hier geht der Spass richtig los. Denn nicht nur Reverser können Loader coden, auch Spieleentwickler. So werden dynamisch mehrere DLLs im Speicher entpackt und in das %APPDATA%/Local/Temp-Verzeichnis geschrieben. Da diese DLLs immer sofort gelöscht werden und sich auch immer an einer anderen Stelle im Speicher befinden, ist das Debuggen kein Spass. Aber was machen diese DLLs denn überhaupt? Es werden die DLLs CShell, CFx und CRes geladen. Diese enthalten, wie wir später sehen werden, den wirklich interessanten Code zu Spieldaten, als auch zu Apex und der ganzen Netzwerktechnik. Die Dumps dieser DLLs sind in gutem Zustand und besitzen sogar eine IAT (Import Table). Nur die Verweise zwischen Wolfteam und der jeweiligen DLL, zwischen denen viel Austausch stattfindet, kann durch statische Analysen allein nicht bestimmt werden.

Auch hier zeigt sich einmal mehr: Programmierer sind Faul und lassen sich daher möglichst viel Arbeit abnehmen. So ist Tool geschrieben worden, was den Wolfteam-Prozess raussucht, die einzelenen Module auflistet und je nach Modul die Konvertierung von “Statischer Adresse” zu “Dynamischer Adresse” der geladenen DLL durchführt.

Apex erkennt einen geladenen Debugger “leider” nicht beim eigentlichen Laden von Apex, was bei einem Klick auf einen Server geschieht. Leider heißt in diesem Fall, dass der Debugger erst später erkannt wird und somit uns das Auffinden der Anti-Debug-Methoden schwer macht. Dieser Teil von Apex (welcher Bereits im Address Converter zu sehen ist) bekommt allerdings nochmal einen eigenen Blogpost spendiert.

Debuggen mit OllyDbg fällt ins Wasser und auch CheatEngine wird direkt von Apex erkannt. Doch halt, was ich mit OllyDbg 1 ? Ich weiß nicht wie es kommt und vor allem wie es funktioniert, aber OllyDbg 1 wird nicht von Apex erkannt. So muss man zwar mit weniger Features auskommen, aber ein Debugger ist besser als kein Debugger. Somit können wir nun mehr oder weniger bequem in den Wolfteam-Binaries rumstöbern und uns weiter auf die Suche nach Apex machen.

So far. Easy

5 people like this post.
    • tr4ceflow
    • 20. Mai. 2014 3:14pm

    Nette idee mit der Endlosschleife :-)

    • blup
    • 20. Mai. 2014 9:04pm

    Wieso nicht einfach Import benutzen und Hashsumme fälschen ?

      • Easysurfer
      • 20. Mai. 2014 9:36pm

      Berechtigte Frage :) Aber was die Netzwerktechnik angeht tappe ich noch ziemlich im dunkeln. Inzwischen logge ich zwar alle Packete mit (bevor sie verschlüsselt werden) und kann auch PacketID einer PacketRequest (String) zuordnen, aber dennoch sind die eigenlichen Daten der Packete noch nicht wirklich durchschaut und vorallem nicht immer gleich! Da ein solcher Hashsummencheck schwer zu finden ist (= dynamischer Speicher von Apex mit dynamischen Imports), hatte ich eh keine große Lust drin rum zu debuggen.

    • blub
    • 25. Mai. 2014 5:01pm

    Gibt es schon Fortschritte zu Apex ?

      • Easysurfer
      • 25. Mai. 2014 6:23pm

      Die gibt es und werden auch bald in einem Blogpost verarbeitet. Bis dahin müsst ihr euch noch gedulden ;)

  1. Noch keine TrackBacks.