Patching game executables

[MichiS97]

Hi all,

so I have a lot of experience making ASM based cheats for a lot of systems but I have next to zero experience with the Saturn, maybe someone here will be able to help me 🙂
Yesterday I was trying to create an infinite health cheat for Astal (I know that those cheats are out there but they are mostly RAM based and I want to make one myself by patching the executable myself). I was quickly able to find the instruction in the code that I want to change with the Ghidra loader that uses Mednafen save states. This is when I usually open the game's ROM / executable in a hex editor, look for that specific instruction, make my change and just click on save basically. This time, I found that in Ghidra, this specific sequence of instructions (I think I took around 32 bytes around the two-byte instruction that I wanted to change) appears exactly once in my save state. So I searched for this 32 byte sequence in the Track 1.bin of my game, and I found it a whopping 23 times. Basically I just guessed that the game may load a different executable depending on what level you're in or something like that, so I just replaced all 23 occurences in that bin file. Track 2 had no matches for this sequence, so I didn't edit that file. The cheat seemed to work flawlessly on my Saturn, after copying the modified track 1 bin to my Fenrir.

However, out of curiosity I extracted the original bin/cue image with Sega Saturn Patcher and did a binary search for the original 32 byte sequence and found it in 25 files (one occurrence of the pattern in each of those 25 files). When extracting my modified image from before, I also found the sequence in two additional files. So there seems to be two "missing" occurrences of this pattern in the full image when compared to the extracted image.

I guess my question is, if these two occurrences of this byte sequence seemingly aren't to be found in the original track 1 binary and also not in the track 2 binary, where do they come from? 😀 I haven't worked on CD based systems a lot so I don't know much about the file formats. Could some parts of the disc be compressed while others aren't? I guess that would be why only two of the 25 occurrences of this byte sequence would not be found in the complete binary, because they might be in a compressed section of the image that only gets decompressed when you extract the image. But that is really only guesswork right now.

Does any of that make sense to you? Am I asking stupid questions?
I'd love to get your feedback.

 

[derek (ateam)]

Cool, good luck with your future hacking endeavors!

That said, firstly you should really avoid making direct changes to a BIN data track (presumably a Redump image) outside of quick testing. ECC data is still in tact (unless you manually regenerate it), and this means that more than likely, someone who would burn your disc image would have either a broken or totally non-functional patch (i.e., the original data would be restored). Some emulators and ODEs fake this data, by the way. In fact, I remember a case (I believe it was Blast Wind) where the patch author made direct changes to the data track BIN and was baffled by them not being reflected in the game itself with a certain ODE, while other ODEs were fine.

Instead, you can either use Sega Saturn Patcher to patch one or more files, or for development/testing something like cd-replace can be used (I prefer this, to be honest). With cd-replace, via CLI you can inject modified versions of one or more files to overwrite the original(s), and all data is shifted around accordingly. It's also very fast!

Now, regarding why you could find that pattern more in the BIN than in the original executable, it can be a combination of redundancy (remember that ECC I mentioned?), multiple sector copies, or overlap. The format isn't like ISO, or like a direct, raw ROM you might be used to. For instance, if a given file spans sectors, and the byte array you want to change "straddles" a sector boundary, part of (or all of) that array could appear in adjacent sectors, though partial duplication is more typically seen.

I hope that helps.

 

[MichiS97]

Cool, good luck with your future hacking endeavors!

That said, firstly you should really avoid making direct changes to a BIN data track (presumably a Redump image) outside of quick testing. ECC data is still in tact (unless you manually regenerate it), and this means that more than likely, someone who would burn your disc image would have either a broken or totally non-functional patch (i.e., the original data would be restored). Some emulators and ODEs fake this data, by the way. In fact, I remember a case (I believe it was Blast Wind) where the patch author made direct changes to the data track BIN and was baffled by them not being reflected in the game itself with a certain ODE, while other ODEs were fine.

Instead, you can either use Sega Saturn Patcher to patch one or more files, or for development/testing something like cd-replace can be used (I prefer this, to be honest). With cd-replace, via CLI you can inject modified versions of one or more files to overwrite the original(s), and all data is shifted around accordingly. It's also very fast!

Now, regarding why you could find that pattern more in the BIN than in the original executable, it can be a combination of redundancy (remember that ECC I mentioned?), multiple sector copies, or overlap. The format isn't like ISO, or like a direct, raw ROM you might be used to. For instance, if a given file spans sectors, and the byte array you want to change "straddles" a sector boundary, part of (or all of) that array could appear in adjacent sectors, though partial duplication is more typically seen.

I hope that helps.

About making changes to the bin, yeah, I figured as much. The reason I extracted the image after doing that first patch was that it just kind of felt dirty 😀

You definitely helped me out a ton, thank you!