Closed Joey35233 closed 6 years ago
I can only take guesses with this one until the full game is released. I would appreciate if someone else also tries to debug this by comparing the original to the repacked files and see what changed (besides the zlib compressed and not reencrypted files inside the archive).
Maybe the lua encryption isn't optional with this fox engine version or the MD5 checksum (which is now required to decrypt) of of the files is generated too early/late.
metal Gear Survive crashes if its chunk0.dat is repacked.
Also, GzsTool throws an OutOfMemory exception when trying to unpack a day unless GzsTool is built in Debug mode in Visual Studio.
The OOM issue could be related to the >1GB wmv files and can only be fixed by rewriting the decryption and decompression functions to be stream based.
That is the issue. I spoke to BobDoleOwndU about it on Discord and we tested it; it crashes on those .wmv files that are bigger than 1GB, such as 2930368d6e6d9.wmv. I am unsure of why the release builds crash and the debug modes don't, though.
Can confirm that actual retail version of MGSurivive does crash when data1.dat is repacked.
The latest commit should fix the out of memory issues when unpacking the larger archives. It should only need like 80MB RAM when unpacking the 8GB archives. That version also needs testing with the MGSV files in case I broke something by accident.
Has anyone even looked at what the issue when repacking files is? Do some archives work and some not or does every file cause the freeze? Does repacking without a dictionary work?
I didn't try all of them but i'm positive that data1.dat will not repack correctly and i've seen somewhere that someone tried to also repack one of the chunk dats and it didn't work either.
Using latest commit as of this writing: Game closes silently within second of starting when repacking data1.dat with no modifications, empty dictionary or not. Before it even constructs a window. Game crashes ('Metal Gear Survive has stopped working') with repacked Chunk0.dat, after it's constructed a window, but before anything displays/switches to fullscreen. (Same behavior with prior GzsTool) Same crash after window behavior as Chunk0 when repacking 00.dat (added in last update).
The issue seems to be that this fox engine version doesn't seem to allow skipping the encryption of lua files.
I did another set of tweaks. The repacked 00.dat didn't immediately crash the game for me this time.
Indeed the game does load now although this seems to also break some if not all of the scripts as first prompt as the game loads you cannot participate in a mission as it requires level 0 or higher and then it just keeps loading infinitely.
Nevermind, it actually does work, dummying out the "0" folder (actual patch) does this
Tested as of the latest commit:
-Repacking chunk0 (with no changes) causes the game to load endlessly (Are there other files besides Lua which are encrypted? I.e. foxfs.dat?)
-Repacking data1.dat (with no changes) works fine.
-Repacking data1.dat with any change (even adding a comment) to a Lua script causes the game to load endlessly (a checksum is possibly being run on the scripts, which would also explain the need for re-encryption).
-Adding a new file to data1.dat (without changing any of the original files) works fine.
-Repacking chunk0 (with no changes) causes the game to load endlessly (Are there other files besides Lua which are encrypted? I.e. foxfs.dat?)
You can check this by taking a look at the generated .xml file for chunk0. The encrypted files have an XML attribute Encryption=number. I also haven't fixed the out of memory issues when repacking yet, only when unpacking. That could be related.
-Repacking data1.dat with any change (even adding a comment) to a Lua script causes the game to load endlessly (a checksum is possibly being run on the scripts, which would also explain the need for re-encryption).
I only tested repacking the original files so far by using the patch files in the 0 directory. Since it's gone now I might take a look at the other files.
-Adding a new file to data1.dat (without changing any of the original files) works fine.
Does changing any of the original non-encrypted files work?
Within data1.dat any changes will instantly make the game show "level 0 or above" prompt and then load infinitely.
I can also confirm that adding new files does not cause any issues.
I can only take guesses but it is possible that the game downloads a list of file MD5 hashes and verifies the actual hashes against them. New files might not be checked that way because there is no way to load them? That can only be fixed by either patching the game or by proxying the requests to their backend server (which would also require patching the game if https + certificate pinning is used) which is out of scope for this project.
Another issue could be related to both encrypted and compressed files. The file layers look like this:
(1.) encrypted with a hardcoded key (2.) encypted with per file key
Maybe changing which file layer is used for the MD5 hash might fix that issue.
It looks like changing Lua scripts located within the /Assets/tpp/ folder works. But I don't think these scripts are actually used by the game. So it looks like it's only scripts in the /Assets/ssd/ that cause it to load endlessly when changed.
Does changing any of the original non-encrypted files work?
Changing ffnt files (within the ssd folder) seems to work fine. The game still loads fine after changing them; but all of the in-game text seems to break for some reason.
Check out if the latest version can load modified lua files.
Yep. The new version seems to work with edited Luas no problem. Nice work!
Some confirm if repacking chunk0.dat is also working with the latest version.
No window opens, the game simply does not start.