Hacking 3DZ saves are locked and canot be transfered to other dumps?

[cearp]

before making use of the header data, we could share saves amongst each other right...
but now, if we were each to use our own dump/header data, and rename it 3dz to enable it, these saves are now locked to the header data right?

so if we rename the 3dz to 3ds, so that the header data is ignored, the save data will not work. correct?
i saw somewhere, i think, there is a sava data tool for encryption/decryption, maybe for only older saves or something...?

at least, is there any way at the moment that we can fix this?
is this all about the unique console aes mac key? was it not being used when the header data was not used?

thanks

 

[Saturosias]

If you and the other person are using the same modified header, it should work just fine. Only reason it'll be more "difficult" to share saves now is because people will be likely to perform the procedure themselves with their own other ROM header, unless a patcher is made for each ROM and it doesn't incite DMCA takedowns.

 

[The Real Jdbye]

The saves are locked to the ROM dump used, only way around this problem is to use ROM Cleaner to add the header data to the scene releases instead so they can be used online.
The "header data" is not the problem here. The problem is that each cartridge uses its own savegame encryption, but since we're all using the same scene release, we're practically using the same cartridge, therefore saves can be shared.

 

[cearp]

The saves are locked to the ROM dump used, only way around this problem is to use ROM Cleaner to add the header data to the scene releases instead so they can be used online.
The "header data" is not the problem here. The problem is that each cartridge uses its own savegame encryption, but since we're all using the same scene release, we're practically using the same cartridge, therefore saves can be shared.

and that unique data it uses to make it's own encryption is from the header right...? if not, what else?
is this exactly the same reason that people with powersaves, for example, cannot use other people's pokemon (or any game?) saves?

 

[MelonGx]

The saves are locked with their own ROM until somebody cracks the 3DS savegame encryptions in future.

 

[The Real Jdbye]

and that unique data it uses to make it's own encryption is from the header right...? if not, what else?
is this exactly the same reason that people with powersaves, for example, cannot use other people's pokemon (or any game?) saves?

The header mentioned contains a cartridge ID of some sort, I don't know if it contains anything else useful. The cartridge ID is not used to determine the encryption key. That's not the only header, either. I think the data used for it is in the header at the very beginning of the ROM (that is where the NCSD header is contained, to my knowledge)
The encryption key is made based on a complex set of rules that no one has figured out yet (at least to my knowledge), that's why the only way to modify saves or make them work on another cartridge so far has been to trick the 3DS hardware into doing the job for you.

And yes, that's why saves cannot be transferred between ANY cartridges. The encryption differs, it should be relatively hassle free to code a 3DS homebrew to decrypt and re-encrypt saves to work on other carts in the future, once someone figures (and documents) out the steps needed to call the hardware keyscrambler in the 3DS with the correct information to generate a valid key.

 

[Cyan]

the CartridgeID (used for online identification) is not the same things as the Cartridge Encryption key for Game and save encryption key for savegames.
Nintendo doesn't provide the encryption key in clear text inside the ROM.

The CartridgeID is NOT in the header.
Gateway put that data in the header! (which makes ROMS dump no longer clean dump).

I think, The CartridgeID is retrieved by asking the cartridge to provide it. GW just happen to store it in the header in a (currently unused) location for convenience to get that string without the cartridge inserted.
But the game doesn't use that data located in the header to accept or block savegames.

 

[drfsupercenter]

This only applies to CARD1 games, correct?

I can confirm that using Scene dumps of Pokémon X or Pokémon Y (They aren't interchangeable, tried that too), you can make a save on CONTRAST's ROM (European region), then inject it into ABSTRAKT or KIRIN (USA, Japan respectively) and it will work perfectly fine. And obviously all 3 of those were different cartridges.

(Though interesting to note, Kirin's dump of X has some save data in it, I had to use UP+B+X to wipe it, as the 3DS said the save data was corrupted when I tried to start a new game using their dump)