Crack für Monkey Island 1 / Deutsch
Weil ich gerade so im SCUMM-Debugging drin bin, gibt’s hier auch als Bonus auch gleich einen Patch für Monkey Island 1 / Deutsch. Das Analyseschema ist dasselbe, was schon im vorherigen Post verwendet wurde, allerdings sind hier die Daten in einem LEC-File untergebracht und nicht in den separaten LFL-Files. Ich habe der Einfachheit halber einfach die Bytesequenz gesucht, da ich mir die Analyse der LEC-Files ersparen wollte. Ich habe wieder die Branches bei Erfolg und Fehler untersucht, diesmal sieht das Ergebnis so aus:
Falscher Code eingegeben:
(90:152:0x1BC): Script 152, offset 0x1bc: [3F] o5_drawBox()
(90:152:0x1C8): Script 152, offset 0x1c8: [9A] o5_move()
(90:152:0x1CD): Script 152, offset 0x1cd: [88] o5_isNotEqual()
(90:152:0x1D4): Script 152, offset 0x1d4: [14] o5_print()
(90:152:0x1D9): Script 152, offset 0x1d9: [14] o5_print()
(90:152:0x1E5): Script 152, offset 0x1e5: [AE] o5_wait()
Richtiger Code eingegeben:
(90:152:0x1BC): Script 152, offset 0x1bc: [3F] o5_drawBox()
(90:152:0x1C8): Script 152, offset 0x1c8: [9A] o5_move()
(90:152:0x1CD): Script 152, offset 0x1cd: [88] o5_isNotEqual()
(90:152:0x1F5): Script 152, offset 0x1f5: [14] o5_print()
(90:152:0x1FA): Script 152, offset 0x1fa: [27] o5_stringOps()
Die SCUMM V5-Files von Monkey Island sind nicht mit 0xFF werXORt, wie bei Loom, sondern mit 0x69. Der entsprechende Code befindet sich bei der EGA-Version auf Offset 3EA92 in DISK01.LCK:
3EA90: 6D 29 E1 63 68 DA 69 48 69 7D 96 66 49 69 7D 96
Das Ganze also nun wieder mit 0x69 verXORt ergibt:
3EA90: 04 40 88 0A 01 B3 00 21-00 14 FF 0F 20 00 14 FF
Man hat hier also ein o5_isNotEqual() und ersetzt es wieder durch einen Sprung an den richtigen Offset mittels o5_jumpRelative, welchen man vorher ja aus den 2 Branches berechnen konnte.
Fertig ergibt das dann flgende Modifikationen.
3EA90: 04 40 18 28 00 B3 00 21 00 14 FF 0F-20 00 14 FF
Wieder mit 0x69 verXORn und man hat einen fertigen Patch.
Bei der VGA-Version befinden sich die Bytes übrigens auf Offset 10959A. Noch Fragen?
System programmer
Comments
Welchen Hexeditor hast Du verwendet und welhe Datei muss geöffnet werden? Ich blick da nicht ganz durch…
Ich persönlich benutze den Hexeditor Hacker’s view, der läuft unter DOS, Windows und OS/2 und hat eine sehr einfache Bedienung. Aber man kann natürlich jeden beliebigen Hexeditor hernehmen, wie z.B. WinHex.
Die zu öffnende Datei ist DISC01.LEC (Im Post habe ich versehendlich .LCK geschrieben – sorry).
Um den Patch durchzuführen einfach die angegebene Originalsequenz (6D 29..) suchen. Die zu patchenden Bytes mit 0x69 verXORen und tauschen, das war’s mehr oder minder.
Vielen Dank!
Aber so ganz versteh ich das noch nicht. Was meinst Du mit verXORen?
Ich habe nun dies eingefügt (04 40 18 28 00 B3 00 21 00 14 FF 0F-20 00 14 FF) an der Stelle wo vorher dies stand (6D 29 E1 63 68 DA 69 48 69 7D 96 66 49 69 7D 96).
Bei der Codeabfrage gebe ich irgendwas an und dann kommt die Fehlermeldung: Local Variable 4037 out of Range (min 0 max 16)
Ui, nein, so war das nicht gemeint, damit hast Du’s kaputt gemacht.. 😉
Nochmal zurück zum Start. Es ist ganz simpel:
18 XOR 69 = 71
28 XOR 69 = 41
00 XOR 69 = 69
Das heißt: Ersetze die Bytes E1 63 68 durch 71 41 69
XOR ist einfach eine Rechenoperation. Die Lucasfilm-Spiele haben Ihren SCUMM-Code damit “geschützt”, indem sie alle Bytes mit einem bestimmten Wert (in unserem Fall 0x69) verXORt haben. Nachdem die Operation sowohl zum ent-, als auch zum verschlüsseln verwendet werden kann, habe ich versucht zu erklären, wie der ScummVM-Code also entschlüsselt aussieht und welche Operation man ändern muss. Nachdem der Interpreter die Daten aber in “verschlüsseltem” Format erwartet, muss man seinen Patch der entschlüsselten Opcodes natürlich wieder verschlüsseln, bevor man ihn ins File hineinpatcht und das war mit “wieder mit 0x69 verXORn” gemeint. Alles klar?
Hallo!
Ja nun hab ich das verstanden. Vielen Dank für die Hilfe.
Das heißt man kann das auf alle alten Klassiker von Lucasarts/Filmgames anwenden? Denke da gerade an Monkey2 und Indi4 und Loom werd ich mir dann auch mal anschauen ob ich das hinbekomme.
Aber mal noch was anderes. Wie findet man das raus mit den Sprungadressen? Muss man dafür den gesamten Code entschlüssen? Oder gibt es ein Analyseprogramm für soetwas?
Danke nochmals…
Der im Artikel referenzierte vorherige Post zum LOOM-Crack sollte Deine Fragen eigentlich beantworten: SCUMMVM dechiffriert im DEBUG-Modus die Opcodes und es gibt im WIKI auch ne opcode-Liste.
Hallo!
Kann man die Passwortabfrage für MI2 und IJ4 auch ganz deaktivieren?
Gruß, Thomas
Thomas: Wird man wohl mit etwas bastlerei auch können, allerdings muss man dann analysieren, welche Variablen in der Kopierschutzroutine gesetzt werden, die möglicherweise später noch benötigt werden, bevor man diese überspringt.
Auf jeden Fall ist das Ganze etwas komplizierter 🙂
Wow, danke. Hat super geklappt.
Trackbacks