Reverse Engineering der NLT II

[HenneNWH]

Das kann ich mir vorstellen:
Aktuell bin ich dabei den Bereich in welchem sich die Daten für den allgemeine Spielstand befinden so zu überarbeiten dass er auf aktuellen Systemen funktioniert
und versuche ihn aufwärtskompatibel zu gestalten.
D.h. es soll mit BrightEyes möglich sein ältere DOS-Spielstände weiterzuspielen.
Die erwähnten Probleme mit Zeigern im Spielstand habe ich schon so vorbereitet,
dass nur noch zwei Problembereiche zu klären und zu beheben sind:
* Der Held welcher mit dem Einhorn kommuniziert muss anders definiert werden (Zeiger und/oder Position können nicht funktionieren).
* Die Hafenoptionen, welche vermutlich die aktuell buchbaren Schiffspassagen enthalten, leiden unter ähnlichen Problemen.

Es sind noch eine Reihe von Reiseevent-Flags zu verdrahten.

Weiterhin sind noch ein paar Flags ausfindig zu machen, welche bisher nicht im Spielstand gespeichert wurden.
Diese können durch Speichern und Neuladen beliebig oft wiederholt werden.

Es gibt in der Wolfshöhle einen Müllhaufen, welche bei Durchsuchen 2 Silberstücke und einen CH-Malus von -5 für einen Tag einbringen.
Dieses Event ist so ein Kandidat.

Dieser Schritt ist möglicherweise am Sonntag vorbereitend abgeschlossen.

Dann sind noch die Charakterbögen für die Feinde in den Kämpfen in Form zu bringen.
Wenn das erledigt ist kann ich endlich die arithmetischen und logischen Operatoren (+=, &=, ...) auf Daten aus dem Datensegment
aus BrightEyes entfernen und somit einige DOSBox-Altlasten loswerden. 
Namentlich: add_ds_bs(), add_ds_ws(), ...

Lese- und Schreiboperationen und der Zeiger p_datseg bleiben noch ein Weilchen,
aber deren Lebenszeit nähert sich mit Fortschreiten meiner Arbeit dem Ende.

[NewProggie]

