-All unofficial cards have the same header (all 0x00), and thus header file can be.
-Inserting a header with diferent flash ID than that of the card's will corrupt the card.

Uses of header files:
-Transfer protected savegames from unoficial cards to unoficial cards (note that in dolphin all raw images behave as unofficial cards)
-Restore a raw image to a card with different header as long as the image and the card are the same size.

Click to expand...

WARNING: it is NOT possible to transfer a header between official cards (and thus making f-zero savegame work). The procedure only works with unnoficial cards, because they share the same serial (flash) ID.

UPDATE 11 september 2012: As of today it is possible "insert" the serial number of a memory card image or header to another memory card image or header. This makes serial protected savegames work. This has been tested even with official cards and works fine. More information here: http://gbatemp.net/t...ost__p__4384277
Still, Action Replay codes may be a better method to make serial protected savegames work, as it allows to have more than one serial protected savegame (originally from different memory cards, of course) in the same card.

-Added gamecube mode with SD gecko support (also with pso/sdload reloading support)
note: there's no SD gecko support in wii mode
-Added usb (fat32) support. Please plug only one device at a time.
-Added checks for internal SD, USB, SD gecko and memory card being inserted.
-Official memory cards are fully working in both wii and gamecube mode (previous version corrupted official memory cards when writing raw images.
-Included source of GCHeader.exe

About inseting headers and raw images:

First of all, official memory cards only accept its own header, any raw written to the official memory card wich doesn't have that card's header will render the memory card to be reported as corrupted.

So, you can change headers from official cards to unofficial cards and between unofficial cards.

Note that if an official card is formated, the header will change, but previous raw images of that card should still work.

You can still insert f-zero/Phantasy star online savegame and header to a official memory card image and it will work perfectly with dolphin.

This is implemented in order to install the f-zero savegame on another card. The option creates MemoryCardA.hdr and MemoryCardB.hdr, most like raw backup images work.

Quick setup to transfer F-zero savegame:

Put card with F-zero savegame in SLOT A
Backup F-zero savegame to GCI.
Backup header from SLOT A card.
Insert new memory card in SLOT A
Restore header and gci savegame to that card.
Enjoy your F-zero savegame.

Alternatively use GCHeader.exe to extract the header from a raw memory card backup image (command line or drag the file to executable).

You can also use GCHeader.exe to insert a header on a memory card raw image (via command line).

Yo, been a while apart from the scene ^^

So, last thing I wanted to implement to GCMM 2-3 years ago was raw mc dumping and restoring, I even bough a broad band adapter for gamecube to try the original ctr-gcs. For some reason I was never able to write the dump back, even though it was read properly; but with Dacto-Taco porting ctr-gcs to wii and dolphin being the awesome emulator it is, finally confirming my theory about F-zero savegame was possible.

Also, with tueidj modifications oficial memory cards are fixed.

Theory was: a raw dump of a card written to another card (same size) would allow F-zero savegame to be transfered.

I said it a thrillion times, nobody seemed to bother trying (and that's why I bought the broad band adapter).

Anyway, this suposes an obvious problem: only transfering to same size cards and having to write a full dump just to transfer a savegame. Here is where my modifications come useful.

The pack includes a modified ctr-gcs with the ability to extract and write the card header (block number 1). Also, It can be written to any memory card, regardless the size (header is modified and checksum recalculated before writing it).
Summing up, to transfer the F-zero savegame you have export gci save from original card AND header file, then import the gci AND header file to new card. Easy peasy.

Also included there's a windows command line tool that will extrat the header from a raw memory card (drag and drop to exe file). I can also insert a header to another card dump (via command line).

I remember to you all that dolphin includes a memory card manager that works perfectly fine with raw dumps.

By the way, this is a workaround, the propper way would be modify the f-zero savegame and change the flashid to the cards one, but as I haven't been able to find it in the save (and changing it would probably need changing the savegame's checksum too)

And now, does anyone know any other game that uses savegame protection? I mean real protection, not just permisions like pokemon coloseum, which transfers just fine in GCI.

Phantasy Star Online(Episode 1&2 at least, I would assume 3 is the same way) has save protection similar to F-Zero's, I believe. I could be wrong, though. It seems to refuse to work from a new memory card, even if you backup and move all 3 save files it makes(without doing this new method you've come up with). I could've done it wrong though, however.

