Anybody w/ experience with save hex editing?

[TheLegendaryJames]

So a while ago I decided to buy a DexDrive 64, GameShark 3.2 64, and an Everdrive 64 so I could have a lot of options to play my N64 games on. I bought the Dexdrive so I could convert my official cart saves to an .eep or .sra native save file format. I have successfully converted a DK64 and SM64 .N64 save file format to .eep/.sra via HxD, a hex editor. For those who don't know DexDrive saves (.N64) are almost like .MPK, but usually smaller. Basically what I've been doing is downloading other .eep/.sra formats of a game I have and comparing it to the .N64 dex save and stripping away the unneeded bytes and then renaming the .N64 file to .eep or .sra. Lately though I have gotten stuck on converting my Banjo-Tooie save. Every .eep I compare it to the data starts at the string ".€h", but it's nowhere to be found in my save file. Iv'e also noticed that the Banjo-Tooie .eeps are usually 800 in length. I have about 22 hours in Banjo-Tooie and I've already lost my data in this game before and I would really like to finish it, so if someone would be kind enough or even try to attempt to convert the save file it would really mean a lot to me. I'll attach a zip with the saves. My original save is called "BANJOTOOIE22" and the other 3 saves are a 100% complete game, a mid-complete game and a freshly new started game. If you have any questions about anything please ask and again thank you for checking this post out.

[HatCat]

Actually, I just used N-Rage's DirectInput plugin to export A64 files from MPKs and N64s. (This feature was removed in the XInput fork of N-Rage's plugin.) Bear in mind that A64 files are text-based and not binary; you'll see the hex but in ASCII characters stored in a plain text file.

If you just want a binary export though, doing that yourself with things like HxD is easy.

First off, Banjo-Tooie EEPs are not 800 bytes in length; they're 2K and Project64 likes to truncate EEP files down to save a few bytes of disk space if the ending of the file is just a bunch of null bytes.