Ich hab gerade mal meinen PR mit dem CI-Job aktualisiert (https://github.com/Henne/BrightEyes/pull/15/). Wollen wir den mal upstream mergen @Henne

[HenneNWH]

@NewProggie: Generell bin ich dem was du vorbereitet hast sehr positiv gegenüber eingestellt, habe allerdings noch ein paar Fragen. (Meeting)

@Ilm: Danke für das CMake-HowTo. Aktuell ist CMake für mich absolute Nebensache, da OutOfTree-Builds mich im Moment eher bei der Arbeit behindern würden.
Wenn Schick in dem Zustand wie gen ist, ist CMake the WayToGo!

Das Meeting kann meiner Meinung nach in ca. 3 Wochen stattfinden.

Zwischenstand:
* Binäräquivalenzcodedifferenz = 3929 Bytes (Änderungen außerhalb des ausführbaren Codes, was genau ist noch unklar [vermutlich Overlays])
* auskommentierte Zeilen in der symbols.h = 83.2 %
* es kompilieren auch schon einige Dateien (90 / 112) mit dem GCC

Wesentliche Änderungen:
* Die Datenstruktur enemy_sheets ist jetzt so verbaut wie sie soll. In dieser werden die "Charakterbogen" der Kampfgegner während der Kämpfe gespeichert.
   Die vorherige Variante mit Pointern und Enums existiert jetzt nicht mehr.
   Auch die 4 verschiedenen Varianten diese Daten zu ändern wurden vereinheitlicht,
   was es mir anschließen ermöglicht hat die zwei Flag-Bytes zu einem Flag-Word zusammenzufassen. (Danke an Siebenstreich für den Tip!)

   Diese Datenstruktur zieht sich durch folgende Bereiche: Kampfsystem, Kampfanimationen, Zaubersprüche.
   Das wird nur noch durch die Datenstruktur der Helden getoppt, welche sich quer durch das ganze Spiel zieht.
   Alles andere sollte nach der Vorarbeit am Charaktergenerator "NGen" ein relativer Spaziergang werden.

[llm]

@NewProggie: Generell bin ich dem was du vorbereitet hast sehr positiv gegenüber eingestellt, habe allerdings noch ein paar Fragen. (Meeting)

CI build ist definitiv was feines - baust du dann u.a. auch mit MSVC?

@Ilm: Danke für das CMake-HowTo. Aktuell ist CMake für mich absolute Nebensache, da OutOfTree-Builds mich im Moment eher bei der Arbeit behindern würden.

Wenn Schick in dem Zustand wie gen ist, ist CMake the WayToGo!

das mit dem OutOfTree Build ist ja nur eine Option - kannst auch alle CMake Artefakte voll zwischen deine Source-Dateinen oder in Unterordner erzeugen - das ist jedem frei gestellt - ich mach das nur gerne so das ich nicht einen besonderen Build-Ordner brauche oder meine .gitignore zugespamt wird

[NewProggie]

@NewProggie: Generell bin ich dem was du vorbereitet hast sehr positiv gegenüber eingestellt, habe allerdings noch ein paar Fragen. (Meeting)

CI build ist definitiv was feines - baust du dann u.a. auch mit MSVC?

Ja. Die ursprüngliche Idee war, Binaries für jeden Commit für Win/Mac/Linux bereitzustellen, damit man das leichter testen kann, weil nicht jeder hier im Forum verständlicherweise einen Compiler bedienen kann. Dann hatte Henne seinerzeit die Binäräquivalenz gecheckt. So etwas schreit ja auch förmlich nach einem CI-Job. Ist dann aber ein bisschen eingeschlafen.

Die rudimentäre CMake in dem Repo ist auch von mir. Macht aber vermutlich auch erst etwas später Sinn das weiter zu pflegen, wenn der erste Port vollständig ist. Bspw. sind die ganzen Shell-Skripte auch eher custom targets, die man im Buildsystem haben will.

[Shihan]

Aloha zusammen!

Wollte eigentlich nur kurz mal in Richtung HenneHW "saugute Arbeit" brüllen, nachdem ich monatelang nur Lurker war 
Im Github-Repo geht ja einiges ab. Sehr cool, dass Du immer noch Bock hier drauf hast. Davor kann man nur den Hut ziehen.


Überlege immer mal wieder, hier das ein oder andere in Richtung RIVA beizutragen, aber mental bin ich seit langer Zeit nicht so auf der Höhe. 
Hennes Einsatz hat allerdings schon was Motivierendes an sich, muss ich zugeben 


Und auch die anderen Beiträge hier sind cool. NewProggies CI-Pipeline und Ilms Einwürfe bzgl. Compiler finde ich besonders fein.
Macht weiter so!!!

[HenneNWH]

@Shihan: Danke! Das freut mich zu hören.

Momentan nehme ich mir die Zeit dafür, da sich dieses Projekt sehr stark auf den nächsten Höhepunkt zu bewegt:
Es wird bald ein Binary für die Schicksalsklinge geben.
Es sind noch 6 Dateien, welche aus unterschiedlichen Gründen nicht kompilieren.

In den letzten Tagen habe ich die Schatztruhen in den Dungeons auf Vordermann gebracht.
Ganz fertig bin ich damit noch nicht, aber wie ich mich kenne ist das innerhalb der nächsten Tage erledigt.


Zwischenstand:
* Binäräquivalenzcodedifferenz = 3927 Bytes
* auskommentierte Zeilen in der symbols.h = 84.5 %
* es kompilieren auch schon einige Dateien (104 / 110) mit dem GCC

Weitere Fortschrittswerte welche definitiv gegen Null gehen:

Code:

# p_datseg     : 159
# ds_read       : 603
# ds_write      : 362
# host_read    : 2806
# host_write   : 626
# _ptr_           : 401

Die ersten 3 Werte hängen mit den globalen Variablen des Spiels zusammen und müssen noch in Form gebracht werden,
damit das Programm ausführbar werden kann.
Die 3 anderen Werte werden später bereinigt, erhöhen die Lesbarkeit des Codes sowie das Verständnis der Funktionsweise der Schicksalsklinge, bzw. der Original-NLT.

[Shihan]

Binäräquivalenzcodedifferenz ist ein wunderbares Wort
Ist das der Unterschied zwischen originaler SCHICK.EXE und deinem Kompilat?

[Obi-Wahn]

Momentan nehme ich mir die Zeit dafür, da sich dieses Projekt sehr stark auf den nächsten Höhepunkt zu bewegt:
Es wird bald ein Binary für die Schicksalsklinge geben.
Es sind noch 6 Dateien, welche aus unterschiedlichen Gründen nicht kompilieren.

[HenneNWH]

@Shihan: So ist er ursprünglich gedacht gewesen. Bei der GEN.EXE funktionierte das Tool von mir hervorragend.

Bei der SCHICKM.EXE ist der Fall aber etwas anders, weshalb diesem Wert erstmal nicht ganz soooviel Bedeutung zugemessen werden sollte wie gehofft.

Die SCHICKM.EXE würde mit seinen ca. 550 kb gar nicht vollständig in den Speicher passen.
Darum werden die Codeteile aus seg024-seg122 bei Bedarf dynamisch Nachgeladen (Overlays).
Damit das funktioniert ist weiterer Code in der SCHICKM.EXE vorhanden, welcher nicht zum eigentlichen Spiel gehört.
Dieser Wert betrifft nur den Code, welcher immer im Speicher ist (seg000-seg013)! und Verwaltungsbereiche
welche das Aufrufen von nachgeladenem Code ermöglichen.


Die von der SCHICKM.EXE nachgeladenen Teile werden von diesem Wert gar nicht erfasst.
Zu früh gefreut.

[Obi-Wahn]

Wäre es für die moderne Version der SCHICKM.EXE nicht besser, wenn das anders gelöst würde? Oder gibt es dann nachfolgende Probleme?
550kb ist heute ja jetzt nicht das große Problem.

[llm]

Die von der SCHICKM.EXE nachgeladenen Teile werden von diesem Wert gar nicht erfasst.
Zu früh gefreut.

d.h. deine aktuelle Portierung enthält dann noch recht wenig von dem eingentlichen Code? ich dachte jetzt auch das du es fast geschafft hast :/

[Shihan]

Wäre es für die moderne Version der SCHICKM.EXE nicht besser, wenn das anders gelöst würde? Oder gibt es dann nachfolgende Probleme?
550kb ist heute ja jetzt nicht das große Problem.

Hier frage ich mich sowieso, wie Henne das im Kontext von BCC und modernen Compilern handhaben wird.
Overlays sind ja eine DOS-Spezialität, die es heute ja dank Virtual Memory und Paging eigentlich nicht mehr gibt. Zumindest nicht bei Desktopanwendungen.

[HenneNWH]

Regel #1: Don't Panic!

Jetzt kommt eine Menge Tech-Kram für Interessierte, welcher nur eine Zwischenstandmeldung ist.

-----------------

@Obi-Wahn: Das betrifft in meinem Fall nur die DOS-Version. Auf moderneren Rechnern mit richtigen Betriebssystemen und genug RAM spielt das überhaupt keine Rolle.

Die Info war eher für Shihan gedacht, der ja auch an RIVA rumbastelt und dabei mit den DOS-Gegebenheiten zu kämpfen haben kann.
Allerdings sind die bei RIVA ganz anders, da der Watcom 10.x Compiler benutzt wurde und dort ganz anders vorgegangen werden sollte.
Wie genau kann ich gerade nicht sagen.

@Ilm: Das "zu früh gefreut" bezieht sich auf die Aussagekraft der bisherigen "Binäräquivalenzcodedifferenz".
Die müsste bei der SCHICKM.EXE noch um den ausgelagerten Code erweitert werden.

Bei der GEN.EXE war das nicht notwendig, da keine Overlays benutzt wurden.
Den Overlay-Teil der SCHICKM.EXE hab ich gestern händisch untersucht und herausgefunden, dass der von mir erzeugte Code insgesamt nur um ca. 32 Byte länger ist.
Ein stumpfer 1:1 Vergleich dieser beiden Bereiche würde im Overlay-Teil zu einer Binäräquivalenzcodedifferenz von ca. 300000 Bytes !!! führen.

Natürlich habe ich noch die Disassemblies von beiden Bereichen verglichen und festgestellt, dass ab seg032 ein paar andere Instruktionen erzeugt werden.
Somit hat sich der Codebereich von seg033-seg122 nur etwas nach hinten verschoben und erzeugt so diesen sehr hohen Wert.

Eine andere Besonderheit ist aktuell noch, dass viele globale Variablen noch nicht die richtigen Adressen haben und von mir per Hand umsortiert werden müssen,
damit BCC/TLINK dasselbe Binary erzeugen können.

Das sind die Besonderheiten, welche nur unter DOS gelten und von mir schon so eingestellt sind, dass das hoffentlich in naher Zukunft alles passen wird.

Unter modernen Plattformen spielen diese Tricksereien überhaupt keine Rolle mehr.
Da werden die Dateien genauso wie damals unter DOS compiliert und gelinkt, nur dass diese Softwareunterstützung jetzt von der Hardware übernommen wird.
Und das macht das ganze viel einfacher. :-)