I tested GCHeader with PSO, taking the header from my 251(2mbyte) official memory card dump, and moved it to a 16mbyte image created by Dolphin, and it worked, as expected. I successfully moved my save to the larger memory card with no issue.

I'll try the updated CTR-GCS dol in a minute.

Also, a random thought: Wouldn't this let you restore raw images to another memory card with no issue? Couldn't you just do the following, if you bought a new card for example:
1. Backup flashid header & raw image of memory card A
2. Restore raw image A to memory card B
3. Restore flashid header of memory card A to memory card B

I tested GCHeader with PSO, taking the header from my 251(2mbyte) official memory card dump, and moved it to a 16mbyte image created by Dolphin, and it worked, as expected. I successfully moved my save to the larger memory card with no issue.

Click to expand...

Thanks for testing, glad to know it works.

It would be interesting to know all games that use this type of protection and their gamecode (it is written to the gci filename when extracting with ctr-gcs)
The idea is to use the gamecode to auto-extract the header file when backing up the savegame to GCI (and save it along the GCI, with the same filename).

I'm not so sure about auto-installing the header, but with a propper warning it should be fine.

The card ID is only the first 20 bytes (12 bytes scrambled + 8 byte PRNG seed) so you could just copy those over (and then fix the header checksum) if you wanted to transfer between different size cards.
I'm also curious if you're using a fixed version of libogc - the sramex struct is incorrectly defined (flash id checksum is only 1 byte for each slot, not 2) which can cause problems if the card is already unlocked.

I tested GCHeader with PSO, taking the header from my 251(2mbyte) official memory card dump, and moved it to a 16mbyte image created by Dolphin, and it worked, as expected. I successfully moved my save to the larger memory card with no issue.

I'll try the updated CTR-GCS dol in a minute.

Also, a random thought: Wouldn't this let you restore raw images to another memory card with no issue? Couldn't you just do the following, if you bought a new card for example:
1. Backup flashid header & raw image of memory card A
2. Restore raw image A to memory card B
3. Restore flashid header of memory card A to memory card B

Click to expand...

The header is already in the raw backup, if you restore a raw backup to another card the protected saves will work the same. This has been posible in gamecube for many years (but again, nobody tried it)

If you mean restoring a raw image to a card of a different size, that's a bad idea, you'd be better managing your savegames on PC with dolphin's memory card manager, then add the header to the raw of the card with gcheader.exe, for example.

The card ID is only the first 20 bytes (12 bytes scrambled + 8 byte PRNG seed) so you could just copy those over (and then fix the header checksum) if you wanted to transfer between different size cards.
I'm also curious if you're using a fixed version of libogc - the sramex struct is incorrectly defined (flash id checksum is only 1 byte for each slot, not 2) which can cause problems if the card is already unlocked.

Click to expand...

