DOS-Spiele – was gibt es eigentlich schöneres als DOS-Spiele? Richtig – nichts! 😛

Im Verlauf der letzten gut fünfzig Beiträge haben wir uns ja mit zahlreichen alten PCs beschäftigt und dabei auch einige DOS-Games zum Laufen gebracht. Darunter fanden sich ein paar echte Adventure-Klassiker (z.B. The Secret of Monkey Island oder Day of the Tentacle), Rennspiele (wie z.B. Micro Machines), ein paar Geschicklichkeitsspiele (z.B. Prehistorik oder Croc: Legend of the Gobbos) und eben auch eine Hand voll Puzzlespiele (z.B. Blockout oder Pushover).

Gerade letztere – häufig auch als „Denk- oder Knobelspiele“ betitelte – Gattung von Spielen wird meist zu Unrecht als langweilig oder uninteressant abgestempelt. Dabei müssen selbst Hardcore-Gamer, welche sich überwiegend mit Titeln wie GTA, FIFA, Cyberpunk, Read Dead Redemption, Call of Duty, Fortnite, League of Legends oder Battlefield beschäftigen, zugeben, dass sie schon mal Tetris gespielt, ein Sudoku ausgefüllt oder ein Puzzlespiel auf dem Smartphone (z.B. 4 Bilder 1 Wort, Logo-Quiz, Candy Crush Saga, etc.) gespielt haben. Stimmt’s oder habe ich Recht? 😛

Eines dieser Puzzlespiele, welches ich seit Kindheitstagen kenne (und spiele) ist „The Incredible Machine“ von Entwickler Dynamix aus dem Jahre 1992.

Ziel des Spiels ist es, mit Hilfe verschiedener Utensilien Maschinen zu bauen, die jeweils eine bestimmte Aufgabe (z.B. das Befördern eines Basketballs in einen Korb) erfüllen sollen. Als Utensilien stehen neben technischen Bauteilen wie Zahnrädern und Förderbändern auch Haushalts- und Freizeitgegenstände sowie einige Tiere (Tiere?!) zur Verfügung. Klingt abgefahren, ist es auch. 😀

Zu Beginn eines jeden Puzzles sind bereits diverse Bauteile der Maschine platziert. Alle übrigen Teile müssen vom Spieler so eingesetzt werden, dass eine Kettenreaktion entsteht. Diese werden dabei von Level zu Level immer komplexer. Hier heißt es also: Hirn anschalten! 😉

Es ist eine eher gemächliche Spielerfahrung, bei der man durch einfaches „Herumprobieren“ häufig schon weiterkommt und dazulernt, für was welches Utensil gut ist – fast so wie bei einem Adventure! Um ehrlich zu sein, kann ich euch gar nicht genau sagen, was mich an dem Denkspiel so fasziniert. Vielleicht ist es einfach das Konzept selbst. Man fühlt sich tatsächlich etwas wie ein verrückter Wissenschaftler, der auf möglichst umständliche Weise vermeintlich triviale Dinge erledigt. Also voll mein Ding! 😛

Heute soll es aber nicht um das Spiel selbst gehen, sondern um die Art und Weise, wie die Entwickler sichergestellt haben, dass nur Leute, welche das Original erworben haben, in den Genuss des Spiels kommen – den Kopierschutz also. Direkt nach dem Spielstart erhält man die Aufforderung aus einer Auswahl von diversen, im Spiel vorkommenden Gegenständen drei bestimmte auszuwählen.

Welche das sind, lässt sich nur auf der jeweils angegeben Seite im Handbuch nachschlagen. Für gewöhnlich macht mir der Kopierschutz bei so betagten Games nichts aus – im Gegenteil: Das Nachschlagen von bestimmten Worten im Handbuch oder das Drehen an einem „Codewheel“ wie z.B. bei den Monkey Island Spielen tragen maximal zum Flair solcher alten Spiele bei. Im Falle von „The Incredible Machine“ geht mir der Kopierschutz allerdings gehörig auf die Nerven.

