Das Reversen einer Ragnarok EXE beginnt eigentlich immer gleich. Anhand irgendwelcher Referenzen sucht man Funktionen wie GetMsgString (msgstringtable.txt Zeilen auslesen) und verteilt in IDA die passenden Namen.

Erst kam die mühsame Handarbeit, welche mit wachsendem Umfang der Modifikationen immer langwieriger wurde…

Dann kann ein C Tool namens GetOffset, welcher mir eine Art C #define Syntax ausgab…

Und nun kommt das IDA Plugin! Im Zuge einer Rundumerneuerung meiner RO Tools hatte ich heute Mittag die Idee, eine einheitliche Möglichkeit zu schaffen, die wichtigsten Offsets ohne viel Aufwand in IDA zu importieren.

Erster Gedanke: Ich generiere mit GetOffset einfach eine PDB Datei und importiere diese. Mit der DbgHelp Library wäre das auch relativ problemlos möglich gewesen. Ein zufälliger Blick auf den Ordner der IDA 5.2 SDK hat mich dann jedoch dazu veranlasst, ein IDA Plugin zu schreiben.
Ich hatte mich bezüglich Plugins vorher nur mit PHP beschäftigt. Wer mit dem PHP Extension System vertraut ist, wird nachvollziehen können, mit welchen Erwartungen ich an die IDA SDK heran gegangen bin.
Es stellte sich jedoch schnell heraus, dass man die IDA SDK in keiner Weise mit dem aufgeblasenen, vollgestopften, unübersichtlichen Zend Extension System vergleichen kann. Ein funktionierendes Plugin benötigt ~10 vordefinierte Zeilen, alle Header und die beinhalteten Funktionen sind dokumentiert und mit ein wenig Einarbeitung kann man sehr schnell mächtige Plugins schreiben. Beispiel gefällig?

ea = get_name_ea(BADADDR, “ijlWrite”);
if( ea == BADADDR )
{
msg(“Failed to fetch DoScreenshot – aborting.\n”);
return;
}
xb.first_to(ea, XREF_ALL);
ea  = xb.from;
ea  = ea2func(ea);
set_name(ea, “DoScreenshot”, SN_NOCHECK);

So in der Art gestaltet sich die gesamte Arbeit mit der IDA SDK. Alles ist in simplen Funktionen zusammengefasst. Weiterhin ist in der Readme.txt eine Übersicht aller Headerdateien mit jeweils ein paar Worten zu den beinhalteten Funktionen – somit findet man meistens ohne viel Aufwand die richtige Headerdatei.

Wie dem auch sei – ich habe also ein kleines IDA Plugin geschrieben. Es analysiert die RO EXE, sucht relevante Funktionen und benennt sie dementsprechend. Als kleines, aber dennoch ziemlich nützliches Nebenfeature werden alle Aufrufe von GetMsgString() gesucht und der passende Text wird als Kommentar darübergeschrieben. Somit hat man bei einem Aufruf von GetMsgString sofort eine Ahnung, worum es im betreffenden ASM Block gerade geht

Im Laufe der nächsten Tage werden evtl. noch Enums und Klassen/Strukturen dazu kommen. Mal sehen wie viel Langeweile ich habe …

In der Athena Szene benutzt sie fast jeder – und dennoch weiß fast niemand genau, was dahinter steckt. Da ich in den letzten Wochen öfters nach Diffs und deren Funktionsweise gefragt wurde, werde ich einfach mal versuchen, das System dahinter zu erklären.

Vorweg: Eine .diff Datei hat nichts mit Subversion oder ähnlichen Systemen zu tun, auch wenn dort häufig ähnliche Suffixe verwendet werden. RO-Diffs sind nichts weiter als normale Textdateien. Wenn man sich beispielsweise einen der aktuellen kRO Sakray Diffs mit dem Editor anschaut, wird man so etwas zu Gesicht bekommen:

Die erste Zeile beinhaltet die CRC32 Prüfsumme der EXE. Dieser Wert dient dazu, dass man nicht aus Versehen eine mit diesem Diff inkompatible EXE verwendet. Durch Modifikationen wie XRay ändert sich dieser Wert natürlich, daher muss man bei XRay EXEn auch stets die CRC Überprüfung deaktivieren.

Die “BLURB”-Zeile ist nichts weiter als der Titel des Diffs. Dieser steht meistens über den Optionen und hat ansonsten keinerlei Relevanz.

Nun wird es interessant. Wie man sieht besteht jede Diff Option aus mehreren Zeilen. Jede Zeile repräsentiert hierbei ein Byte, das in der EXE verändert wird. Wenn man eine Diff Option auswählt, werden alle dazugehörigen Zeilen abgearbeitet.
Doch nun zum Aufbau der einzelnen Zeilen: Im Grunde genommen sagt jede Zeile dem Diff Tool “gehe an Position X, dort müsste Y stehen. Ersetze dieses Zeichen mit Z.” Die Position (aka Adresse, Offset) ist im Hexadezimalsystem geschrieben. Die erste Zahl nach der Adresse ist der Wert, der an der Adresse stehen sollte und die zweite Zahl der Wert, durch den der vorherige ersetzt werden soll. Klar soweit?

Nehmen wir jetzt mal an, wir wollen für die Sakexe vom 15.01.2009 (Klick mich) einen Diff schreiben, der den Fenstertitel auf Rohrzucker ändert.
Wie jeder weiß, ist der normale Fenstertitel Ragnarok. Also nehmen wir den Hexeditor unserer Wahl den wohl besten Hex Editor, XVI32, öffnen die EXE und suchen nach dem String Ragnarok.

Der Fenstertitel wird an CreateWindowExA übergeben, als Parameter wird ein C String verwendet. C Strings werden mit einem ASCII 0 terminiert. also muss nach dem Text Ragnarok ein 00 stehen.

(Paint <3)

Gefunden! Man könnte nun einfach im Überschreibmodus den neuen Fenstertitel eintragen, abspeichern und sich über den neuen Fenstertitel freuen. Aber es geht hier ja um Diffs!
Nun steht also in der Statusleiste die Adresse, an der wir uns befinden. Damit die Adresse im Hexadezimalsystem angegeben wird, vorher ggf. Tab drücken, damit die linke Seite weiß erscheint und die rechte Seite grau.

Diese Adresse ist nun der Wert für das erste Zeichen. Wir wollen ja Rohrzucker verwenden. Also wandeln wir das Wort Rohrzucker in die entsprechenden Asciiwerte um. Um sich den Blick in die Ascii Tabelle zu ersparen (ich bezweifle einfach mal, dass sie bei jedem am Monitor klebt…), empfiehlt sich mein hochkomplexes PHP Tool: Klick mich. Da die Zeichenwerte in Diffs Dezimal sind – wer auch immer sich das ausgedacht hat … – ist lediglich die untere Zeile relevant. Die “vorher”-Werte kann man im Hexeditor ablesen, die “nachher”-Werte bekommt man durch das Tool, die Adresse bekommt man durch Erhöhen der Anfangsadresse.

Nun noch einen Titel hinzufügen, als .diff speichern und testen!

Und noch einmal der Vergleich:

=D

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