[Shihan]

Ja, RIVA sieht ganz anders aus. Da ist die große Herausforderung, am DOS/4GW-Loader vorbeizukommen. Aber wenn man das LE-Binary aus der EXE herauslöst (z.B. ein unbind mit Watcoms sb.exe), kann man mit IDA 5.0 und Ghidra den eigentlich Spielcode ziemlich schnell erreichen. Overlays habe ich da auch keine gesehen, was aber nicht heißt, dass es sie nicht gibt. Vielleicht hat cmfrydos was gefunden...

Hier ist tatsächlich ein spannender Punkt, dass viele CALLs über Pointer gehen, weil sie zur Laufzeit mit den vtables der einzelnen C++-Klassen gefüttert werden. Da kommt die statische Analyse schnell ins Schleudern

[llm]

Ja, RIVA sieht ganz anders aus. Da ist die große Herausforderung, am DOS/4GW-Loader vorbeizukommen. Aber wenn man das LE-Binary aus der EXE herauslöst (z.B. ein unbind mit Watcoms sb.exe), kann man mit IDA 5.0 und Ghidra den eigentlich Spielcode ziemlich schnell erreichen. Overlays habe ich da auch keine gesehen, was aber nicht heißt, dass es sie nicht gibt. Vielleicht hat cmfrydos was gefunden...

