Crystals-DSA-Foren
Reverse Engineering der NLT II - Druckversion

+- Crystals-DSA-Foren (https://www.crystals-dsa-foren.de)
+-- Forum: Allgemeines zur Nordlandtrilogie DOS (https://www.crystals-dsa-foren.de/forumdisplay.php?fid=20)
+--- Forum: Technische Werkstatt (https://www.crystals-dsa-foren.de/forumdisplay.php?fid=34)
+--- Thema: Reverse Engineering der NLT II (/showthread.php?tid=5383)

Seiten: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

RE: Reverse Engineering der NLT II - siebenstreich - 08.02.2021

Danke für diese ausführliche Antwort!

So ganz funktioniert es leider noch nicht.
Das Skript ./disassemble.sh (das ich noch ausführbar machen musste) liefert bei mir
Code:
SEG001.dis near =  3  far = 25  changed
SEG002.dis near =  92  far = 338  changed
SEG003.dis near =  0  far = 9  changed
SEG004.dis near =  30  far = 67  changed
SEG005.dis near =  2  far = 63  changed
SEG006.dis near =  3  far = 33  changed
SEG007.dis near =  1  far = 0  changed
SEG008.dis
SEG009.dis
SEG010.dis near =  0  far = 2  changed
SEG011.dis
SEG024.dis near =  1  far = 23  changed
SEG025.dis near =  14  far = 143  changed
SEG026.dis near =  9  far = 160  changed
SEG027.dis near =  0  far = 140  changed
SEG028.dis near =  7  far = 129  changed
SEG029.dis near =  2  far = 56  changed
SEG030.dis near =  3  far = 118  changed
SEG031.dis near =  1  far = 29  changed
SEG032.dis near =  0  far = 88  changed
SEG033.dis near =  0  far = 124  changed
SEG034.dis near =  0  far = 82  changed
SEG035.dis near =  0  far = 32  changed
SEG036.dis near =  0  far = 49  changed
SEG037.dis near =  0  far = 34  changed
SEG038.dis near =  1  far = 8  changed
SEG039.dis near =  0  far = 27  changed
SEG040.dis near =  0  far = 27  changed
SEG041.dis near =  1  far = 40  changed
SEG042.dis near =  0  far = 129  changed
SEG043.dis near =  0  far = 138  changed
SEG044.dis near =  0  far = 23  changed
SEG045.dis near =  0  far = 12  changed
SEG046.dis near =  0  far = 108  changed
SEG047.dis near =  0  far = 17  changed
SEG048.dis near =  0  far = 87  changed
SEG049.dis near =  0  far = 63  changed
SEG050.dis near =  0  far = 68  changed
SEG051.dis near =  2  far = 87  changed
SEG052.dis near =  0  far = 46  changed
SEG053.dis near =  0  far = 66  changed
SEG054.dis near =  0  far = 79  changed
SEG055.dis near =  2  far = 39  changed
SEG056.dis near =  0  far = 100  changed
SEG057.dis near =  0  far = 107  changed
SEG058.dis near =  2  far = 87  changed
SEG059.dis near =  0  far = 45  changed
SEG060.dis near =  1  far = 115  changed
SEG061.dis near =  3  far = 86  changed
SEG062.dis near =  0  far = 74  changed
SEG063.dis near =  3  far = 88  changed
SEG064.dis near =  0  far = 7  changed
SEG065.dis near =  0  far = 134  changed
SEG066.dis near =  55  far = 111  changed
SEG067.dis near =  9  far = 114  changed
SEG068.dis near =  2  far = 125  changed
SEG069.dis near =  0  far = 48  changed
SEG070.dis near =  0  far = 86  changed
SEG071.dis near =  0  far = 70  changed
SEG072.dis near =  5  far = 64  changed
SEG073.dis near =  0  far = 21  changed
SEG074.dis near =  13  far = 34  changed
Traceback (most recent call last):
  File "./nc2fc.py", line 63, in <module>
    opcode = int(pushline[1][:2], 16)
IndexError: list index out of range
SEG076.dis near =  9  far = 87  changed
SEG077.dis near =  0  far = 61  changed
SEG078.dis near =  0  far = 119  changed
SEG079.dis near =  1  far = 107  changed
SEG080.dis near =  0  far = 98  changed
SEG081.dis near =  0  far = 141  changed
SEG082.dis near =  0  far = 55  changed
SEG083.dis near =  12  far = 118  changed
SEG084.dis near =  0  far = 125  changed
SEG085.dis near =  0  far = 102  changed
SEG086.dis near =  0  far = 76  changed
SEG087.dis near =  0  far = 162  changed
SEG088.dis near =  0  far = 30  changed
SEG089.dis near =  28  far = 105  changed
SEG090.dis near =  4  far = 76  changed
SEG091.dis near =  7  far = 57  changed
SEG092.dis near =  1  far = 90  changed
SEG093.dis near =  0  far = 46  changed
SEG094.dis near =  5  far = 56  changed
SEG095.dis near =  20  far = 60  changed
SEG096.dis near =  14  far = 12  changed
SEG097.dis near =  6  far = 89  changed
SEG098.dis near =  2  far = 81  changed
SEG099.dis near =  0  far = 81  changed
SEG100.dis near =  0  far = 79  changed
SEG101.dis near =  0  far = 80  changed
SEG102.dis near =  0  far = 35  changed
SEG103.dis near =  0  far = 88  changed
SEG104.dis near =  0  far = 80  changed
SEG105.dis near =  1  far = 27  changed
SEG106.dis near =  0  far = 126  changed
SEG107.dis near =  0  far = 57  changed
SEG108.dis near =  0  far = 85  changed
SEG109.dis near =  4  far = 147  changed
SEG110.dis near =  4  far = 166  changed
SEG111.dis near =  0  far = 152  changed
SEG112.dis near =  3  far = 125  changed
SEG113.dis near =  3  far = 163  changed
SEG114.dis near =  0  far = 159  changed
SEG115.dis near =  0  far = 152  changed
SEG116.dis near =  0  far = 171  changed
SEG117.dis near =  0  far = 174  changed
SEG118.dis near =  0  far = 117  changed
SEG119.dis near =  0  far = 74  changed
SEG120.dis near =  1  far = 178  changed
SEG121.dis near =  0  far = 40  changed
SEG122.dis
Der Fehler "IndexError: list index out of range" ist vermutlich nicht so gewollt.

Und das Compilieren geht auch nicht, leider. Auskommentieren der seg038-Zeile in compile.bat und anschließendes Ausführen von tools/bc.sh liefert

Code:
seg038.cpp
Error seg038.cpp 13: Unable to open include file 'string.h'
Error v302de.h 12: Unable to open include file 'stdlib.h'
Error v302de.h 973: Unable to open include file 'DOS.H'
[...]
Anscheinend findet er die Bibliotheks-Dateien nicht. Unter src/custom/drive_c/BORLANDC/INCLUDE gäbe es bei mir die Dateien STDIO.H, STDLIB.H und DOS.H.

Hast du zufällig noch eine Idee, wie ich weiterkommen könnte? Ich würde wirklich gerne kontrollieren, wie viel ich mit meinen ganzen Änderungen mittlerweile kaputt gemacht habe.

RE: Reverse Engineering der NLT II - gaor - 09.02.2021

Also ich habe das jetzt auch nur aus dem Gedächtnis und aus den verlinkten Beiträgen rekonstruiert. Ich kann das Skript disassemble.sh auch auf meinem aktuellen System nicht ausführen, weil nc2fc.py in Python Version 2 geschrieben ist, und mein System (Fedora) unterstützt kein Python 2 mehr. Deswegen kann ich dir jetzt so auf die schnelle leider keine Hilfestellung leisten. Vielleicht finde ich am Wochenende Zeit.

RE: Reverse Engineering der NLT II - wiese.hano - 09.02.2021

Wenn ihr das hinbekommt, werde ich es auf jeden Fall auch durchexerzieren.

RE: Reverse Engineering der NLT II - siebenstreich - 10.02.2021

(09.02.2021, 20:22)gaor schrieb: Also ich habe das jetzt auch nur aus dem Gedächtnis und aus den verlinkten Beiträgen rekonstruiert. Ich kann das Skript disassemble.sh auch auf meinem aktuellen System nicht ausführen, weil nc2fc.py in Python Version 2 geschrieben ist, und mein System (Fedora) unterstützt kein Python 2 mehr. Deswegen kann ich dir jetzt so auf die schnelle leider keine Hilfestellung leisten. Vielleicht finde ich am Wochenende Zeit.

Vielen Dank, das wäre wirklich sehr nett! Ich habe gerade nochmal alle Schritte durchgeführt, ausgehend von einer frischen Kopie der letzten BrightEyes-Version von Henne. Auch die SCHICKM.EXE hab ich nochmal von meiner originalen CD gezogen. Die beiden Fehler bleiben, leider. Was könnte die Ursache sein? Bei disassemble.sh könnte es sein, dass neuere Versionen von ndisasm bzw. Python-Modulen etwas anderes produzieren als die damaligen Versionen, mit denen das Skript von Henne geschrieben wurde. Und bei tools/bc.sh könnte es sein, dass in der Archive-Version des Borland Compilers Sachen fehlen oder anders aufgebaut sind.

Die Python 2 vs. Python 3 Problematik ist ein ewiges Ärgernis. Ich musste mich auch wieder damit herumschlagen, um disassemble.sh zum Laufen zu bringen. Bei mir ist ein Ubuntu am Laufen, wo es glücklicherweise keine grundlegenden Probleme mit Python 2 gibt. Gelernt habe ich dabei auch, dass es in Ubuntu neuerdings zwei (sich gegenseitig ausschließende) Pakete namens python-is-python2 und python-is-python3 gibt, die einen Link unter /usr/bin anlegen, so dass der Befehl python dann python2 bzw. python3 aufruft.

RE: Reverse Engineering der NLT II - Rabenaas - 10.02.2021

(09.02.2021, 20:22)gaor schrieb: Ich kann das Skript disassemble.sh auch auf meinem aktuellen System nicht ausführen, weil nc2fc.py in Python Version 2 geschrieben ist, und mein System (Fedora) unterstützt kein Python 2 mehr.
Könnt ihr mir einen Beispielinput für nc2fc.py geben? Ich habe das nach Python3 umgeschrieben, aber noch nicht getestet.

RE: Reverse Engineering der NLT II - gaor - 12.02.2021

So, ich hab das Problem mit der disassemble.sh gelöst. Edit: Siehe mein nächster Beitrag für den Fix.

@Rabenaas: Danke für das Übersetzen in Python 3. Du hast auch noch ein bisschen Code-Linting betrieben, sehr löblich. Edit: Siehe mein nächster Beitrag für den passenden Pull Request.

RE: Reverse Engineering der NLT II - gaor - 12.02.2021

@siebenstreich: Dein Problem mit der bc.sh kann ich nicht reproduzieren. Hier habe ich mal alle Dateien in BORLANDC aufgelistet, dann kannst du vergleichen ob in deiner Version vielleicht Dateien fehlen: https://paste.eccologic.net/?5cfda88c19fdc8a4#5hVvEUv21eAa3GQbV4XoWEackSKjZcobLpfhVcUZofJi

@siebenstreich: Ich habe einen Pull Request erstellt für die Unterstützung von Python 3 und neuere nasm-Versionen, dann braucht man auch keine conda-Umgebungen und solchen Kram: https://github.com/siebenstreich/Bright-Eyes/pull/1 Würdest du das bitte mergen? Ich würde sowieso vorschlagen, dass wir jetzt erstmal mit deinem Fork weiterarbeiten, solange Henne nicht erreichbar ist.

RE: Reverse Engineering der NLT II - siebenstreich - 13.02.2021

goar: Danke für den pull request! Ich habe das übernommen. Wobei ich die Sachen nach wie vor natürlich am liebsten im originalen BrightEyes drin sähe. Aber da dort Funkstille ist, ist die nächstbeste Variante natürlich, zumindest an nur einem Fork rumzuschrauben.

./disassemble.sh geht jetzt, danke auch an Rabenaas!

Du hast ja noch weitere Sachen geändert. Für die Wiederherstellung der Binäräquivalenz in seg068.cpp bin ich froh. Darf ich daraus schließen, dass ich sonst nirgends etwas kaputt gemacht habe? Darauf hätte ich nicht viel getippt.

Etwas ärgerlich finde ich es schon, dass wir anstelle von
Code:
for (item_pos = cursed_hero_pos = 0; item_pos <= 6; item_pos++, hero += SIZEOF_HERO) {
nicht
Code:
cursed_hero_pos = 0;
for (item_pos = 0; item_pos <= 6; item_pos++, hero += SIZEOF_HERO) {
schreiben dürfen. Ich kann nicht recht glauben, dass die Attic-Programmierer das damals so geschrieben haben. Gibt es (im Rahmen der Binäräquivalenz) wirklich keine Möglichkeit, diese geschachtelten Zuweisungen besser lesbar zu machen?

Deine ITEM-Umbenennungen sind gut für die Lesbarkeit. Eine Sache dazu: Teilweise waren und sind diese Bezeichner auf Englisch ("ITEM_WHIRLWEED"), teils auf Deutsch ("ITEM_LOBPREISUNGEN"), oder sogar ein Mischmasch "ITEM_ANGST_POISON". Nachdem es ja die deutschsprachige Version ist, die hier nachkonstruiert wird, würde ich am liebsten die Gegenstände konsequent nach dem deutschen Namen im Spiel benennen. Also z.B. "ITEM_WIRSELKRAUT" oder "ITEM_ANGSTGIFT". Ansonsten müsste man ja eigentlich in der englischen Version nachschauen, wie die ganzen Gegenstände dort korrekt heißen, was auch irgendwie albern wäre.

RE: Reverse Engineering der NLT II - siebenstreich - 13.02.2021

@gaor:
Das Problem mit tools/bc.sh besteht unverändert weiter, leider. Ich habe deine Dateiliste stichpunktartig verglichen, und konnte keine Unterschiede feststellen.
Womit hast du diese Liste erzeugt? Dann könnte ich das auch machen und direkt die Listen vergleichen.

Noch eine Bitte: Könntest du das Skript tools/bc.sh vielleicht mal testweise mit der oben verlinkten archive-Version des BCC ausprobieren?

RE: Reverse Engineering der NLT II - gaor - 14.02.2021

(13.02.2021, 22:58)siebenstreich schrieb: Du hast ja noch weitere Sachen geändert. Für die Wiederherstellung der Binäräquivalenz in seg068.cpp bin ich froh. Darf ich daraus schließen, dass ich sonst nirgends etwas kaputt gemacht habe? Darauf hätte ich nicht viel getippt.
Ja, sieht so aus als wäre das das einzige Problem.

(13.02.2021, 22:58)siebenstreich schrieb: Ich kann nicht recht glauben, dass die Attic-Programmierer das damals so geschrieben haben. Gibt es (im Rahmen der Binäräquivalenz) wirklich keine Möglichkeit, diese geschachtelten Zuweisungen besser lesbar zu machen?
Ich halte es nicht für so abwegig, dass die Attic-Programmierer das so geschrieben haben. Aber es kann auch sein, dass es anders geschrieben werden kann, ohne die Binäräquivalenz zu zerstören.

Ich habe mir die Version von BCC 3.1 angeschaut, die auf Archive liegt. Da fehlt anscheinend das "Application Framework". Das gibt es beispielsweise hier: https://winworldpc.com/product/borland-c/30

RE: Reverse Engineering der NLT II - siebenstreich - 15.02.2021

(14.02.2021, 14:45)gaor schrieb: Ich habe mir die Version von BCC 3.1 angeschaut, die auf Archive liegt. Da fehlt anscheinend das "Application Framework". Das gibt es beispielsweise hier: https://winworldpc.com/product/borland-c/30

Vielen Dank! Damit scheint es jetzt zu klappen.

Anleitung: Unter dem winworldpc-Link "Borland CPP 3.1 and Application Frameworks (1992) (3.5-1.44mb)" herunterladen. Dann alle Diskettenimages der Reihe nach einzeln mounten und die darin enthaltenen Dateien in ein Verzeichnis <all_disks> kopieren (die Dateien von den verschiedenen Disketten landen also alle im selben Verzeichnis). Außerdem ein Verzeichnis <install> anlegen. Dann Dosbox starten,

Code:
mount a <all_disks>
mount c <install>
a:
install

In dem Installer unter "Windows Options" alles abwählen, dann "Start Installation".

Danach liegt unter <install> das benötigte Verzeichnis BORLANDC mit Compiler, Bibliotheken etc.

RE: Reverse Engineering der NLT II - gaor - 15.02.2021

Super! Unsere Erkenntnisse zum Developer-Setup würden doch ein gutes README-Dokument abgeben, das du in deinen Fork aufnehmen könntest, findest du nicht? Das war lange schon überfällig. Hier im Forum altern derlei Infos und HowTos leider nicht besonders gut, sondern verschwinden allmählich im Nirvana der Thread-Historie.

RE: Reverse Engineering der NLT II - siebenstreich - 20.02.2021

Ja, das ist eine gute Idee. Ich habe in der README.brighteyes bei mir ein paar Zeilen geschrieben.

Allerdings springt ja jetzt beim commit dieser pre-commit-hook an, der mit BCC testen will ob alles passt.
Und dabei bekomme ich jetzt folgende Fehlermeldung:

Code:
wc: <path>/src/custom/schick/rewrite_m302de/temp/disasm_orig/SEG013.dis: No such file or directory
head: invalid number of lines: ‘<path>/src/custom/schick/rewrite_m302de/temp/disasm/SEG013.dis’
REPORT 110 Files: Good = 110 Fail = 0
Fehler: 110 Dateien wurden geprueft, aber es sollten 111 sein
Good files were broken

Beim genaueren Hinschauen fällt auf, dass in der disassemble.sh die Dateien SEG012.dis bis SEG023.dis nicht erzeugt werden. Das ist auch in der letzten Henne-Version von BrightEyes schon so, wir haben also nichts kaputtgemacht. Nachdem der BCC-commit-Test bei dir ja offenbar durchgelaufen ist, gaor: Könntest du mir hier nochmal helfen?

RE: Reverse Engineering der NLT II - gaor - 20.02.2021

Du hast in der SEG043 einige Aufrufe von D1_INFO hinzugefügt, ohne "#if !defined(__BORLANDC__)", deswegen schlägt die BCC-Kompilation von seg043.cpp fehl. Zugegebenermaßen ist die Fehlerausgabe des Hook-Skripts bc_ready.sh nicht besonders hilfreich. Ich habe einen Pull Request erstellt, der die Ausgabe etwas verbessert und seg043.cpp korrigiert: https://github.com/siebenstreich/Bright-Eyes/pull/2

RE: Reverse Engineering der NLT II - siebenstreich - 20.02.2021

Vielen Dank!

Ich schaue mir das später genauer an, wenn ich Zeit habe. Nur kurz:

Wäre es nicht besser, das
Code:
#if !defined(__BORLANDC__)
in das Makro D1_INFO mit hineinzuverpacken?

Und dass in disassemble.sh SEG012 bis SEG023 fehlen, ist wohl tatsächlich korrekt so?

Bitte vorerst keinen größeren Commit machen, bei ist nämlich noch was in der Warteschlange...

RE: Reverse Engineering der NLT II - gaor - 20.02.2021

D1_INFO ist ein Makro mit Variadic-Argument, also mit einer Variablen Anzahl an Argumenten: D1_INFO(...) Diese Art von Makro wird von BCC 3.1 nicht unterstützt: http://www.bitsavers.org/pdf/borland/borland_C++/Borland_C++_Version_3.1_Programmers_Guide_1992.pdf Es gäbe die Möglichkeit, D1_INFO als eine richtige Funktion zu definieren, die nichts tut:
Code:
static inline void D1_INFO(...) { }
Aber leider ignoriert das der BCC-Compiler nicht, sondern baut da tatsächlich einen function call ein, der dann die Binärkompatibilität zerstört.

Also, wenn du eine elegante Möglichkeit siehst, D1_INFO in BCC zu definieren, ohne die Binärkompatibilität zu zerstören, dann los. Ansonsten muss es bei dem umständlichen #if !defined(__BORLANDC__) bleiben.

Tja, zu den fehlenden SEG012 bis SEG023 kann ich nichts sagen, aber das wird schon Absicht sein, vermute ich.

RE: Reverse Engineering der NLT II - siebenstreich - 20.02.2021

Danke für die Erklärung zu D1_INFO, das ist einleuchtend (und ein wenig ärgerlich). Also hilft es wohl nichts, das "#if !defined(__BORLANDC__)" muss jedes mal hin.

Zu dem commit-hook: Ich kriege jetzt die von dir geänderte Meldung "Warnung: SEG013 is nicht im Disassembly der Original-EXE."
Für mich klingt das so, wie wenn der Verlust der Binärkompatibilität in seg013.cpp nicht überprüft wird (und ich vermute ähnliches für seg014.cpp bis seg023.cpp). Das kann doch nicht so gewollt sein?

Mein commit ist durch. Ich habe u.a. den Rechtschreibfehler 'heros' zu 'heroes' korrigiert, das betraf recht viele Dateien.

RE: Reverse Engineering der NLT II - gaor - 20.02.2021

Doch, es kann schon sein, dass 13 bis 23 keinen richtigen Code enthalten. In der bc_ready.sh steht was von BSS, und das würde dann bedeuten, dass die hauptsächlich aus 0 bestehen: https://de.wikipedia.org/wiki/Datensegment#BSS Also ich würde mich darum jetzt erstmal nicht kümmern.

RE: Reverse Engineering der NLT II - siebenstreich - 20.02.2021

Ich denke, du hast recht. Ich hätte auch erst mal richtig schauen sollen: seg012.cpp bis seg023.cpp gibt es ja gar nicht. Die einzigen Dateien in diesem Bereich sind seg013.h und seg013.asm. (evtl. kommt daher die Warnung über SEG013).

RE: Reverse Engineering der NLT II - siebenstreich - 25.02.2021

gaor, ein kleines Rätsel für dich: Warum liefert 'make' einen Fehler, wenn ich diesen Kommentarblock "einkommentiere"? Ich verstehe es nicht.

In diesem Zusammenhang noch was: Spricht etwas was dagegen, assert.h einzubinden und sowas in assert(...) reinzusetzen? Die entsrpechenden Codestellen müssen natürlich durch eine Präprozessor-Variable abschaltbar sein, damit der BCC davon nichts mitbekommt.