It's not exactly what you wanted, but I've pivoted to looking for how the save files are encrypted and decrypted since there's no working save editor. I'm thinking that a save editor might be easier than tracing through the obfuscated code while the game is running. So far I've found the instructions that write to the unencrypted file data before it's encrypted and written to disk. I think within the next few days (probably longer) I
might be able to figure out where the key and such are. I still have no idea what the encryption is, but it could be blowfish since apparently MHW used that.
I'm pretty new at reversing and hacking, so if anyone wants to collab on this, I'm open. Send me a message and I can get you my Ghidra project and notes.
PS:
pretty sure a stick of RAM just went bad on me. So, uh, it'll be at least until I can get some new RAM :') I was going to type something else but I totally lost my train of thought after that. Thankfully it was just RAM! I'm going to pick up some new RAM tomorrow morning.
For real, though, if anyone has experience with the Monster Hunter World save decryption, hit me up! I've looked at a few Github repos, but I'd like to hear about the process of researching and getting to that point.
Update 2022-09-25:
I was able to dump the memory of the complete unencrypted save file (the larger of the two). No idea how it's going to change for the title update coming out in a few days, though. The file in total is 6.1MB and is exactly 1 byte shorter than the size of
data001Slot.bin in the save folder.
I'm still not sure what
data00-1.bin is yet, but I saw a tweet that mentioned that the save files are compressed, so maybe that is the compressed version of this file since there is
a lot of repetitive data in this file. I still don't know how this file is actually being encrypted as of now.
Interesting things about the save file are: the size, the amount of unused space and useless data, and the number of UTF-16 strings written to the file. The UTF-16 strings in particular might make dissecting the file easier.
Update 2022-09-26:
I've found where the first 16 bytes (The
CSSS header) are being copied to the output buffer and, more importantly, the line of code that calls to the encryption function. Unfortunately, the encrypt call is
call rax and the memory address for that call is conspicuously low in memory (0x08XXXXXX), far below the MHR start offset. I'm still a noob, so I don't know what that means. I also can't figure out the arguments to the function, also likely due to me being a noob. At the moment, I still think it's blowfish because blowfish on Windows takes both an input and output buffer as params and there are, of course, two buffers here: the plaintext and the ciphertext.
Idk if I'll be able to figure this out before the title update this week. The update is making me pretty nervous because I don't want to lose all of my research up until this point.
Hopefully bindiff comes through when that happens and there aren't any new values encrypted or code obfuscated.
Hopefully bindiff comes through when that happens and there aren't any new values encrypted or code obfuscated.