I know, but I went by copying the full block (it's only 8kb anyway) and editing the card size because I only have to write 1 time to the card. Your way is probably cleaner, but more complicated and my programming skills are... well very bad. Also reading/writing the whole block was quicker, as I just had to slightly modify the backup/restore functions of ctr-gcs.

About libogc, I'm using the same setup as savegamemanager-gx. Your version of ctr-gcs has proper dsp unlocking, so official cards work the same. I saw your commit to libogc, but I think the sramex structure isn't fixed yet right? I should recompile with latest libogc and fix the structure... gonna do it right away.

I wanted to recompile anyway, I want to add gamecube mode with sdgecko support.

Actually now that I think about it, this won't work if official memory cards are used. The reason is the flash id in the header is a scrambled version of the real flash id (the one that gets written to nand). The real flash id is obtained during the unlock function and there's no way to copy that from one card to another. If the real flash id doesn't match the descrambled flash id from the card header, the card will be rejected by games as needing formatting. Unofficial cards all use zeroes for their flash id so there's no problem copying headers between them.

If the headers from the two saves are from different memory cards, it'll probably break PSO.

Consider this:
A) PSO is on memory card A
B) FZero is on memory card B
C) We have a third different image(we'll call it memcard C)

If we restore the GCI of PSO and F-Zero to memcard C, then put F-Zero's header(memcard B) on memcard C, I would imagine that PSO(memcard A) would see the saves as "corrupt" since the header would no longer match its original memcard A header.

Now consider this situation:
A) PSO is on memcard A
B) F-Zero is on memcard A
C) We want to move them to a new memcard image, memcard B

If we move the GCIs over and then just replace memcard B's header with memcard A, it should have no issue. It's the first scenario that would/should give you problems.

Note that the scenarios I'm talking about here are only dealing with memory card images, not real memory cards.

Also, the test I did with PSO was with two memory card images, not real memory cards.

Actually now that I think about it, this won't work if official memory cards are used. The reason is the flash id in the header is a scrambled version of the real flash id (the one that gets written to nand). The real flash id is obtained during the unlock function and there's no way to copy that from one card to another. If the real flash id doesn't match the descrambled flash id from the card header, the card will be rejected by games as needing formatting. Unofficial cards all use zeroes for their flash id so there's no problem copying headers between them.

Click to expand...

That's depressing to read, I tested with an unoficial card. Well, at least we can copy the savegame to any unoficial card.

Then changing the hader of an official card will only break the card and there's no software solution for that? If that's so, we are again at the point of needing to change the ID in the savegame itself...

Do you know how to get the real flash ID from the header scrambled one?

Actually now that I think about it, this won't work if official memory cards are used. The reason is the flash id in the header is a scrambled version of the real flash id (the one that gets written to nand). The real flash id is obtained during the unlock function and there's no way to copy that from one card to another. If the real flash id doesn't match the descrambled flash id from the card header, the card will be rejected by games as needing formatting. Unofficial cards all use zeroes for their flash id so there's no problem copying headers between them.

Click to expand...

That sounds interesting, however...

I tried to follow this tutorial in order to copy my F-Zero GX from an unofficial memory card (1019 blocks) to an official one (251 blocks).
Thanks to suloku tools I managed to create a raw image with all my savegames from the 251 official, I changed its ID and then added my F-Zero GX savegame. Dolphin reads it correctly, but it's impossible to restore it to my 251 official using ctr-gcs (no matter what version I use, tueidj's or suloku's). It's always corrupted after restoring it.

At first I thought it was related to tueidj's post here, but then I tried to restore my ORIGINAL (not modified) RAW to the 251 official and it gives me the same problem: the memory card is corrupted after restoring the RAW.

I don't care about the savegames lost there because I have a copy of all of them.

I tried to restore f-zero gx save and header from a third party memory card (nyko 123 blocks) to a official nintendo memory card (251 blocks) without success, it gets corrupted. Need to re-format while starting the game or going to data management.

I tried to restore f-zero gx save and header from a third party memory card (nyko 123 blocks) to a official nintendo memory card (251 blocks) without success, it gets corrupted. Need to re-format while starting the game or going to data management.

Click to expand...

It seems you have the same problem as me.
Do you have an original RAW (not modified) of your official memory card? Have you tried to restore it?
Main problem here is that even the original one doesn't restore correctly in my official 251.

Yes, I tried to restore the raw dump of my official memory card but unfortunately its the same problem. Only transfering individual gci files from certain games its the only way to make it work without corrupting it.