Woran liegt das? Nun, leider habe ich bereits vor Jahren das originale Handbuch verlegt oder im dümmsten Fall sogar entsorgt. Klar, man findet online noch eine Kopie davon und ich habe mir sogar die relevanten Passagen herausgesucht und ausgedruckt, aber es ist einfach nicht das gleiche Feeling, als mit einem echten, gebundenen Handbuch! 🙁

Wäre es nicht schön, wenn wir die Kopierschutzabfrage einfach überlisten könnten? So könnten wir uns das (kopierte) Handbuch komplett sparen und direkt ins Spiel einsteigen. Um herauszufinden, wie so etwas funktionieren könnte, sollten wir uns mal die Spieldateien etwas genauer ansehen. Leider ist mittlerweile auch die originale Diskette defekt und wurde entsprechend vor ca. zwei Jahren entsorgt. Glücklicherweise konnte ich kurz vor ihrem Ableben die Daten noch auf einen zweiten Datenträger sichern und so die Spieldateien retten. Es geht doch nichts über Backups! xD

Schön und gut, aber wie hilft uns das jetzt bei dem Kopierschutz weiter? Den Adleraugen unter euch wird sicher sofort aufgefallen sein, dass das Spiel bei mir gerade in der DOSBox, also virtuell in einem Emulator läuft. Tatsächlich habe ich das Spiel auch auf einigen der Retro-PCs installiert, aber heute habe ich die Spieldateien absichtlich auf einen „modernen“ PC kopiert, damit wir uns die Spieldaten mit dem DOSBox-Debugger (siehe Artikel 168) mal etwas genauer ansehen können.

Konkret sollten wir uns die „TIM.EXE“ ansehen. Dabei handelt es sich um die Haupt-Spieldatei und ich gehe mal stark davon aus, dass die Kopierschutzabfrage irgendwo darin versteckt ist. Wie damals bei „Electro Body“, handelt es sich um eine 16-Bit MS-DOS EXE (MZ-Datei). Wir können nur hoffen, dass die Entwickler den Programmcode nicht verschlüsselt oder ihn mit Hilfe von listigen Technologien (genannt „Obfuscation“) wie z.B. „Storage Overlay“ verschleiert haben.

Als erstes sollten wir mal das Spiel starten und die Ausführung mit Hilfe des Debuggers und der Tastenkombination [ALT]+[PAUSE] direkt vor der Kopierschutzabfrage anhalten.

Um jetzt herauszufinden, wie das Programm tickt, bzw. an welcher Stelle genau die drei Symbole geprüft werden, müssen wir uns Schritt für Schritt ([F10]) durch den Maschinencode arbeiten und versuchen, Muster zu erkennen. Häufig sind Vergleichsoperationen (z.B. CMP-Instruktionen) und (bedingte) Sprungbefehle (z.B. JMP, JE, JNE) ein gutes Indiz für Abfragen.

Meist landet man im Rahmen der Erstanalyse in irgendwelchen Schleifen, in denen die gleichen Maschinenbefehle ständig (in nur leicht modifizierter Form) wiederholt werden. Um nicht jeden einzelnen Maschinenbefehl ansehen zu müssen, können wir das Spiel an einer bestimmten Speicherstelle mit Hilfe von Breakpoints (also Haltepunkten) anhalten (z.B. „bp 0fd1:0db0). Gerade am Anfang ist mehr „Glück“ dabei, ob man einen geeigneten Haltepunkt erwischt, oder ob man bereits die entscheidende Stelle übersprungen hat. So ist das eben beim Reverse Engineering! 😉

Ich gebe es zu – das ist ein recht mühsames Unterfangen und leider lässt sich auch keine generelle, für alle Programme geeignete, Vorgehensweise empfehlen. Mir persönlich hilft es immer, ein Auge auf die Speicherbereiche zu haben. Ändern sich diese plötzlich, kann man davon ausgehen, dass eine neue Funktion angesprochen wird. Hier befinden wir uns z.B. mutmaßlich in einer Unterroutine, welche für die Ausgabe der Hintergrundmusik verwendet wird.