d.h. RIVA ist 32bit code mit DOS-Extender? d.h. nur die Aufrufe Richtung DOS API und die Hardware-Zugriffe sind nicht Windows tauglich? Vergleichbar mit dem SyndicateWars reversing: https://gynvael.coldwind.pl/?id=278

(SCHICK ist, nach meinem Verständnis, ja Realmode mit Segment/Offset was es noch schlimmer macht zu reversen)

[Shihan]

Ja, ganz genau. Was ich bisher von den Hardwarezugriffen gesehen habe, ist ein Haufen DPMI-Zeugs.

Und ja, ich würde dir zustimmen, was die Schwierigkeit angeht. So wie es sich mir bisher darstellt ist der Wechsel Real Mode <-> Protected Mode die größte Schwierigkeit. Solange man im PM ist, gibt es einen schön flachen Speicher in einem Segment.
Es gibt ein paar ISRs, die liegen ja glaube ich unter Umständen ausserhalb.

[HenneNWH]

(SCHICK ist, nach meinem Verständnis, ja Realmode mit Segment/Offset was es noch schlimmer macht zu reversen)

Richtig, darum beeile ich mich auch so, damit ich nicht mehr über verschiedene Pointertypen (near, far, huge) und deren Normalisierung nachdenken muss.
BTW: Aktuell bin ich gerade an den Reisestartpunkten dran (Hafen und Wegweiser).

Zwischenstand:
* Binäräquivalenzcodedifferenz = 3892 Bytes
* auskommentierte Zeilen in der symbols.h = 87.6 %
* es kompilieren auch schon einige Dateien (104 / 110) mit dem GCC

Weitere Fortschrittswerte welche definitiv gegen Null gehen:

Code:

# p_datseg     : 131
# ds_read       : 412
# ds_write      : 204
# host_read    : 2709
# host_write   : 618
# _ptr_           : 401

[HenneNWH]

Zwischenstand:
* Binäräquivalenzcodedifferenz = 3834 Bytes
* auskommentierte Zeilen in der symbols.h = 90.8 %
* es kompilieren auch schon einige Dateien (104 / 110) mit dem GCC

Weitere Fortschrittswerte welche definitiv gegen Null gehen:

Code:

# p_datseg   : 114
# ds_read    : 353
# ds_write   : 167
# host_read  : 2691
# host_write : 618
# _ptr_      : 402

[llm]

d.h. du stehst "kurz" vor einer nativen 32/64bit SCHICKM.EXE?