- Joined
- Oct 1, 2010
- Messages
- 645
- Trophies
- 1
- Age
- 31
- Location
- where the wind makes the curve
- XP
- 2,599
- Country
What is meant by "rename the sav to game title ID"?
Is the ID of the new header used on the 3dz file?
What is meant by "rename the sav to game title ID"?
Is the ID of the new header used on the 3dz file?
Btw, just defrag the SD card, and you wont get the error anymore. Any time you get that error, just defrag the SD card. A small pain that is totally worth for using GW
https://www.piriform.com/defraggler
Regards,
Zananok
hopefully someone will be able to figure it outOkay I'm calling for experts now ^^
Here joined you have 2 saves .
- AMGP.ZIP -> Metal Gear 3DS EUR 128ko file (retail save dumped)
- 0004000000082400.ZIP -> Metal Gear 3DS EUR 512ko file generated by the Gateway when it creates a save
EDIT : Seriously, I didn't get nothing on Hex Editor, it seems there is no similarity ... (i'm not used to that either), please help ^^
I was hoping someone might be able to make a Homebrew App. like to do something like put your old .sav files in it from your .3ds roms and convert them working to the .3dz roms cause I have not got a scooby doo which .sav files belongs to which rom????????????. The dates are all mad up on my SD card and none make any sense to me at all and also to boot seen as though I have like 30 old .sav files its like looking for a needle in a hay stack, as they say!
I was hoping someone might be able to make a Homebrew App. like to do something like put all your old .sav files in it from your .3ds roms and convert them working to the .3dz roms cause I have not got a scooby doo which .sav files belongs to which rom????????????. The dates are all mad up on my SD card and none make any sense to me at all and also to boot seen as though I have like 30 old .sav files shoved on my SD card its like looking for a needle in a hay stack, as they say! Its a real pain that none of my old .sav files work on the new .3dz roms
yes, that is how it works (at least, what everyone here agrees on being the case)If my assumption of how it works is right (which is that GW was programmed to ignore the header for .3ds),
It means that the .sav are encrypted differently.
So it's an decryption-reencyption issue,
which is why when loading it says "corrupted",
but can be played when reverted back to .3dS, even after header insertion.
If my assumption of how it works is right (which is that GW was programmed to ignore the header for .3ds),
It means that the .sav are encrypted differently.
So it's an decryption-reencyption issue,
which is why when loading it says "corrupted",
but can be played when reverted back to .3dS, even after header insertion.
Agree in that there are people out there who know how the save decryption/encryption works for 2.x+ keys but for various (and mostly pointless) reasons they won't share the information. I think Gateway could also 'fix' it by just faking the eeprom space on 128kb save games.
It's frustrating because this is mostly a problem (save games) for people who actually buy and play retail games and want to move them to Gateway simply for the convenience of multi-rom. At least Gateway took the first step by providing a method to actually backup/restore game saves so that is something.
Any time I bring up the lack of progress or the slow progress in the 3DS scene I usually get trashed and called ungrateful...... which cracks me up as all I am doing is pointing out the facts which is this scene is moving at a snails pace, really only has one primary contributor (gateway), and seems to lack passion where the 'open' source developers are concerned. This is not a diss to Gateway or SMEA or anyone else for that matter, it is just an observation/commentary based on my experiences of more than 3 decades of gaming and hacking/modding shit. Eventually (as usual) we will get these save/rom tools and likely get an 'open' CFW that runs games from the SD slot......I just wish there was more interest, and more contributors.
source : http://www.3dbrew.org/wiki/Savegames2.0.0-2 Hashed keyY and 2.2.0-4 Savegame Encryption
When certain NCSD partition flags are set, a SHA-256 hash is calculated over the data from the CXI(same data used with the original plain keyY), and the 0x40-bytes read from a gamecard command(this 0x40-byte data is also read by GetRomId). The first 0x10-bytes from this hash is used for the keyY. When flag[7] is set, the CTR will never repeat within the save image, unlike the original CTR-method. All games which had the retail NCSD image finalized after the 2.2.0-4update(and contain 2.2.0-4+ in the System update partition), use this encryption method.
This keyY generation method was implemented with 2.0.0-2 via NCSD partition flag[3], however the proper CTR wasn't implemented for flag[7] until 2.2.0-4. The hashed keyY flag[3] implemented with 2.0.0-2 was likely never used with retail gamecards.