Nun wird es ernst!
Seit einigen Tagen bin ich wieder aktiv am Reversen und Analysieren des RO Clients. Nicht primär mit dem Ziel, eine Bot Protection zu schreiben, sondern eher um mein Verständnis über dessen Funktionsweise zu verbessern. Ganz nebenbei entstand dabei (mit Timos tatkräftiger Hilfe :p) ein kleines Wiki, welches ich, hoffe ich jedenfalls, im Laufe der nächsten Monate auch noch erweitern werde. Darin sind einige Tabellen und Informationen bzgl. des RO Clients zu finden – größtenteils aus Gravity Funktionen gedumpt, dennoch werden einige davon sich zuweilen wohl als äußerst nützlich erweisen. Nach einem kurzen Test alternativer Wiki-Software habe ich mich letztendlich für das mir vertraute MediaWiki (wie es auch Wikipedia verwendet) entschieden.
Wiki: Klick mich
In einem Anflug von Langeweile habe ich bei der Auswahl der zu reversenden EXE für ein recht exotisches Exemplar entschieden. Es handelt sich dabei um eine der Exen aus der Zeit des großen Packet Scramblings, welche ganz nebenbei noch eine kleine Paketverschlüsselung in petto hat. Wer sich erinnert: Mitte Februar 2008 fing Gravity an, regelmäßig alle Packets IDs des RO Netzwerkprotokolls neu zu ordnen. Als damals auf kRO Sakray diese Exen verwendet wurden, war eAthena absolut hilflos und es gab nicht mal Ansätze einer Lösung des “Scrambling” Problems.
Ich habe mich nun aus reinem Interesse diesem Problem angenommen. Ja, ich weiß, es ist nicht mehr relevant. Aber ich kann mich danach immerhin besser fühlen, schließlich wäre ich gerüstet, wenn Gravity wieder mit dem Scrambling anfangen würde! *hust* Wie dem auch sei…
Auf den ersten Blick scheint das Scrambling Problem unlösbar zu sein – es sei denn man verbringt mehrere zig Stunden mit dem Disassembly der EXE und notiert sich Offsets. Ich weiß nicht mehr ob unter der Dusche oder auf dem Klo – jedenfalls sind mir für all diese Probleme in den letzten Tagen recht interessante Lösungsansätze in den Sinn gekommen.
Die Langeweileresistenz des RO Clients erwies sich als meinen Waffen (Editor, Windows Taschenrechner und IDA!) nicht gewachsen. Nach wenigen Minuten war die Packet Verschlüsselung geknackt und gut eine halbe Stunde später auch das Login Paket. Als erste harte Nuss sollte sich die erwartete Antwort des Mapservers auf den Login erweisen. Bis zu diesem Zeitpunkt hatte ich keine Ahnung vom Umfang der Paketänderungen, die Gravity an dieser EXE vorgenommen hatte. Es dauerte auch eine ganze Weile, bis ich den einfachsten Lösungsansatz gefunden hatte (diesmal ist er mir beim Essen gekommen…): Durch Vergleichen der Packet Handler war das gesuchte Packet schnell gefunden. Das Hauptproblem dabei: Der RO Client hat gut 650 Pakete in seinem Parser – und das sind nur die Ausgehenden. Es bedarf also eines Tools, welches den Handlervergleich automatisiert erledigen konnte. A simple matter of programming? Naja, fast. Es stellte sich als etwas verzwickt heraus, doch nach gut 2 Stunden fand das Tool bereits 291 Paketzugehörigkeiten und nach 3 Stunden waren dann (bis auf 3) fast alle benötigten (sprich eAthena bekannten) Pakete ausfindig gemacht.
Doch damit nicht genug – gut die Hälfte der Pakete wurde auch in ihrere Struktur verändert und fast alle vom Client ausgehenden Pakete sind mir noch unbekannt. Noch. Aus irgendeinem Grund hat dieser Client seit langem mal wieder meinen gesamten Ehrgeiz geweckt und so vermute ich, dass der noch verbleibende Teil in spätestens 2 Wochen vollständig implementiert ist. eAthena mit “Packet Scrambling”. 
Oh, und ganz nebenbei habe ich nun endlich einen zweiten Entwickler für Harmony… Aber dazu mehr im nächsten Artikel.
Zu guter letzt noch ein Foto meiner aktuellen “Arbeitsumgebung” =p
Links mein alter P4 zum Testen und der Laptop zum Entwickeln und für MSN/ICQ. Der PC bleibt in letzter Zeit meistens aus. Ab und zu hängt nur noch der 19″ TFT mit am Laptop.
:p