Vorwort: Auweia – der heutige (und auch der folgende) Blogartikel sind leider (mal wieder) deutlich technischer geworden, als ich es zu Beginn geplant hatte. Generell versuche ich die technischen Themen auf dem Blog auf einem „moderaten“ Niveau zu halten und die Basteleien so zu beschreiben, dass man auch als Laie grob nachvollziehen kann um was es geht. Ich könnte mir vorstellen, dass es mir in diesem Fall nicht ganz optimal gelungen ist. 😀

Falls du das liest und nicht alles (oder generell nur Bahnhof) verstehst – gräme dich nicht, denn es geht wirklich tief in die Bits und Bytes rein. HILFE – nur noch Einsen und Nullen überall! 😉

In jedem Fall lohnt es sich bis zum Ende durchzuhalten, denn wie bei jedem guten Projekt gibt es am Ende (nach zahlreichen Rückschlägen) doch noch ein – wenn auch zuvor komplett anders geplantes – Happy End.

In diesem Sinne:

„If you successfully and completely read this and the next article – consider yourself a legend!“ 😉

Fest anschnallen Leute – heute wird es abgespaced – viel Spaß!

********

Hm, eigentlich habe ich euch über das Spiel „Electro Body“ ja bereits in Artikel 12 und Artikel 127 ausgiebig berichtet. Wieso kommt denn jetzt noch ein Beitrag dazu?

Nun, ich kann euch be(un)ruhigen, denn heute geht es eher um „die Technik“ als um das Spiel selbst. Eine Sache, die mich schon immer gestört hat, ist der nervige Kopierschutz. Bei jedem Spielstart muss man das Handbuch rauskramen, ein bestimmtes Wort (auf einer bestimmten Seite in einem bestimmten Absatz) heraussuchen…

… und das dann eingeben, bevor man spielen darf – mega ätzend! 🙁

Ob es eine Möglichkeit gibt, das Programm irgendwie zu überlisten? Ich erinnere mich ganz dunkel, dass man bei älteren Spielen und Anwendungen häufig einfach eine INI-Datei anpassen, oder die Passwörter aus den Programmdateien auslesen konnte…

Fun Fact: Kennt jemand z.B. die Datei „misson.dat“ von Siedler 2? Wenn man sich einfach zu blöd angestellt und eine Mission nicht geschafft hat, konnte man einfach in der Datei eine 0 in eine 1 umsetzen und schon galt die Mission als erfolgreich abgeschlossen und man konnte zur nächsten weiterschreiten! 😀

Meine anfängliche Euphorie, bzw. Hoffnung ist schnell verflogen, als ich mir die Programmdateien etwas genauer angesehen habe. Ganz so einfach ist es im Fall von „Electro Body“ wohl leider nicht, denn die Entwickler haben sämtliche Kopierschutzmechanismen in die „EB.EXE“-Datei integriert. Schade, aber das wäre wohl auch zu leicht gewesen. 😀

Und jetzt? Somit bleibt uns also nur der harte Weg – die manuelle Analyse der Software. Also quasi ein „reverse engineering“ des Spiels! Doch wie macht man das eigentlich?

Auch diese Frage ist leider nicht einfach zu beantworten. Eine generelle Vorgehensweise festzulegen wäre vermessen, denn jedes Programm und jede Architektur ist anders. Es gibt viele Abhängigkeiten wie z.B. für welche Plattform wurde ein Programm entwickelt (Windows, Unix/Linux, macOS, etc.) oder für welche Architektur (also für welchen Prozessortyp) wurde die Software konzipiert.

Im Fall von „EB.EXE“ handelt es sich um eine 16-Bit MS-DOS EXE (ausführbares Programm). Häufig werden diese DOS-Programme auch MZ-Datei genannt. Der Begriff leitet sich von den ersten zwei Bytes (4D und 5A) im Header so einer EXE ab. Das kann man gut mit Hex-Editoren wie z.B. der Software „HxD“ überprüfen. Die Hex-Werte 4D und 5A stehen in der ASCII-Codierung für die Buchstaben „MZ“.

Fun Fact: Und für was steht das MZ? Die Erklärung ist trivialer als man vielleicht glauben mag, der Erfinder des Dateiformats heißt „Mark Zbikowski“ und er hat sich, bzw. seine Initialen im Header des Dateiformats verewigt! 🙂

Alles schön und gut, aber wie hilft uns das weiter? Erst mal gar nicht, denn wir benötigen definitiv etwas Software um das Spiel genauer unter die Lupe zu nehmen…

Für gewöhnlich lasse ich Electro Body in der (bereits aus vergangen Artikeln bekannten) DOSBox laufen, da es ja nativ unter Windows nicht mehr läuft (16-Bit-Anwendung). Auch heute möchte ich die DOSBox verwenden, allerdings eine spezielle Debug-Version der Software. Diese bietet neben dem normalen Anwendungsfenster ein Debug-Menü, über welches man zur Laufzeit sämtliche Daten im Speicher (Register- und Speicherinhalte, Programmbefehle, etc.) auslesen und sogar modifizieren kann – abgefahren!

Und wie sieht das in der Praxis aus? Nachdem das entsprechende Verzeichnis gemountet und das Spiel gestartet wurde, habe ich auf dem Passwort-Bildschirm über die Tastenkombination [ALT]+[PAUSE] das Spiel angehalten.

