Reverse Engineering der NLT II

[cmfrydos]

Kurzes Update:

Irgendwie kommen immer mehr kleinere Dinge dazu, die vor einem Release des Viewers / ResolutionMods noch gefixt werden sollten. Könnte sich also noch etwas verzögern..

Mir ist heute aber eingefallen, dass ich noch kleinere Erkentnisse zu den .ALF Archiven gewonnen hatte, die es teilweise ermöglichen, diese auch so zu packen, dass das Spiel diese einliest. Das scheint nach Wiki bisher noch nicht geklappt zu haben.

Anmerkung: Die folgenden Daten sind noch etwas ungewiss, da es uns noch nicht gelungen ist, ein Riva-Archiv so zu packen, dass das Spiel dieses fehlerfrei nutzen kann. -- Hendrik

In den Riva-Archiven sind die Dateien jeweils Modulen zugeordnet. In der Regel gehört eine Datei in ein bestimmtes Modul, es ist jedoch auch möglich, eine Datei mehreren Modulen zuzuordnen. Im Archiv müssen die Module in einer bestimmten Reihenfolge (nämlich der gleichen wie in der .MOD-Datei, siehe dort) stehen, und innerhalb dieser die Dateien, ebenfalls in fester Reihenfolge. Auf die Module wird über ihren Namen im Archiv zugegriffen. Der Zugriff auf die Dateien erfolgt über deren Index im Archiv und nicht über den Dateinamen.

(https://github.com/shihan42/BrightEyesWi...BCber-Riva)

Bei der Analyse der Dateizugriffe stellte sich heraus, dass auf Archivdateien über zwei UInt16 zugegriffen wird, eins für das Modul (minus 1), das andere für die Datei in diesem Modul. Welche ALF gemeint ist, ergibt sich eigentlich immer aus dem Kontext. Modul und Datei steht meistens zusammen in einem Register, also zB. als 000A0002 was die 3. Datei im 10. Modul repräsentiert.

Die Reihenfolge der Module ergibt sich aus der Reihenfolge in der ensprechenden .MOD Datei zum .ALF Archiv.
Diese Reihenfolge muss nicht identisch sein mit der Reihenfolge der Module in der .ALF! Bei der Riva.ALF ist es dies beispielsweise nicht. Man packt die Module also, wie man sie in der .ALF vorgefunden hat. Das Spiel greift dann auf ein Modul i so zu, dass es den i. Namen in der .MOD nimmt, und dann das Modul in der .ALF sucht, dass diesen Namen trägt. Aus Performancegründen steht diese Permutation wahrscheinlich in einem Array und wird nur ein einziges Mal bestimmt.

Auf welche Datei zugegriffen wird, kann man anhand der DSA3::entries des NLTPackers ablesen (https://github.com/Henne/BrightEyes/blob...3.cpp#L338), wenn man für "Dummy-Einträge" ebenfalls einen leeren Eintrag vornimmt. Die Dummies stehen gewissermaßen für gelöschte Dateien.

Beim Entpacken muss man sich folglich den Index der Dateien und Module merken, wobei manche Indices nicht belegt sind, und dann in der selben Reihenfolge wieder packen.

Eigentlich macht Hendrik da alles richtig, aber irgendwie ist die -c Option (Neupacken) von NLTPack noch etwas verbuggt, da synchronize() die Dateien der .FN nicht mit denen in der Ordnerstruktur matcht (ist vielleicht nur ein falscher Path-Delimiter oder so). Davon, und dem Kopierschutz (s.u.), abgesehen verstehe ich nicht wirklich, wieso das Packen damit noch nie geklappt hat.

Naja, mit meiner gekaperten C#-Version des Packers kommt so dann ein funktionierendes RIVA.ALF Archiv bei raus, was ich durch Modifizieren von Soundfiles verifizieren konnte.

Es gibt nur ein Problem bei den meisten Archiven: Nur auf RIVA.ALF, RIVAHELP.ALF, RIVAHINT.ALF wird über die Festplatte zugegriffen, der Rest liegt auf der CD, und ist somit nicht direkt modifizierbar. Bei Entpacken der .ISO und Neupacken mit geänderter ALF beschwert sich der Kopierschutz von Riva. Wie dieser funktioniert kann ich noch nicht genau sagen. Falls dieser mit Hashwerten der Dateien arbeitet, könnte es so gut wie unmöglich sein, jene Archive zu modifizieren, ohne den Kopierschutz der .EXE durch einen Patch zu umgehen. Und letzteres hört sich leider ziemlich I**egal an.. Hoffentlich sind es aber nur Metadaten der CD, die beim Neupacken verloren gehen, nur kenne ich mich damit leider nicht wirklich aus.

Vielleicht lösen wir in Zukunft noch dieses Problem, und wären dann in der Lage, Riva vollständig zu modden.