I've been told that they've since redumped most of these images, but the bad images are still apparently floating around.
It seems that all sides of the images have block 1 0x1f-0x37 zeroed out, and all sides after the first contain a tool string.
So basically, it's DiskDude!, but this time in an actual part of the game itself that games can read if they wanted to.
I'm most concerned about the actual side byte that is zeroed out by this. The dates could be displayed onscreen in a game, and the values would no longer be valid BCD values.
higan operates in two modes: one is that the original file is parsed, I add back the gaps and checksums if they're missing, and I write out each side into per-game folders. The other is that I hold the transformed data in memory. Either way, the original files are never modified.
So, I'm asking here to get people's input: is it a good idea or a bad idea to try and repair the headers via an opt-in setting in my emulator?
The idea would be to collect a set of game hashes + known-good headers into a database, by scanning against the latest No-Intro set. When I find a match and see the "hCON" string, I'll restore the header with the copy from the database.
The tricky part is, how to compute a hash that's valid for both images. Because I can't know for certain which blocks are save data and may have been modified. I could probably match based on header bytes 0x00-0x1e alone?
The trickier part is, what if there's no match in the database? I hacked together a quick simple repair that will at least get us valid dates and disk side information, on the off chance a game tries to read that data and possibly display it on screen.
But the ethical concern here is that there's an infinitesimal chance someone actually uses higan, and then an even smaller one they use it for FDS emulation, and then an even smaller one that they try and reseed these "repaired" images, and it may not be immediately obvious that a repair was attempted, and may fool someone into thinking it's a clean image whereas the "hCON" version is obviously tampered with.
If the majority view here is that I shouldn't do this, I'll gut the code out.
So, thoughts?
Code: Select all
for(uint index : range(size() / 65500)) {
auto side = &data[index * 65500];
if(memory::compare(&side[0x20], "hCON by hal9999", 15)) vandalized = true;
}
if(!vandalized) return;
//attempt to rebuild block 1 header for all disk sides
for(uint index : range(size() / 65500)) {
auto side = &data[index * 65500];
//zero out the vandalism
for(uint index = 0x20; index <= 0x37; index++) side[index] = 0x00;
//repair damage as best we can: the values won't be correct, but at least they won't be invalid
side[0x1f] = 0x61; //1986 (Shouwa 61)
side[0x20] = 0x01; //January
side[0x21] = 0x01; //1st
side[0x22] = 0x49; //country code: Japan
side[0x23] = 0x61; //unknown (constant?)
side[0x26] = 0x02; //unknown (constant?)
side[0x2c] = side[0x1f]; //rewritten date
side[0x2d] = side[0x20]; //same as manufactured date if never rewritten
side[0x2e] = side[0x21];
side[0x2f] = 0xff;
side[0x30] = 0xff;
side[0x31] = 0xff;
side[0x32] = 0xff;
side[0x33] = 0xff;
side[0x35] = index & 1; //disk side (0x00 = side A, 0x01 = side B)
}