+- 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)
RE: Reverse Engineering der NLT II - wiese.hano - 08.07.2018
Basiert das BrightEyes-Wiki eigentlich auf MediaWiki oder DokuWiki?
RE: Reverse Engineering der NLT II - Crystal - 08.07.2018
MediaWiki.
RE: Reverse Engineering der NLT II - Obi-Wahn - 08.07.2018
Jap, genau. MediaWiki. Ich hatte mal eine Umwandlung angedacht, es aber letztlich nicht durchgezogen. Die Abschaltung ist jederzeit wieder umkehrbar, ich habe es nur gemacht, weil das Interesse im Moment kaum vorhanden ist und ich im Moment keine Zeit / keinen Nerv habe, um mich um das Monster "MediaWiki" zu kümmern.
Hab schon mit Wordpress genug zu kämpfen. Würde da gerne umsteigen auf Flat-File-Content-Management-System wie Bludit. Aber inzwischen gibt es dann doch zu viele Verlinkungen im Web....
RE: Reverse Engineering der NLT II - NewProggie - 12.07.2019
Hier haben ein paar Leute Super Mario 64 aus dekompilierten Assembly wieder den originalen Sourcecode zusammengesetzt:
https://gbatemp.net/threads/super-mario-64-has-been-decompiled.542918/
Vom Vorgehen ziemlich ähnlich zum Reverse Engineering (halt ohne Dosbox als Hilfe). Da hab ich mich gerade gefragt, wie denn
hier der aktuelle Stand ist des Projekts? Meine letzte Info war, dass im Prinzip Binärkompatibilität erreicht wurde?
RE: Reverse Engineering der NLT II - gaor - 12.07.2019
Wenn man nach dem Plan von Henne geht, sind wir quasi fertig mit der "Phase 2": https://www.crystals-dsa-foren.de/showthread.php?tid=700&pid=151277#pid151277 Das bedeutet: Wenn wir den Code mit dem Original-Compiler von damals kompilieren, kommt eine Binary raus, die sich nur unwesentlich von der Original-Binary unterscheidet. Streng genommen gibt es noch 5 Funktionen, die sich in einzelnen Bytes vom Originalcode unterscheiden: https://www.crystals-dsa-foren.de/showthread.php?tid=700&pid=151240#pid151240 Außerdem ist die resultierende EXE-Datei nicht richtig gelinkt. Ich kenne mich mit solchem Linker-Gedöns nicht aus und weiß nicht, wie trivial hier die Änderungen sein müssten, kann mir aber nicht vorstellen, dass das allzu aufwendig ist. Wir sind also an einem ähnlichen Punkt wie die SuperMario64-Community, vielleicht sogar etwas weiter, weil wir schon einen sehr großen Teil der Funktionen und Variablen mit sinnvollen Namen versehen konnten. Interessant wäre eigentlich auch, eine minimale Variante vom Original-Code zu haben, die mit modernen C-Compilern auf modernen Plattformen lauffähig wird. Und davon sind wir noch weit entfernt. Genauso wie von einer leicht modbaren Variante.
RE: Reverse Engineering der NLT II - wiese.hano - 12.07.2019
Wie war eigentlich der Weg, hin, zu einem Code-Stand mit kryptischen Methodennamen? Was musste man dafür tun?
RE: Reverse Engineering der NLT II - gaor - 12.07.2019
Als ich hier eingestiegen bin, war das Projekt schon enorm weit fortgeschritten. Wie alles begonnen hat, ist hier dokumentiert: https://chemnitzer.linux-tage.de/2011/vortraege/591 Es wurde also ein Disassembler benutzt, der bereits in der Lage war, C-Code zu generieren (IDA). Wenn ich das richtig verstehe, waren dann aber immer noch Anpassungen per Hand notwendig. Dieser Quellcode wurde zunächst (für einzelne Funktionen) in DosBox "reinkompiliert". Irgendwann hatte man aber auch die Originalversion des ursprünglich benutzten Borland-C++-Compilers aufgetrieben und konnte dann auch Compiler-spezifische Assembler-Optimierungen so berücksichtigen, dass auch wirkliche Binärkompatibilität für einzelne Funktionen erreicht wurde.
Bis heute sind noch in 5 Funktionen Compiler-spezifische Abweichungen im Assembler zu erkennen. Ich hab da schonmal reingeschaut und es geht da wirklich darum, dass der Compiler irgendwelche Codeabschnitte äquivalent umsortiert, aber eben nicht so äquivalent, wie das in der Originalversion war. Ich kam mit meinen bescheidenen C-Kenntnissen nicht dahinter, was der Compiler da genau tut und wie man den C-Code umstellen müsste, damit er das richtige Ergebnis ausspuckt.
EDIT: Hier sind die IDA-Dateien, in die wohl auch über die Jahre Dinge reinkommentiert wurden: https://github.com/Henne/BrightEyes-reveng
RE: Reverse Engineering der NLT II - Obi-Wahn - 12.07.2019
Henne hat sich leider seit 2 Jahre nicht gemeldet, daher erwarte ich momentan keine weitere Entwicklung von seiner Seite.
RE: Reverse Engineering der NLT II - Obi-Wahn - 19.07.2019
Juhu!! https://github.com/Henne/Bright-Eyes/issues/49#issuecomment-513164365
RE: Reverse Engineering der NLT II - Shihan - 24.07.2019
Er lebt noch
Aber hatte er nicht gesagt, dass ihn das RL extrem im Griff hat und demnach keine Zeit für NLT ist?
(Übrigens auch mein Problem)
RE: Reverse Engineering der NLT II - wiese.hano - 30.08.2019
(19.07.2019, 22:05)Obi-Wahn schrieb: Juhu!! https://github.com/Henne/Bright-Eyes/issues/49#issuecomment-513164365Na das finde ich doch mal sehr interessant. Ich habe mich immer gefragt, wie ihr dieses Reverse-Engineering angeht; jetzt verstehe ich das etwas besser. Wäre für mich aber immer noch zu kompliziert, das selbst zu tun. Ist ja nun, mit Blick auf den Stand des Projekts, nicht mehr nötig. In Abhängigkeit von eurer Zeit hoffe ich, dass ihr bald weiterkommt, mit den paar Funktionien, die noch "aus der Reihe tanzen".
RE: Reverse Engineering der NLT II - Obi-Wahn - 16.03.2020
Das BrightEyes-Wiki ist jetzt offline. Eines der letzten Updates hat leider dutzende Seiten geleert, so dass das Wiki jetzt ziemlich leer ist. Ich habe noch ein altes Backup, aber ich beabsichtige nicht, dass Wiki wieder einzurichten.
RE: Reverse Engineering der NLT II - Rabenaas - 16.03.2020
Schade. Wäre vielleicht irgend wann mal eine Hardcopy im PDF-Format möglich?
RE: Reverse Engineering der NLT II - aeyol - 16.03.2020
Finde ich auch schade. Wäre es möglich, das bei git mit abzuladen? So entstünden keine Kosten und man müsste das auch nicht weiter pflegen, wenn man keine Zeit hat?
RE: Reverse Engineering der NLT II - Obi-Wahn - 16.03.2020
Wenn du Interesse hast, kann ich dir ein Inhalts-Dump von 2017 zu kommen lassen. Das Datenbank-Backup ist von Mitte 2019, müsste ich nur mal lokal aufsetzen und dann einen Inhalts-Dump machen. Viel hat sich in den letzem zwei Jahren eh nicht getan.
RE: Reverse Engineering der NLT II - Obi-Wahn - 16.03.2020
(16.03.2020, 13:12)aeyol schrieb: Finde ich auch schade. Wäre es möglich, das bei git mit abzuladen? So entstünden keine Kosten und man müsste das auch nicht weiter pflegen, wenn man keine Zeit hat?
Hmm, das sieht interessant aus. Da gibt es wohl Möglichkeiten:
https://doc.itc.rwth-aachen.de/display/SES/Migration+MediaWiki+zu+Gitlab+Wiki
RE: Reverse Engineering der NLT II - Shihan - 17.03.2020
Hatte noch einen Dump vom 11.06.2018. Den habe ich mal auf Github eingestellt: https://github.com/shihan42/BrightEyesWiki/wiki
Github kann MediaWiki lesen, allerdings sind eventuell ein paar Fehler mit dabei. Habe die gröbsten Sachen, die mir beim Import aufgefallen sind, korrigiert. Gibt noch einige Redlinks, allerdings sind das auch oft Weiterleitungen, die ich nicht mit importiert habe.
Wenn jemand Korrekturen hat: Einfach Bescheid geben!
RE: Reverse Engineering der NLT II - Obi-Wahn - 17.03.2020
Hey, super! Danke! Seit 2018 hat sich imho nichts getan. Darf ich den Link in meinem BrightEyes-Download-Thema reinpacken?
RE: Reverse Engineering der NLT II - Shihan - 17.03.2020
Aber natürlich, dafür ist er da
RE: Reverse Engineering der NLT II - siebenstreich - 17.01.2021
Im Rahmen der Fehlersuche für den Patch habe ich mir eine lokale Kopie von Bright Eyes angelegt und darin -- hauptsächlich in seg038.cpp -- Variablen umbenannt und Bugfixes eingebaut. Es wäre schön, die Erkenntnisse wieder im offiziellen Bright Eyes drinzuhaben. Deswegen habe ich einen Pull Request erstellt.
Meine Fragen:
1) Gibt es die Aussicht, dass der Pull Request angenommen wird? Passiert hier noch etwas?
2) Vermutlich habe ich sämtliche Konventionen verletzt. Ich bin aber lernwillig und würde mich über kritische Rückmeldungen freuen.
3) Seit dem letzten Commit läuft 'make' nicht mehr durch, und ich verstehe nicht so recht warum. Eine richtige Fehlermeldung sehe ich nicht. Kann mir hier jemand helfen? Die letzten Ausgabezeilen lauten
Code:
In file included from seg002.cpp:26:
datseg.cpp:50:23: warning: ‘M302de::g_weapons_table’ defined but not used [-Wunused-variable]
50 | struct{char unkn[7];} g_weapons_table[65] = { { 0x01, 0x04, 0x0e, 0x02, -0x01, 0x00, 0x00 }, { 0x01, 0x01, 0x0e, 0x06, -0x01, -0x01, -0x03 }, { 0x01, 0x03, 0x0f, 0x02, -0x01, 0x00, 0x00 }, { 0x01, 0x00, 0x10, 0x04, -0x01, -0x03, -0x04 }, { 0x01, 0x03, 0x63, 0x05, 0x01, 0x00, -0x03 }, { 0x01, 0x02, 0x0f, 0x01, -0x01, 0x00, -1 }, { 0x01, 0x04, 0x0e, 0x05, -0x01, 0x00, -0x03 }, { 0x01, 0x03, 0x63, 0x00, 0x03, 0x00, 0x00 }, { 0x02, 0x04, 0x0e, 0x03, -0x01, -0x01, -0x04 }, { 0x01, 0x06, 0x63, 0x00, 0x05, 0x00, 0x00 }, { 0x01, 0x01, 0x0f, 0x03, -0x01, -0x02, -0x03 }, { 0x01, 0x03, 0x63, 0x04, 0x02, -0x01, -0x03 }, { 0x01, 0x01, 0x63, 0x00, 0x00, 0x00, 0x00 }, { 0x02, 0x04, 0x0e, 0x03, -0x01, -0x02, -0x03 }, { 0x01, 0x04, 0x63, 0x00, 0x04, 0x00, 0x00 }, { 0x01, 0x05, 0x0f, 0x05, -0x01, -0x01, -0x03 }, { 0x01, 0x00, 0x10, 0x06, -0x01, -0x02, -0x03 }, { 0x01, 0x03, 0x63, 0x04, 0x02, -0x01, -0x04 }, { 0x01, 0x03, 0x13, 0x07, -0x01, -0x01, -0x04 }, { 0x01, 0x04, 0x0d, 0x01, -0x01, 0x00, -0x02 }, { 0x01, 0x03, 0x10, 0x03, -0x01, 0x00, -1 }, { 0x01, 0x03, 0x10, 0x03, -0x01, 0x00, -1 }, { 0x01, 0x01, 0x0f, 0x05, -0x01, 0x00, -1 }, { 0x01, 0x00, 0x13, 0x02, -0x01, 0x00, -0x06 }, { 0x01, 0x00, 0x63, 0x04, 0x00, -0x03, -0x04 }, { 0x01, 0x02, 0x11, 0x05, -0x01, -0x03, -0x04 }, { 0x01, 0x03, 0x11, 0x06, -0x01, -0x03, -0x04 }, { 0x02, 0x03, 0x0f, 0x02, -0x01, -0x02, -0x04 }, { 0x01, 0x03, 0x0f, 0x03, -0x01, 0x00, -0x03 }, { 0x01, 0x04, 0x0f, 0x05, -0x01, -0x01, -0x03 }, { 0x01, 0x02, 0x0d, 0x06, -0x01, -0x02, -0x03 }, { 0x01, 0x03, 0x12, 0x04, -0x01, -0x01, -1 }, { 0x03, 0x03, 0x11, 0x04, -0x01, -0x03, -0x04 }, { 0x01, 0x01, 0x10, 0x04, -0x01, -0x02, -0x03 }, { 0x01, 0x02, 0x0f, 0x04, -0x01, -0x02, -0x03 }, { 0x01, 0x01, 0x10, 0x07, -0x01, -0x03, -0x04 }, { 0x01, 0x02, 0x0f, 0x02, -0x01, -0x01, -0x02 }, { 0x02, 0x02, 0x0f, 0x03, -0x01, -0x02, -0x02 }, { 0x01, 0x03, 0x0f, 0x02, -0x01, 0x00, -1 }, { 0x01, 0x05, 0x0e, 0x02, -0x01, -0x01, -0x02 }, { 0x01, 0x06, 0x0f, 0x01, -0x01, -0x02, -0x02 }, { 0x01, 0x04, 0x10, 0x03, -0x01, -0x01, -0x03 }, { 0x01, 0x05, 0x0e, 0x01, -0x01, -0x01, -0x02 }, { 0x01, 0x03, 0x10, 0x04, -0x01, 0x00, -1 }, { 0x01, 0x04, 0x0e, 0x02, -0x01, 0x00, -1 }, { 0x01, 0x06, 0x0f, 0x03, -0x01, -0x01, -0x03 }, { 0x01, 0x02, 0x63, 0x00, 0x01, 0x00, 0x00 }, { 0x01, 0x03, 0x0d, 0x04, -0x01, 0x00, -0x02 }, { 0x01, 0x04, 0x0d, 0x02, -0x01, -0x02, -0x04 }, { 0x01, 0x05, 0x0e, 0x02, -0x01, -0x01, -0x03 }, { 0x01, 0x04, 0x63, 0x00, -0x01, 0x00, 0x00 }, { 0x01, 0x03, 0x0f, 0x02, -0x01, 0x00, 0x00 }, { 0x01, 0x03, 0x0f, 0x02, -0x01, 0x00, -1 }, { 0x00, 0x00, 0x63, 0x00, -0x01, 0x00, 0x00 }, { 0x01, 0x05, 0x0e, -0x05, -0x01, -0x02, -0x03 }, { 0x01, 0x0a, 0x0e, -0x63, -0x01, -0x02, -0x08 }, { 0x01, 0x02, 0x0f, -0x63, -0x01, 0x02, -1 }, { 0x01, 0x03, 0x0f, 0x00, -0x01, 0x00, 0x00 }, { 0x02, 0x04, 0x0e, -0x63, -0x01, -0x03, -0x04 }, { 0x01, 0x04, 0x0e, -0x63, -0x01, 0x02, 0x02 }, { 0x01, 0x04, 0x0e, 0x00, -0x01, 0x02, 0x00 }, { 0x01, 0x03, 0x63, 0x05, 0x06, 0x01, 0x01 }, { 0x01, 0x00, 0x63, 0x04, 0x07, -0x03, -0x04 }, { 0x01, 0x01, 0x0f, -0x63, -0x01, 0x00, 0x00 }, { -0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 } }; // ds:0x06b0
| ^~~~~~~~~~~~~~~
In file included from seg002.cpp:26:
datseg.cpp:49:23: warning: ‘M302de::g_ranged_weapons_table’ defined but not used [-Wunused-variable]
49 | struct{char unkn[8];} g_ranged_weapons_table[9] = { { 0x01, 0x00, 0x00, -0x01, -0x63, -0x63, -0x63, 0x06 }, { 0x01, 0x01, 0x00, 0x00, -0x01, -0x63, -0x63, 0x06 }, { 0x02, 0x01, 0x00, 0x00, 0x00, -0x63, -0x63, 0x07 }, { 0x01, 0x01, 0x00, 0x00, 0x00, -0x01, -0x63, 0x04 }, { 0x02, 0x02, 0x01, 0x00, 0x00, -0x01, -0x02, 0x04 }, { 0x02, 0x02, 0x01, 0x00, -0x01, -0x02, -0x03, 0x03 }, { 0x02, 0x02, 0x01, 0x01, 0x00, 0x00, -0x01, 0x04 }, { 0x09, 0x09, 0x09, 0x09, 0x09, 0x09, 0x09, 0x02 }, { -0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 } }; // ds:0x0668
| ^~~~~~~~~~~~~~~~~~~~~~
In file included from seg002.cpp:20:
../../../../include/dos_inc.h:641:14: warning: ‘Bit8u RealHandle(Bit16u)’ defined but not used [-Wunused-function]
641 | static Bit8u RealHandle(Bit16u handle) {
| ^~~~~~~~~~
make[6]: *** [Makefile:714: seg002.o] Error 1
make[6]: *** Waiting for unfinished jobs....
mv -f .deps/seg004.Tpo .deps/seg004.Po
mv -f .deps/seg006.Tpo .deps/seg006.Po
mv -f .deps/seg005.Tpo .deps/seg005.Po
make[6]: Leaving directory '/<...>/Bright Eyes/git_branch/src/custom/schick/rewrite_m302de'
make[5]: *** [Makefile:734: all-recursive] Error 1
make[5]: Leaving directory '/<...>/Bright Eyes/git_branch/src/custom/schick/rewrite_m302de'
make[4]: *** [Makefile:411: all-recursive] Error 1
make[4]: Leaving directory '/<...>/Bright Eyes/git_branch/src/custom/schick'
make[3]: *** [Makefile:413: all-recursive] Error 1
make[3]: Leaving directory '/<...>/Bright Eyes/git_branch/src/custom'
make[2]: *** [Makefile:448: all-recursive] Error 1
make[2]: Leaving directory '/<...>/Bright Eyes/git_branch/src'
make[1]: *** [Makefile:377: all-recursive] Error 1
make[1]: Leaving directory '/<...>/Bright Eyes/git_branch'