Second, go to 0x0300 in the MPK file (if it's N64 the offset might be different). You can have up to 16 game notes because there are 16 32-byte blocks from 0x0300 to 0x04FF; i.e., 0x0300 to 0x031F is note 1, 0x0320 to 0x033F is note 2, etc.. Offset 0x17 into each 32-byte block stores the memory offset index for the respective note...so if note_header[0x17] is 0x05 then the first page of the note starts at 0x05 << 8 or 0x0500 bytes deep into the mempak.

[HatCat]

...Or you can just look for KHJC. Those 4 ASCII characters should be the magic number bytes beginning the Banjo-Tooie save.

Or at least that's what I noticed when I wrote my own save editor for Tooie.
https://github.com/cxd4/tooie-save-e...er/main.c#L119

Try to work with MPK files instead of N64 ones if you can. The MPKs are more accurate with each page being 0x0500, 0x0600, ... 0x7F00 (always 256-byte-aligned). N64 is something custom.

[TheLegendaryJames]

I don't really have a choice to use the MPK format unfortunately because the dexdrive only transfers saves in N64 format. Unless I export the save from the .N64 format using N-rage V2 as a .A64 file then import it back into a .MPK. Either way I think my game is corrupt because I exported it as an A64 then copied the first row of numbers to match what is in HxD and I stripped the rest, and it has my minigames still unlocked, but my actual game save file says "empty". Also I tried exporting the N64 save back into my memory pack and then into the Banjo-Tooie Game Pak via gameshark and it shows the same thing, mini games and bosses unlocked actual story mode file, gone. Not sure what to do now. Weird though because I still have the "KHJC" in my save.

[TheLegendaryJames]

If anyone wants to look at the files; .a64, .n64 (save), and .eep, here they are. I stripped the .eep off of the mpk file. To me it looks corrupted compared to other Banjo-Tooie save files. Other Banjo-Tooie save files usually have a pattern that repeats itself after the KHJC, but for whatever reason it's not there (probably due to the piece of shit DexDrive) not transferring all the data. Yet I find it funny that I played around with it so much that I actually got the menu screen to show my save, but when I loaded it hell was unleashed.

[HatCat]

Originally Posted by TheLegendaryJames

I don't really have a choice to use the MPK format unfortunately because the dexdrive only transfers saves in N64 format. Unless I export the save from the .N64 format using N-rage V2 as a .A64 file then import it back into a .MPK.

You could do that.

In fact I had written a utility back in 2012 (a very, very long time ago in some very, very shitty coding that I'd like to not share) that manages MPK files--exports/imports notes, renames them, even defragments them had I finished the thing.

Originally Posted by TheLegendaryJames

Either way I think my game is corrupt because I exported it as an A64 then copied the first row of numbers to match what is in HxD and I stripped the rest, and it has my minigames still unlocked, but my actual game save file says "empty". ... Weird though because I still have the "KHJC" in my save.

Yes, because the very first beginning block of bytes in the Banjo-Tooie EEPROM is global data--unlocked bosses/cinema and mini-games, multiplayer features etc..

So if you still have all your mini-games and unlockables (read from the first few bytes in the EEP) but not any file data (read from latter blocks), that suggests you cut off your end point too early in the N64/MPK file where you extracted it.

Remember like I said that the save chip for Tooie is 2 KiB. If you rip it out from a starting point at 0x500 bytes deep into the MPK/N64 file, the ending point should be 0x0CFF. If it starts at 0x0600, then it ends at 0x0DFF. If 0x1000, then 0x17FF. Etc.

If you're still having trouble I'll have a look at the N64 file myself when I get home from work.

[TheLegendaryJames]

Please do, I was literally up all night trying to fix this file and then I had to get up up 8. If you do decide to check the files out, it would mean a lot to me. Thanks for explaining a lot of this stuff to me as well, it's actually almost a learning experience since I've never actually used a hex editor.

[HatCat]

There is an error in my explanation about the string "KHJC". It is indeed the magic number for prefixing valid save slots in Banjo-Tooie, but it does not preface the entire EEPROM save chip data--only the save slot blocks of memory within the file (and the one currently signaled to the game's protection against save hacking through this stupid mechanism the game does to throw off hackers).

The actual beginning bytes to the entire EEPROM save file as a .eep file to Project64 are just a few bitfields encoding the widescreen mode setting and the X/Y coordinate offset screen adjustment of the game for TVs, which is not something reliable for identifying the beginning of the save file.

So I took a look at your MPK file's index node mapper section and worked out through the MPK file format that the save starts at 0x0500 deep into the MPK file.

Likewise, for your original BANJOTOOIE22.n64 file from your first ZIP attachment, the file starts at 0x1540. Why, I don't know. I never reverse-engineered the DexDrive mempak format, just the real N64 one. It appears from your data that the DexDrive file format, starting at offset 0x1040, generally is identical from that point onwards with the N64 mempak file format in the MPK files starting at 0x0000 from the beginning. (In other words, just as I originally surmised years ago when I was converting DexDrive .n64 save files off the GameFAQs website, the DexDrive save format is actually a bloated superset of the real N64 mempak format...yours is only smaller than the MPK file because not all 123 pages of the controller pak file are being reserved, so it saves disk space by truncating the file to the pages that are in use.)

So here is your solution in both formats:

• In the .MPK file, extract all the bytes from NEW.mpk offset 0x0500 down to 0x0CFF to create a 2-KiB EEP file.
• In your .N64 file, extract all the bytes from 0x1540 (0x0500 + 0x1040) down to 0x1D3F (0x0CFF + 0x1040).

Either of those must create the real working save chip contents loadable into N64 emulators.

[TheLegendaryJames]

Tried both of those methods and they didn't work. The BANJOTOOIE.N64 file isn't even long enough to even have the 0x1D3F offset, it ends at 0x1C3F, so I added zeroes from that offset until I got to 0x1D3F and that didn't work. On the MPK file as soon as I got to offset 0x0C00 to 0x0CFF I was just copying "FF" (blank data?) and that didn't work restore my game either. I honestly think that a lot of the data got scrambled when it was transferred which is why the end results end up not looking like other Banjo Tooie eeps. I guess it's safe to say corrupt forever?

[HatCat]

Originally Posted by TheLegendaryJames

I honestly think that a lot of the data got scrambled when it was transferred which is why the end results end up not looking like other Banjo Tooie eeps.

You are absolutely correct. I realize now that it's corrupt.

No, it's not corrupt forever. I know how to repair it manually, but I didn't suspect this sooner.

What the game is doing is storing 4 game save file blocks...game 1 at 0x100 (added to the 0x0500 offset into the MPK file of course) to 0x2BF.

• game 1: 0x100 to 0x2BF
• game 2: 0x2C0 to 0x47F
• game 3: 0x480 to 0x63F
• game 4: 0x640 to 0x7FF

Each is 448 bytes or 1C0_16 hex.

Now Banjo-Tooie only lets you save in 3 game saves, and the 4th is Rareware's anti-hacking scheme I'd discovered hit many times while creating the save editor. Game 4 is a spare slot that buffers the last game you just saved at (1/2/3) over to that location, while destroying the first 64 bits of game 1/2/3 to 0s. When game initializes, it compares which of the 3 game slots has 64 bits destroyed and uses game 4 as the source buffer to restore it with.

If ANY of the 4 game slots are found invalid (checksum, missing magic number, bad/truncated block size, ...) the game wipes the entire set of all 3 game saves from what I've experienced way back then and makes you start over completely. It was a pain in the ass to write a save editor for Tooie.

Now doing the math, your MPK note save for Tooie is corrupt indeed. Game 4 in the MPK file starts at 0xB40 and should end at 0xCFF, but, as you say, those were all 0s because the N64 file your DexDrive created cut off before that point with a prematurely truncated file. Those bytes have been lost.