(Continuing on from my last thread
, I made a new one because it's a different issue altogether)
I'm currently working on a PS1 game with a file that can't be modified. If I change even a single byte, the game softlocks on the loading screen where it's being read.
It's not that I'm modifying sensitive data: I've already figured out the file contents, and I know for sure that what I'm modifying is plain text data. If I make the same change directly to RAM instead of the BIN, the changes in text show up just fine.
It's not that I'm changing the file's length or position: this happens even when I replace a single byte on the middle of the file.
It's not EDC/ECC data: I have the disc's EDC/ECC data recalculated after any change I make. Either way, I'm working on no$psx, which AFAIK ignores EDC/ECC data entirely anyway. Though I'm getting the same issue with other emulators too.
Then there's this:
At the start of each of these files, there's 8 bytes of data I haven't been able to figure out what they're used for. They're ignored by pointers tables to filesizes and file start offsets, and they're not loaded to RAM. Because of this, I also can't (or don't know how) "breakpoint" on it and trace what is it being used for.
However, I noticed that if I change it, I get the same softlock on loading screens I get if I change a byte within the actual contents of the file. This led me to believe those first 8 bytes might be used as a checksum for the rest of the file whenever the file is being loaded to RAM. So I would need to either figure out how to update this value after making changes, or bypass this hypothetical file integrity check entirely.
I'm not entirely sure if that's what's going on, so I came to ask for anyone who might've had a similar experience to give me some pointers.
Has anyone had a similar problem and has been able to solve it? If so, what was the cause?
If it is indeed a checksum, how would I go about reverse engineering it? Is that even feasible to do? Are there any commonly used checksum algorithms I should check?
What about skipping integrity checks altogether?
For now the only thing I can think of is to read and compare what's going on in code during the softlock. Weirdly, if I revert the modified byte to its original value (any byte within the file that I might have modified) while the game is running, the game immediately gets unstuck and the loading screen completes, so I guess it's reading the same place over and over again until it gets the value it's expecting. Though to get a complete comparison of both cases (stuck/file modified, unstuck/file unmodified) I'm afraid I'll have to look line by line for a long time. I could really use a complete log of the CPU code while this happens, but this game doesn't run on PCSX Agemo, and no$psx doesn't seem to have an option to log CPU activity to a text file
Anyway, thanks in advance for any leads!
PS: for additional context, I'm currently working on Goemon Shin Sedai Shuumei, which has most of the game assets packed (though uncompressed) within a single "ALLDATA.X" file. I've already managed to split this file into individual files, and repack it back to its original form, matching the original 100%.
This file is stored in Mode2/Form2. I got a pretty good understanding of sector headers by now. So far I've kept them identical to the original file, so that can't be the issue here.