Apex = Defeated?
Anderthalb Monate ist es her, seid der erste Post über Apex entstanden ist. Nun bin ich an dem Punkt angelangt, Apex als besiegt zu bezeichnen. Zwar weis ich noch lange nicht, wie all die unzähligen Apex Module arbeiten, aber es reicht für uns einen Hack zu schreiben ohne das Apex (frei nach Archimedes) unsere Kreise stört , Mir ist klar dass dieser Post vielleicht von anderen Kopiert wird und als Vorlage für andere Hacks benutzt wird, daher werde ich keinen kompletten Source posten.
Im letzten Post wurde erwähnt dass Apex uns nach dem Hook von End2DOptimized und RenderString Kicks verteilt. Auch sollte im Hinterkopf behalten werden, dass Apex uns nicht selbst kickt, sondern nur Daten an den zentralen Server weiterleitet. Des weiteren sollten wir uns in das Gedächnis rufen, dass die Detour-Library die ersten 6 Bytes einer Funktion mit einem JMP ersetzt. Das alles deutet darauf hin, dass Apex irgendwie den Funktionsanfang prüft, ob dort Hooks gesetzt sind oder nicht. Prompt wurde CheatEngine gezückt und der Debugger attached, welcher in auf Lesezugriffe am Anfang der gehookten End2DOptimized Funktion achtet. Das selbe wäre auch mit OllyDbg möglich gewesen, aber CheatEngine ist in diesem Fall bequemer zu bedienen.
Mit allein diesem Resultat fangen wir wenig an. Wichtig ist zu wissen, dass generell 0x7XXXXXXX Adressen in den Kernelspace zeigen. Mit dem Debugger finden wir, dass 0x760575B2 in der Funktion IsBadReadPointer liegt und diese wohl unseren Funktionsanfang prüft. Der Call dazu erfolgt allerdings auf dem 0x0CCXXXXX Adressbereich. Wir wissen ja inzwischen, das Apex zwei große Module in den Speicher mapped, allerdings ist keines davon annährend in diesem Bereich. Ein Glück, dass VirtualAlloc gehooked ist und wir somit die dynamischen Speicherreservierungen mitbekommen. Darin finden wir:
14:08:20 Virtual Alloc! Size: 7d90, Addr: 0xcce0000, allocType: 1000, flProtect: 40
