Reverse Engineering der NLT II

[Shihan]

Das Tool war der erste Google-Treffer auf meine Suche nach einem Watcom Disassembler. Wie gesagt, Assembler ist für mich Neuland. "Unter" C habe ich mich bisher nicht getraut. Daher kenne ich z.B. Ghidra gar nicht, aber sollte es mir wohl auch mal anschauen.

Ghidra stolpert ab und an über das Disassembly (keine Ahnung, welchen Ansatz die nutzen). Das Problem ist ja generell, dass man das richtige, echte Disassembly eigentlich erst zur Laufzeit bekommt, weil dann bei Sprüngen und Pointer-Aktionen die notwendigen Register-Inhalte gesetzt sind. Alles andere ist eigentlich kluges Raten.

Wie dem auch sei, im Großen und Ganzen passt der Code. Das Schöne ist, dass man durch den Code browsen kann. Z.B. einem Call folgen, schauen, an welchen Stellen auf eine Adresse geschrieben oder von ihr gelesen wird, etc.
Und es gibt auch die Möglichkeit, eine Konvertierung in eine mögliche C-Funktion zu machen. Die ist meistens ziemlich chaotisch und kompiliert garantiert nicht, aber Dinge wie if oder while kann man dann schon erkennen.

   

Lohnt sich also schon, da mal einzusteigen

Da ich wirklich noch nicht viel von der Materie verstehe, frage ich lieber noch einmal nach, was genau du von mir gerne haben möchtest.
Ich erklimme leider gerade noch "Mount Stupid"..

Mount Stupid ist völlig ok. Da stand ich auch drauf und dachte, ich hätte die Welt verstanden

Was genau sind Asm-Listings? Meinst du damit die gesamte Ausgabe des wcdatools? (wenn ja, lieber von riva de oder en?)

Jep, aber wie es scheint, gibt es da echt nur diese riesige ASM-Dateien...

An Infos daneben habe ich eine Liste mit HEX-Suchstrings, mit den gefundenen Adressen in der V1.01UK und der deutschen V1.12.
Jeweils noch mit einem Kommentar mit in etwa der Funktion an dieser Stelle. Die HEX-Suchstrings solltest du auch in deiner Disassembly finden.

Jep, das ist z.B. einer der großen Vorteile von Ghidra, weil es genau diese definierten Strings schon sammelt und dann auch sucht, wo sie im Code referenziert werden. Das hilft unglaublich!

Oh, Wow, das hört sich ja fantastisch an! Keine Ahnung, wie du das geschafft hast - Ich habe da selbst nur immer mal wieder ein paar Strings im Hexeditor gesehen, konnte damit aber gar nichts anfangen.. ZB. die Informationen zu den Dungeon-Verknüpfungen, welcher Ausgang zu welchem Eingang führt, stand inmitten von .cpp Dateien (also den String Verweisen darauf). Deine Zuordnung könnte mir tatsächlich einiges erleichtern, da es meinen Suchraum stark einschränkt.
Wenn man aus den Startpositionen der Funktionen einen eindeutigen Suchstring generieren könnte, kann ich das direkt im Debugger anzeigen lassen. Nur so als Idee, um da unsere Ergebnisse abzugleichen. Das mit den Suchstrings funktioniert aber nicht überall. Vorallem bei weiten Sprüngen, oder Variablenreferenzierungen gibt es da doch einen Unterschied zwischen den Riva Versionen, und meiner disassembly. Aber in 2 von 3 Fällen hat es bisher geklappt. Optimalerweise würde man da dann mit einer RegEx suchen, bei denen die uneindeutigen Adressen Wildcards sind.

Mal sehen, wie ich das aufbereite. In Ghidra kann man mit Python viel machen. Also werde ich wohl einfach einen sinnvollen Export bauen. Könnte aber ein paar Tage bauen, bis ich da was brauchbares habe...

Danke für deine Einschätzung, damit habe ich das Vertrauen, dass bei meinem Shader etwas sinnvolles bei rauskommen könnte
Wirklich vielen, vielen Dank für deine Hilfe! Hier ist es etwas still geworden, und die meisten Experten hier schauen nur noch alle paar Monate oder Jahre vorbei. Ich habe das Gefühl, ich bin hier über 10 Jahre zu spät, andererseits dann aber doch froh, dass es an Riva noch zu arbeiten gibt.

Jederzeit und sehr gerne!
Finde es großartig, dass Du hier eingestiegen bist und jetzt so viele gute Erkenntnisse gewonnen hast. Das hat mich motiviert, auch nochmal mehr einzusteigen.