Harvest Moon - A new Beginning (3DS) -> Scripts in PlainText, benötige weitere Hilfe

      Harvest Moon - A new Beginning (3DS) -> Scripts in PlainText, benötige weitere Hilfe

      Hey Leute,

      ich habe gestern begonnen das Spiel "Harvest Moon - A new Beginning" zu decrypten und wollte mir eigentlich nur das 3D Logo, welches man im Systemmenü sieht, abspeichern um ein Beispiel für Größe und Aufbau für ein Custom 3D Logo zu bekommen.
      Jedoch fand ich in den entschlüsselten Dateien im romfs-Ordner noch etwas, was um einiges Interessanter war.
      Denn es stellte sich heraus, das die Scripts (im Grunde fast alle Code-Bezogenen Dateien) entschlüsselt als PlainText vorliegen!


      Anhand des Codes habe ich herausgefunden, dass alles in Squirrel Language geschrieben ist.


      Es sollte mir also möglich sein, tiefgreifende Modifikationen bzw. Veränderungen an dem Spiel vorzunehmen!

      Nun gibt es jedoch zwei Probleme, die ich nicht gelöst bekomme...

      Weiß zufällig jemand von euch, wie ich die romfs.bin rebuilden kann und dann das Spiel rebuilden kann mit der veränderten romfs.bin?
      Da bräuchte ich wirklich dringend Hilfe!

      Ich habe auf meiner SD-Karte die Palantine CFW 4.5 installiert und besitze dieses Spiel als original eShop-Spiel.
      Das originale, unveränderte eShop Spiel funktioniert bei mir auch Problemlos auf der CFW.




      So habe ich das Spiel decrypted:
      Decrypted habe ich das Spiel mit "3DS Lazy 1.2", heraus kamen folgende Dateien und Ordner:


      anschließend habe ich die romfs.bin rebuilded mithilfe von dem Programm SciresM's RomFS-Builder. Alle Dateien aus dem "romfs"-Ordner wurden zu einer neuen romfs.bin zusammengefügt.
      Nachdem dies passiert ist, habe ich die decrypteten exefs.bin, exheader.bin und romfs.bin, welche oben im Bild zu sehen sind, kopiert.

      Danach decryptete ich mithilfe von "AUTO CIA", einem Programm zum builden von .cias, genau das gleiche Spiel.
      im Ordner "AUTO CIA/tmp" wurden ebenfalls die Daten decrypted. Ich kopierte meine exefs.bin, exheader.bin und die neu erstellte romfs.bin in genau diesen Ordner und ersetzte die Dateien, welche von Auto CIA erstellt wurden.
      Danach sah der tmp-Ordner so aus:



      So habe ich das Spiel rebuilded:

      Anschließend habe ich das Spiel mit Auto-CIA zu einer installierbaren cia-datei gepackt, mit den Einstellungen, die AUTO-CIA aus der originalen rsf-datei erstellt hat:


      Nun, AUTO_CIA hat eine cia-Datei erstellt und gab mir keinerlei Fehlermeldungen.
      Ich habe das Spiel mit BigRedMenu installiert und wollte es starten.
      Nun das Problem: Nach dem 3DS-Boot-Logo bleibt das Bild schwarz und der 3DS hängt sich auf.
      Ich verstehe nich, wo das Problem liegt.

      Wenn ich die cia direkt schon über 3DS Lazy builde, nachdem ich die romfs.bin rebuilded habe, erscheint beim Starten des Spiels eine Fehlermeldung und ich werde gebeten, den 3DS neu zu starten.




      Mein zweites Anliegen:
      neben den entschlüsselten Scripts im .nut-Format liegen noch Dateien im xbb-Format vor.
      Diese scheinen Archive zu sein, welche ich gerne unpacken und repacken würde.
      Diesbezüglich habe ich eine Dokumentation zum Format der Dateien gefunden, welche jedoch für das Spiel "Harvest Moon Sunshine Island" waren.
      Ich bin mir nicht sicher, ob der Entwickler seitdem das Format überarbeitet hat, jedoch würde ich mich freuen, wenn mir jemand helfen würde einen unpacker/repacker für dieses Format zu entwickeln.
      Hier die Dokumentation


      Ich würde mich sehr über eure Hilfe diesbezüglich freuen. Dies könnte jedenfalls einiges ermöglichen, da wir vollen Zugriff auf die ganzen Scripts haben.

      Bist du denn sicher, dass die Scripte wirklich so ausgeführt werden und dass das nicht nur irgendein Entwicklungs-code ist der fürs fertige Spiel dann kompiliert wurde und nur fälschlicherweise noch im Spiel ist?

      DevkitPro Archiv (alte Versionen / old versions): wii.leseratte10.de/devkitPro/
      Want to donate for Wiimmfi and Wii-Homebrew.com? Patreon / PayPal

      Dieser Beitrag wurde bereits 0 mal editiert, zuletzt von Leseratte ()

      Leseratte schrieb:

      Bist du denn sicher, dass die Scripte wirklich so ausgeführt werden und dass das nicht nur irgendein Entwicklungs-code ist der fürs fertige Spiel dann kompiliert wurde und nur fälschlicherweise noch im Spiel ist?



      Ja, da bin ich mir sicher :)
      Wenn man bedenkt, das wirklich ALLE Scripts so vorliegen und diese im Ordner "Script" liegen, denke ich schon, dass diese Scripts wirklich so ausgeführt werden ;)
      Btw. wenn die Daten fälschlicherweise noch im Spiel sind, würde es mich wundern, wenn diese auch in der europäischen Version drin sind. Als Entwickler kann mir das in der japanischen Originalversion passieren, hätte es aber vor dem Europarelease bestimmt bemerkt.

      Aber abgesehen davon: Selbst wenn ich an keinen Dateien etwas ändere und versuche die romfs.bin zu packen und diese in der cia zu verwenden, warum bekomme ich nur einen Blackscreen? Wie könnte man dies beheben?

      Hier nochmal ein Screenshot der den romfs-Ordner zeigt, den darin enthaltenen "Script"-Ordner und ein Script, das zeigt, dass die Scripts aus dem Scriptordner als ".nut" geladen werden.

      Ciapa schrieb:

      Ich vermute doch eher, dass die aus Zufall drin sind, so wie z.B. die memory.ini in MH3U
      Denn Squirrel wird ja standardmäßig auch Kompilliert, soweit ich weiß. Wäre ja auch schwachsinn, falls nicht.

      Würde mich dann jedoch wundern, wieso ich keine zusammenhängende Datei in der romfs finden kann, welche ein kompilierter Code sein könnte.
      Dort befinden sich hauptsäclich die bekannten "bc"-files wie "bcmdl", "bcskel", "bctex" Dateien, ein paar arc-files und wenige xbb-files mit ~10kb - ~250kb size.
      Es befinden sich KEINE .bin-files oder ähnliche in dem Spiel.

      Es gibt da noch zwei etwas größere xbb-files wovon eine wohl alle Texte des Spiels enthält (Msg.xbb) und eine andere, welche sich wie folgt nennt: DeviceResidence.xbb

      Wenn die "unkompilierten" codes tatsächlich vergessen wurden, warum gibt es dann einige Scripts, die auf andere Scripts im .nut Format verweisen und einige Scripts, die auf .xbb files verweisen?

      Dazu sollte es mir mittlerweile möglich sein, xbb-files mit folgendem Script zu entpacken:

      Quellcode

      1. #XBB
      2. IDString 0 XBB;
      3. GoTo 4 0;
      4. Get NFiles Long 0;
      5. GoTo 32 0;
      6. For T = 1 To NFiles;
      7. Get FileOffset Long 0;
      8. Get FileSize Long 0;
      9. Get FileNameOffset Long 0;
      10. Get FileID Long 0;
      11. SavePos HeaderOffset 0;
      12. GoTo FileNameOffset 0;
      13. Get FileName String 0;
      14. Log FileName FileOffset FileSize 0 0;
      15. GoTo HeaderOffset 0;
      16. Next T;
      Alles anzeigen


      Bedenke: Die xbb-files sind scheinbar nur Archive!
      Werde das Script testen, sobald ich zuhause bin
      UPDATE: Habe soeben mal die Msg.xbb entpackt:
      Darin befinden sich Dateien, welche alle einen "PAPA"-Header haben.

      Diese habe ich (einigermaßen) mit diesem Script entschlüsselt:
      Spoiler anzeigen

      Quellcode

      1. #PAPA
      2. IDString 0 PAPA;
      3. GoTo 8 0;
      4. Get HeaderOffset Long 0;
      5. Get HeaderSize Long 0;
      6. Get NFiles Long 0;
      7. Math NFiles -= 1;
      8. For T = 1 To NFiles;
      9. Get FileOffset Long 0;
      10. SavePos HeaderCurOffset 0;
      11. Get NextFileOffset Long 0;
      12. Set FileSize Long NextFileOffset;
      13. Math FileSize -= FileOffset;
      14. GoTo HeaderCurOffset 0;
      15. Log T FileOffset FileSize 0 0;
      16. Next T;
      Alles anzeigen


      Heraus kamen einige Dateien, welche nicht ganz sauber entschlüsselt sind, wo man aber hauptsächlich Text draus lesen kann. Diese Dateien sind kein bisschen mit den .nut-Dateien vergleichbar, bzw. enthält keiner der .nut-files (die Scripts) irgendwelche Texte von Charakteren.
      Beispiel:


      Ciapa schrieb:

      Ist wahrscheinlich fest im jew. boot.dol-Deviat(bei der WiiU Codename.rpx) verankert. Aber ka. Funktioniert das Entpacken und packen ohne Veränderung denn? Was passiert, wenn du das 2D-Icon des Spiels änderst?

      Das Icon kann ich verändern, dieses befindet sich aber nicht in der romfs.bin, sondern in der icon.bin.

      Ciapa schrieb:

      ChrisX930 schrieb:

      Das Icon kann ich verändern, dieses befindet sich aber nicht in der romfs.bin, sondern in der icon.bin

      Ah okay, bei der WiiU ist das ganze etwas anders aufgebaut(data/content, data/code und data/meta, dazu noch system/xx)

      Bei der WiiU weiß ich das leider nicht wirklich^^ nie mit gearbeitet bisher (warum auch, könnt da eh noch nichts mit machen, da kein Exploit existiert, den ich verwenden könnte).
      Wie du sehen kannst, sind das die einzigen Dateien die bei dem decrypten mit 3DS Lazy herauskommen:

      Ich möcht nicht lügen, bin mir aber gerade nicht zu 100% sicher, aber icon.bin etc. befinden sich in der "exefs.bin".
      romfs, den Ordner siehst du ja selber.
      Darin beinden sich insgesamt nur folgende Dateiformate:
      - bcmdl, bctex, Grid.bin (nur für Maps), bcsdr, bcsar, bcstm, shbin, arc, moflex sowie nut und xbb.
      xbb sind in diesem Fall Archive, die ich entpacken kann, wie du oben sehen kannst.


      EDIT: Gäbe da natürlich noch den Ordner "GameData", welcher ebenfalls ein paar xbb-Files enthält und wo man glauben könnte, dass diese Scripts enthalten könnte (im kompilierten Format), jedoch haben die nut-Scripts eine ungefähre größe von zusammen rund 8MB und die xbbs in diesem Ordner nur rund 1,8MB.
      Dazu habe ich einige der xbb's entpackt und konnte nichts finden, was einem kompiliertem Code wie die unkompilierten .nut's gleichkommt.


      Das Ganze ließe sich auch testen, indem ich bei den .nut-Codes beispielsweise den Anfangs-Geldbetrag von 500 auf 10000 ändere, jedoch habe ich wie oben beschrieben das Problem, dass ich das rebuildete Game (trotz Keinerlei Änderungen an den Files im romfs) nicht zum Starten bekomme, weshalb auch immer.



      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von ChrisX930 ()

      Hmm,
      da ich selber keine Gateway hier habe, und meine Freundin mir solche Experimente an ihrem 3DS nicht genehmigen lassen würde, kann ich dir dabei nicht helfen. Das einzige, was ich vermuten würde ist, dass das Spiel selber eine Prüfsumme der einzelnen Skripte generiert. Schau mal was passiert, wenn du eine unnötige Datei hinzufügst. D.h. einfach damit rumspielen, Datei hinzufügen, löschen, bearbeiten usw, und dann schauen, was passiert.
      14.932 bytes pure destruction.

      Ciapa schrieb:

      Hmm,
      da ich selber keine Gateway hier habe, und meine Freundin mir solche Experimente an ihrem 3DS nicht genehmigen lassen würde, kann ich dir dabei nicht helfen. Das einzige, was ich vermuten würde ist, dass das Spiel selber eine Prüfsumme der einzelnen Skripte generiert. Schau mal was passiert, wenn du eine unnötige Datei hinzufügst. D.h. einfach damit rumspielen, Datei hinzufügen, löschen, bearbeiten usw, und dann schauen, was passiert.


      WENN das Spiel selber für jedes Script eine Prüfsumme generiert, müsste ich mit einer rebuildeten romfs.bin, wo ich KEINE Dateien verändert habe, doch das Spiel starten können, oder nicht? aber selbst das funktioniert nicht.

      EDIT: Kennt jemand einen besseren Weg, eine rom zu rebuilden, ohne meinen Umweg nehmen zu müssen?

      Ciapa schrieb:

      Mal die Checksummen der romfs.bin Dateien verglichen? Also vom CIA Tool die und die beiden vom 3DSLazy Tool(direkt aus der .3ds und repacked aus dem Ordner)?
      Ich hatte das oben ganz überlesen, von daher dachte ich, dass das ungetestet gewesen wäre.


      Ich bin mir nicht sicher ob es daran liegen kann. Das Spiel ist schon sehr alt und bei Spielen wie Pokemon und Mario Kart scheint das rebuilden der Rom mit einer custom romfs.bin ja auch zu funktionieren (habe es noch nicht selber getestet).

      Könnte mir vllt. wer eine andere, simple Möglichkeit nennen, eine 3ds rom zu rebuilden?

      EDIT: habe mal die Checksums verglichen und sie unterscheiden sich:



      Auch wenn ich irgendwie nicht glauben kann, dass das Spiel die Checksum überprüft (weiß ich wirklich nicht), gibt es denn eine Möglichkeit diese an das Original anzupassen?

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von ChrisX930 ()

      Ciapa schrieb:

      Ungleiche Checksummen bedeuten, dass das Spiel bzw die romfs.bin nicht 100% Korrekt zusammengepackt wurde.
      Probiers mal mit Project_CTR vom 3DSGuy(github.com/profi200/Project_CTR)


      Erstmal schonmal danke :)
      Magst mir noch verraten, wie ich damit die romfs.bin wieder zusammensetze?
      das entpacken habe ich mit einer älteren ctrtool.exe hinbekommen.
      btw. wie bekomme ich die neue version dieser ctrtool.exe zum laufen? Mir scheinen dlls zu fehlen.
      Und wenn ich alle benötigten heruntergeladen habe, gibt er mir eine Fehlermeldung dass die exe nicht gestartet werden kann

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von ChrisX930 ()

      Ciapa schrieb:

      Windows? Linux? OS X?

      Windows 8.1.

      Habe mir nun ein "Mod Paket (3DS HAck Tools)" heruntergeladen.
      Darin befand sich eine "makeromfs.bat", eine ctrtool.exe und eine makerom.exe.
      Es scheint, als hätte es eine neue romfs.bin erstellt. Die Hashes sind identisch, was mich ziemlich freut.
      Werde es nun nocheinmal testen, diesesmal jedoch mit einer abgeänderten Datei


      EDIT:
      Argh, wie zu erwarten war, hat sich mit der Änderung einer Datei auch die Checksum nach dem Rebuild geändert...
      Wenn die Leute das mit Mario Kart und Pokemon hinbekommen, wieso bekomme ich das nicht so hin? >_>

      Ciapa schrieb:

      @ChrisX930
      Wenn du eine Datei IM ROMFS änderst, ist das normal, dass sich die Checksum ändert... Das ist ja anderer Content drin...
      Probier mit der romfs nun einmal das Spiel zu starten.


      gutgut xD
      So, cia installiert nun und hoffe auf ein positives Ergebnis, denn:

      Heute Mittag habe ich den RomFS-Builder verwendet.
      Ergebnis: Identische Dateien, nichts abgeändert, andere Checksum

      Nun nutze ich die andere Variante:
      Ergebnis: Identische Daten, identische Checksum.

      Da sich die Checksum nach Änderungen von Dateien eh ändert, nutze ich die andere Variante, die mir beim Checksum.Test ein positives Ergebnis brachte.

      IN ca. 5minuten kann ich mein Ergebnis vorstellen


      EDIT:
      Spiel ist gestartet! Das ist schonmal super :D
      Habe in den Scripts das Startkapital geändert und werde überprüfen ob es auch so läuft wie gewünscht

      EDIT: Startgold ist nun auch im Spiel auf 10000 statt auf 500!
      Funktioniert also! :)

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von ChrisX930 ()