Erinnert ihr euch? Beim letzten Mal blieb ja noch die Frage unbeantwortet, wie wir die Änderung zur Überlistung des Kopierschutzes auch in der EXE-Datei durchführen können. So schwer kann das doch nicht sein… Oder? 😀
Fun Fact: Tief Luft holen Leute, es geht nochmal tief rein in die Nullen und Einsen, aber ich verspreche euch, ihr habt es fast geschafft! Ebenso gibt es gegen Ende des Artikels etwas leichte Kost in Form von Trivia über das Spiel. Durchhalten! 😉
Tja, in einer perfekten Welt könnte man nun einfach mit einem Hex-Editor die EXE-Datei öffnen und an der entsprechenden Stelle den Befehl in einen anderen Maschinencode ändern, doch leider ist dem nicht so. An der im Debugger angegeben Speicheradresse finden sich in der EB.EXE nämlich ganz andere Werte:
Fun Fact: Auch eine Suche nach dem zu tauschenden Befehlscode „74“ gestaltet sich schwierig, da dieser mehrere hundert (wenn nicht sogar tausend) Male in der Datei vorkommt. Mist! 😀
Kein Wunder, denn schließlich kann man anhand der EXE-Datei nicht bestimmen an welche Speicheradresse das Programm vom Betriebssystem letztendlich geladen wird. Nach weiteren mühsamen Stunden der Recherche habe ich zumindest eine Reihe von Maschinenbefehlen – um genau zu sein den Anfangspunkt (Entrypoint) des Programms – gefunden, welche zwischen Debugger (Adresse “23F1:0100“) und EXE-Datei („0xAE70“) übereinstimmen:
Doch leider bringt uns auch das nichts, denn erschwerend kommt hinzu, dass die Programmierer eine Technologie namens „Storage Overlay“ verwendet haben. Zu Anfangszeiten von MS-DOS standen den Anwendungen nur 640kB Arbeitsspeicher zur Verfügung. Aus diesem Grund haben findige Entwickler Programme entwickelt, welche sich selbst zur Laufzeit verändern und Daten in den Hauptspeicher nachladen. Zugegeben, eine brillante Idee, doch leider macht diese uns jetzt eine nachträgliche Analyse schwierig! 😀
Ich vermute, dass die anzupassende JE-Instruktion irgendwo als Datendefinition (vermutlich sogar noch gepackt oder verschlüsselt) in der EXE-Datei versteckt ist. Doch wie kommen wir ihr auf die Schliche? Ich befürchte der DOSBox-Debugger muss uns nochmal helfen…
Tatsächlich bietet der Debugger eine weitere nützliche Funktion namens „Memory Dump“. Damit lässt sich zur Laufzeit ein Abzug des Speichers (Dump) erstellt werden. Testweise habe ich das Spiel also gestartet und einfach mal 500 Byte („memdump 0408:3a01 500“) rund um die entscheidende Stelle (0408:3a14) im Speicherbereich abgezogen.
Die Datei wird im DOSBox-Verzeichnis als „MEMDUMP.TXT“ abgespeichert:
Mit einem Hex-Editor kann das Speicherabbild nun geprüft werden. Es sieht tatsächlich so aus, als hätten die Entwickler komplette Assembler-Instruktionen samt Speicheradressen als Bytedefinitionen codiert (verschlüsselt) in der EXE-Datei hinterlegt. Diese werden dann nach Programmstart geladen und irgendwie (mit einem mir unbekannten Algorithmus) aufbereitet und in Maschinenbefehle umgewandelt – clever! 😉
So langsam kommen wir der Sache näher, das ursprüngliche Problem bleibt aber: Das erstellte Speicherabbild zeigt nur die Situation im Speicher, nachdem das Programm die codierten Daten bereits geladen und umgebaut hat. Wie können wir nun also erkennen, welche Daten aus der EXE-Datei geladen werden?
Um das herauszufinden, habe ich noch zwei weitere (etwas kleinere) Speicherabbilder („memdump 0408:3a0d 20“) gezogen. Und zwar eines direkt nach Programmstart (kurz nachdem man die EXE-Datei in der DOSBox gestartet hat) und eines beim Passwortbildschirm, um herauszufinden, wie sich der Speicherbereich an der interessanten Stelle (Adresse „0408:3A14“) verändert.
Es sieht so aus als würde der Hex-Wert „DB“ aus der Datei gelesen und durch das Programm irgendwie in den JE-Befehl (Hex-Wert „74“) umgebaut werden. Um das zu überprüfen, habe ich mit HxD in der EXE-Datei nach „2DD4B34D8B2C34DB“ (betroffener Wert (DB) plus ein paar Bytes zuvor um ein eindeutiges Ergebnis zu erhalten) gesucht und bin tatsächlich fündig geworden!
An der Adresse x“6274“ in der Datei befindet sich der gesuchte „DB“-Wert. Laut Theorie müssen wir an dieser Stelle den Wert abändern, um den Kopierschutz auszuhebeln…
Bleibt abschließend eigentlich nur noch die Frage zu klären, durch welchen Wert wir „DB“ ersetzen müssen, damit aus dem „74“ (JE) ein „EB“ (JMP) wird?
Wenn man viel Zeit (und Lust) hat, könnte man jetzt versuchen, anhand der zuvor ausgeführten Maschinenbefehle im Debugger herauszufinden, wie das Programm und somit der verwendete Algorithmus die geladenen Hex-Werte konvertiert. Theoretisch möglich, aber leider ist 8086-Assembler nicht gerade mein Fachgebiet, daher habe ich einen anderen Ansatz gewählt. 🙂
Mit dem DOSBox-Debugger lässt sich ein Haltepunkt nicht nur auf einen Befehl, sondern auch auf eine Speicherstelle setzen! Das Programm hält selbstständig immer dann an, wenn der Speicherbereich an der angegebenen Stelle verändert wird. Mit einem „bpm 0408:3a14“-Befehl habe ich einen Breakpoint auf den zu ändernden JE-Befehl gesetzt:
Anschließend habe ich einfach etwas im Speicher rund um den Befehl herumgeblättert um einen „EB“-Wert zu finden. Leider ist der Datenspeicher in der DOSBox anders adressiert, somit müssen die Adressen zwischen Datenspeicher und Befehlsspeicherbereich umgerechnet werden – crazy shit! 😀
Und siehe da – mit einem neu gesetzten Speicherstellen-Breakpoint auf einen EB-Wert („bpm 0408:3a50“) habe ich herausgefunden, dass der Wert der aus der Datei geladen wird „89“ sein muss!
Fun Fact: Es sieht so aus als würden die Befehle „von hinten“ (absteigend laufende Schleife) im Speicherbereich aufgebaut werden. Ist das wichtig? Nein, ist mir nur beim Durchsehen der Befehle so aufgefallen! 🙂
Damit sollten wir doch hoffentlich endlich alle benötigten Informationen zusammen haben um das Spiel zu hacken, oder? Das bedeutet konkret, dass wir nur noch in der „EB.EXE“ an der Adresse x“6274“ den Wert „DB“ durch „89“ ersetzen müssen:
Fun Fact: Ich habe die Änderung vorsichtshalber in einer Sicherheitskopie (EB2.EXE) gemacht, nicht dass ich zu guter Letzt noch irgendetwas kaputt mache! 😀
Die Spannung steigt – ob unser Hack funktioniert? Die Frage kann wohl nur ein Test beantworten. Also schnell die DOSBox öffnen und die modifizierte EB2.EXE laden:
Doch was ist das?! Es klappt nicht?! 🙁
Das gibt es doch nicht! Tja, zu früh gefreut – die Passwortabfrage schlägt leider trotzdem fehl. So ein Mist, und ich dachte wirklich wir hätten es geschafft! 🙁 Doch woran liegt es, bzw. was haben wir falsch gemacht? Die kurze Antwort: Ich habe die Durchtriebenheit der Entwickler unterschätzt! 😀
Ich habe mir nochmal die Mühe gemacht und bin Statement für Statement im Debugger durchgegangen. Es sieht so aus als würde zwar der korrekte Wert „89“ aus der Datei gelesen werden, trotzdem wird dieser Wert in eine „74“ (JE) anstatt „EB“ (JMP) umgesetzt.
Nach einiger weiterer Analyse bin ich zum Schluss gekommen, dass der eingelesene Wert wohl nur die halbe Miete ist. Die Werte in den Registern deuten darauf hin, dass das Programm einen – mir unbekannten – Algorithmus zu beinhalten scheint, welcher unabhängig von dem Wert aus anderen Speicherbereichen mit dynamisch generierten Befehlen den „JE“ (74) wiederherstellt. Zugegeben – ich bin echt beeindruckt, das nenne ich mal einen hartnäckigen Kopierschutz! 😀
Um ehrlich zu sein habe ich an diesem Punkt frustriert aufgegeben, denn eine weitere Analyse erscheint mir nicht als sinnvoll. Ich habe so schon sehr viel Zeit (und Nerven) investiert und die Chance, dass ich ohne den Quellcode hinter den Algorithmus komme stehen nicht gut… 🙁
Was für ein Schlag in die Magengrube. Und wie geht’s jetzt weiter? War das alles umsonst? Nicht ganz, denn ich hatte euch ja doch ein „Happy End“ versprochen! 😉
Vor lauter Verzweiflung habe ich mich mit einer Mail an einen der Entwickler gewandt. Kein Witz! Ihr kennt mich – ganz oder gar nicht! 😉
Maciej Miasik ist ein polnischer Programmierer und absoluter Pionier der Videospielindustrie in Polen. Nicht nur, dass er als Designer, Programmierer, Produzent und Toningenieur tätig ist, auch ist er mittlerweile Dozent an einer polnisch-japanischen Akademie für Informationstechnologie sowie für den Bereich Videospielentwicklung an der Warschauer Filmschule zuständig. Was für uns aber noch viel wichtiger ist: Er war maßgeblich an der Entwicklung von Electro Body beteiligt und war bereit mir eine Antwort bezüglich des Kopierschutzes zu geben.
Fun Fact: Natürlich habe ich mir die Genehmigung eingeholt ihn zu erwähnen und seine Statements zu veröffentlichen.
Um ehrlich zu sein, hätte ich nicht mit einer Antwort gerechnet, da das Spiel ja bereits knapp 30 Jahre alt ist und ich mir vorstellen könnte, dass Maciej (betrachtet man seinen beruflichen Hintergrund) genügend andere Themen um die Ohren hat, als Fragen zu einem alten DOS-Spiel zu beantworten, aber was soll ich sagen? Manchmal muss man eben einfach nur nett fragen. 🙂
Hier sein Statement dazu:
It’s nice to read about your sentiment towards Electro Body. Removing the copy protection is quite tricky because we put a lot of effort into hiding many anti-tampering checks in the code. Although removing the initial check would be trivial for a skilled hacker, the game checks in many places for code changes in this particular place and alters the gameplay rendering the game unplayable after some time.
Puh, nachdem ich diesen Satz gelesen habe, bin ich sehr froh, dass ich nicht noch mehr Zeit in die Analyse investiert habe. Selbst wenn wir also die Passworteingabe und somit den Einstieg in das Spiel überlistet hätten, dann wäre es wahrscheinlich gewesen, dass das Spiel zu einem späteren Zeitpunkt erkannt hätte, dass wir etwas am Code verändert haben und sich von selbst beendet hätte. Ich kann nur nochmal die Entwickler für diese beeindruckende Programmierleistung loben! 🙂
Ok, und wo ist jetzt das versprochene Happy End? Immerhin haben wir es ja nicht geschafft den Kopierschutz zu umgehen!
Tatsächlich gibt es schon eine Lösung für das Problem! Maciej hat 2006 unter der Creative Common Lizenz eine Version des Spiels ohne Kopierschutz kostenlos als Freeware veröffentlicht. Der Titel „Electro Man“ ist aus der amerikanischen Version des Spiels übernommen worden…
…aber ansonsten spielt sich die Version des Spiels eins zu eins wie die von unserer Diskette – nur eben ohne Kopierschutz! 😉
Als kleiner Bonus hatte Maciej mir auch noch etwas Trivia zum Spiel zukommen lassen. Diese möchte ich euch nicht vorenthalten:
I especially liked the label on the diskette – we had only labels for the larger 5,25″ floppies as the small ones weren’t very popular at that time in Poland and there was no point to make the small labels – so we reused the larger ones.
Adamik was an exporter of automotive parts to Poland. He was a Pole and it was his son who saw the game and convinced the father to sell it in Germany (West-Germany, by their request). The boxes were manufactured in Poland and shipped to Germany for further distribution. I even remember some old Adamik logos on the parts stores in Poland long after the company disappeared.
The diskettes were duplicated by an ordinary PC using a simple copier written by us. We couldn’t afford anything professional at that time. Those were off-the-shelf floppies, hence we didn’t care about the copy protection tab as that was quicker and more convenient.
The Electro Body title is related to the Electro Body Music genre and the music on the cassette as well. We were huge fans of EBM at that time and that obviously shows. Epic requested the title change [for an american release] but couldn‘t really explain why.
Our digital sound system only managed to play one channel of audio at the same time, therefore the music in the menu, and sound effects during the game. We couldn’t fit more soundtracks in the game for some reason I don’t remember now (storage limitations or memory limitations).
We wanted to give our customers something special with their purchase, hence the cassette with an “extended” soundtrack, which can be enjoyed separately. The cassettes were manufactured professionally by a duplication factory, as at that time we had a bloom of “disco polo” music which allowed former music pirates to become professional music publishers with proper duplication equipment.
The ARJ archiver wasn’t used for compression but as a container for all game files for the installation program. The data was already compressed hence negligible gain with ARJ.
“Jesus is here!” sample is from Front 242’s Welcome to Paradise (which sampled some televangelist). This was changed for Epic’s release (sample had been reversed).
I never finished the game. That has become my habit – I never play games I make. I mean in their entirety – because I play the fragments I work on hundreds of times, but when the work is done I am too fed up with the game to enjoy it. My wife played the whole game though.
Ende gut – alles gut. Ich bin froh, doch noch zu einem versöhnlichen Abschluss gekommen zu sein, wenn auch ich es nicht geschafft habe den Code zu knacken. Danke nochmal an Maciej für die vielen Infos, die Hilfe und die Bereitschaft bei diesem Artikel mitzuwirken!
So, ich bin dann mal weg, es gibt noch eine ganze Schar an pixeligen Robotern abzuballern! 😉
Bis die Tage, ciao!