Anschließend habe ich mich Schritt für Schritt ([F10] und [F11]) mit dem Debugger durch den Maschinencode gearbeitet (oder gequält?) und versucht zu verstehen, was passiert, bzw. an welcher Stelle das eingegebene Passwort geprüft wird. Die Bedienung des Debuggers ist dabei alles andere als selbsterklärend. Gut, dass es online eine gute Anleitung zu dem Thema gibt, sonst wäre man völlig aufgeschmissen!

Sobald man den grundsätzlichen Umgang mit dem Debugger drauf hat braucht man eigentlich nur noch viel Zeit, viel Geduld sowie ein geschultes Auge für Maschinensprache – definitiv kein leichtes Unterfangen! Das wäre alles viel einfacher, wenn man den originalen Quellcode zur Hand hätte. So bleiben uns nur die EXE-Datei mit den Maschinencodes selbst sowie die durch den Debugger interpretierten Assembler-Instruktionen…

Zumindest lassen sich über diesen Weg ein paar Infos über die Struktur des Programms, bzw. die einzelnen unterschiedlichen Abschnitte herausfinden. Für ein grobes Verständnis ist das ganz hilfreich, aber so richtig weitergekommen bin ich damit nicht, denn die entsprechende Routine, welche das Passwort prüft, wird wohl erst gestartet, sobald man die Eingabe mit Enter bestätigt – eigentlich logisch. Blöd nur, dass man nicht so schnell den Debugger starten und das Programm anhalten kann, ehe die Abfrage-Routine durchgelaufen ist. Irgendwie ein klassisches Henne-Ei-Problem! 😀

Um diesem Problem entgegenzuwirken, lassen sich an einer beliebigen Stelle im Code (bzw. in den Maschinenbefehlen) Haltepunkte (Breakpoints) setzen, welche das Programm an dem festgelegten Punkt anhalten (z.B. Befehl „bp 0408:3a0d“). Da ich keinerlei Ansatzpunkt hatte, an welcher Stelle das sein könnte, habe ich etliche Anläufe ([F5] zum Wiederanlaufen lassen, [ALT]+[PAUSE] zum Stoppen der Ausführung) benötigt, um zumindest ungefähr die Stelle herauszufinden, an der das Passwort geprüft wird.

Zusätzlich habe ich – um den Zeitpunkt nach der Eingabe eines falschen Passworts (und dem anschließenden Druck auf [ENTER]) etwas leichter zu erwischen, bzw. nicht zu verpassen – die CPU-Geschwindigkeit (CPU-Zyklen) der DOSBox (über die Tastenkombination [STRG]+[F11]) etwas gedrosselt. So hat man mehr Zeit das Programm anzuhalten, weil der ganze virtuelle/emulierte DOS-PC etwas langsamer läuft! 😉

Nach zahlreichen Stunden der Analyse bin ich dann doch noch auf einen grünen Zweig gekommen. Ich vermute es ist die Instruktion „JE 00003A21“ (Maschinencode x“740B“) an der Speicheradresse „0408:3A14“. Dieser „jump if equal“-Befehl wertet das Ergebnis der letzten Vergleichsoperation CMP al,[45E1] (x“3A06E45“) aus und entscheidet, ob das Programm mit einem Aufruf einer Subroutine (call 0000060D, bzw. „E8EFCB“) bei falscher Eingabe des Passworts abbricht, oder ob 11 Byte des Codes übersprungen werden und das Spiel letztendlich gestartet wird. Kranker Scheiß! 🙂

Jetzt ist nur die Frage, was wir dagegen tun können? Nun, dank dem mächtigen Debugger können wir – zumindest temporär – händisch im Speicher herumpfuschen! Oh weh, jetzt wird es richtig abgefahren… 😀

Konkret bedeutet das, dass wir den „JE-Befehl“ durch einen „JMP“ („unconditional Jump“) abändern müssen. Dieser prüft kein Ergebnis und sollte letztendlich in jedem Fall (egal bei welcher Passworteingabe) das Spiel starten. Um das zu bewerkstelligen, gibt man den Befehl „sm 0408:3a14 eb“ ein, welcher den Opcode (hexadezimaler Maschinenbefehl) x“74“ (JE) in x“EB“ (JMP) an der Speicheradresse „0408:3a14“ austauscht.

Fun Fact: Schon lustig, für einen unbedarften Außenstehenden muss das so aussehen, als wäre man in der Matrix abgetaucht. Überall kryptische Zeichen, weiße Schrift auf schwarzem Hintergrund und viele Nullen und Einsen. Leute, was soll ich sagen? So ist das eben, in der IT! 😉

Und siehe da, nach einem Druck auf [F5] läuft das Spiel wieder an und wir haben es tatsächlich geschafft das Programm zu überlisten. Das Spiel startet, obwohl ich nur Blödsinn als Passwort eingegeben habe! 😉

Fun Fact: Schon verrückt, was ein Byte Unterschied ausmachen kann, was? 🙂

Soweit so gut – zumindest haben wir damit bewiesen, dass sich das Spiel theoretisch (wenn auch nur temporär durch Manipulation der Speicherbereiche) überlisten lässt. Jetzt müssen wir es nur noch in der EXE-Datei selbst anpassen. Ein Kinderspiel, oder? Tja, wer das Intro gelesen hat weiß, dass es noch einen zweiten Teil gibt, also ist es wohl nicht so einfach… 😀

Seht es mir nach, wenn ich die Auflösung auf das nächste Mal verschiebe. Ich glaube das war heute sowieso schon viel Technik zu verdauen und ich wollte auch nicht, dass der Beitrag zu lang wird. In diesem Sinne – bis zum nächsten Mal wo wir (hoffentlich) das Spiel endlich hacken und eine Lösung für das Kopierschutzproblem finden können.

Ciao! 🙂