Not so fun Fact: Leider läuft das Spiel in einer permanenten Schleife, um die Hintergrundmusik via Sound Blaster auszugeben. Das macht die Suche nach dem eigentlichen Programmcode nicht gerade einfacher. Im Idealfall lässt sich die Soundausgabe (z.B. via Konfigurationsmenü) vorab deaktivieren.

Viele aufeinanderfolgende Vergleichsoperationen sind dagegen ein Indiz dafür, dass eine tabellenartige Struktur (wie z.B. die Hex-Werte der eingegebenen Symbole) geprüft wird. So langsam kommen wir der Sache näher…

Um herauszufinden, was passiert, wenn man die Symbole korrekt eingibt, habe ich die entsprechenden Werte aus dem Handbuch herausgesucht, eingegeben und mich mit Haltepunkten bis zur Adresse „0fd1:0e03“ vorgekämpft. Tatsächlich glaube ich, dass an dieser Stelle bereits eine Prüfung der eingegebenen Symbole stattgefunden hat und nur das Ergebnis ausgewertet wird.

Was mich da so sicher macht? Nun, ein paar hundert Maschinenbefehle später, nämlich ab der Adresse „0fd1:09cc“ wird der Bildschirm schwarz und das eigentliche Spiel wird gestartet, bzw. geladen. Im Endeffekt, muss die Prüfung also kurz davor stattfinden! 🙂

Generell macht es Sinn, sich während der Analyse Aufzeichnungen der entsprechenden Speicheradressen und Maschinenbefehle anzulegen. So lassen sich Speicherbereiche leichter identifizieren und bereits analysierte Stellen leichter überspringen.

Fun Fact: Passend zum Spielkonzept von The Incredible Machine sehen auch diese Aufzeichnungen so aus, als wären sie das Werk eines verrückten Wissenschaftlers! xD

Fassen wir alle Erkenntnisse zusammen, würde ich nun also vermuten, dass sich der für uns relevante Befehl an der Adresse „0fd1:0e0e“ befindet. Dieser „jump not equal“ (JNE $+3) überspringt den darauffolgenden Befehl, sofern die vorherige Prüfung (CMP word [bp-12],0000) erfolgreich ist. Das ist der Fall, wenn die Symbole korrekt eingegeben wurden. Der nachfolgende Befehl (JMP $-16d) ist wiederum der Rücksprung zur Prüfung der eingegebenen Symbole, also quasi das, was passiert, wenn man die falschen Symbole eingegeben hat. Ich weiß – einfach ist anders. Seid ihr noch wach? 😀

Um meine Theorie zu überprüfen, können wir den Programmcode mit Hilfe des Debugger-Befehls „sm 0408:3a14 74“ an der Stelle im Speicher temporär modifizieren und durch einen „JE“ (jump equal) ersetzen. Dieser sollte dann genau das Gegenteil bewirken, also das Spiel starten, sofern falsche, oder gar keine Symbole eingegeben wurden.

Und siehe da – tatsächlich startet das Spiel, obwohl wir gar keine Symbole eingegeben haben. Ist das nicht geil? 😀

Leider war das nur die halbe Miete, denn jetzt müssen wir diese Maschinenbefehle irgendwo in unserer „TIM.EXE“-Datei finden und hoffen, dass sie nicht dynamisch zusammengebastelt werden (so wie damals bei Electro Body in Artikel 169). In der Theorie müssten wir beide Jump-Befehle (den anzupassenden „JNE $+3“ sowie den „JMP $-16d“ danach) in ihrer hexadezimalen Form, also „7503E993FE5F“ in der EXE-Datei finden, oder? Tja, Pustekuchen, so einfach haben es die Entwickler uns leider nicht gemacht. Wäre ja auch zu schön gewesen! 😀 Die Frage ist jetzt nur, wie sie den Code versteckt haben. Sofern mit Storage Overlays gearbeitet, oder eine proprietäre Verschlüsselung verwendet wurde, sehe ich wenig Chancen, dass wir das anzupassende Byte finden.

Aufgeben möchte ich allerdings noch nicht, denn, wenn wir Glück haben, wurden die Daten „nur“ komprimiert. Das Komprimieren von EXE-Dateien war eine populäre Methode, um Platz zu sparen und Hackern das lesen (und anpassen) des Maschinencodes zu erschweren. Dafür wurden spezielle Tools verwendet, welche sog. „selbstextrahierende Archive“ erstellen konnten. Dabei werden die Daten mit einem bestimmten Algorithmus komprimiert und das Entpackprogramm wird mit in der EXE-Datei gespeichert. Aus Sicht des Anwenders handelt es sich um eine normale EXE-Datei, aber bei deren Ausführung wird der Inhalt der EXE-Datei automatisch im Arbeitsspeicher entpackt, bzw. dekomprimiert und erst dann wird der eigentliche Programmcode ausgeführt – abgefahren! 🙂

Fun Fact: Populäre Tools zum Erstellen von selbstextrahierenden, unter DOS ausführbaren EXE-Archiven sind z.B. „PKLite“ oder „LZEXE“.

Um zu überprüfen, ob unsere „TIM.EXE“ komprimiert wurde, müssen wir uns einen „Decompressor“ herunterladen. Das wohl beste Tool für DOS-Anwendungen heißt „UNP“, denn die Software unterstützt zig unterschiedliche Formate und Komprimierungsalgorithmen. Tatsächlich kann UNP unsere Datei lesen und extrahieren. Aha, es wurde also LZEXE als Packprogramm verwendet! 😉

Die spannende Frage ist, ob wir jetzt den zuvor identifizierten Maschinencode im „Klartext“ in der entpackten EXE-Datei finden. Tatsächlich – ab Adresse 1155AE lässt sich der Jumpbefehl jetzt auch im Hexeditor erkennen:

Mit einem Tastendruck ist das „problematische“ Byte ausgetauscht:

Um einen möglichst originalgetreuen Zustand wiederherzustellen, sollten wir unsere modifizierte EXE-Datei abschließend noch komprimieren. Dafür verwenden wir die Software „LZEXE“, schließlich wurde die originale EXE-Datei ja auch mit dem Tool komprimiert.

Fun Fact: Fragt mich bitte nicht, wieso ich die französische Version heruntergeladen habe. Es war schon spät und im Endeffekt kann man – auch auf französisch – nicht viel falsch machen! 😀

Es ist schon verblüffend, wie gut diese Komprimierung funktioniert. Ich hätte nicht erwartet, dass eine EXE-Datei (in der sich ja eigentlich größtenteils Binärdaten befinden) fast um die Hälfte komprimiert werden kann. Das spricht dafür, dass ein größerer Bereich der Datei mit wiederkehrenden (und so leicht komprimierbaren) Kopierschutzabfragetabellen belegt ist.

Fun Fact: Ich habe die originale „TIM.EXE“ und unsere selbst zusammengeschusterte „TIMX.EXE“ im Hexeditor nebeneinandergelegt. Durch die Manipulation des einen Bytes haben sich auch noch ein paar andere Bytes in der EXE geändert. Ich vermute, dass das so Dinge wie Prüfsummen, etc. sind.

Puh, das war aber eine ganz schöne Odyssee. Jetzt bleib eigentlich nur noch die abschließende Frage zu klären: Hat unser kleiner „Hack“ funktioniert und lässt sich das Spiel über unsere modifizierte EXE-Datei noch starten, bzw. ohne Kopierschutz spielen? YES SIR! 🙂

Ich kann euch gar nicht sagen, wie glücklich ich bin, dass wir es diesmal zu einem echten „Happy End“ gebracht haben. Mir ist klar, dass das heute eher schwere Kost war, aber ich hoffe euch hat der kleine Ausflug in die Welt der „Nullen und Einsen“ längst vergangener Tage trotzdem gefallen. Ich bin jedenfalls sehr zufrieden und gönne mir jetzt als Belohnung noch ein paar Level des Spiels. Schließlich gibt es noch so viele „incredible machines“ zu bauen! 😉

In diesem Sinne – bis die Tage, ciao!