Hacking 6.x crypto save files on emunand

[lambstone]

Recent weeks there have been fantastic developments in the 3ds hacking and modding scene.

However it seems that with emunand still uses the 4.x crypto keys for save games in nand based titles like pokemon x/y. This means that when you create a save file on a 6.x sysnand and then try to run it on on emunand it shows up as incorrect.

I'm almost ready to jump ship and get a 4.5 3ds but if I have to sacrifice my pokemon y game save...

Is there any work around?

 

[hashcheck1]

i don't understand this issue! I have done a manual system transfer (nand backup and emunand windows tool) with eshop Zelda & Animal crossing my saves work perfectly. They were created on a legit 7.3 3dsXL

How come i didnt see this issue? becuase eshop games not physical?

 

[Huntereb]

How come i didnt see this issue? becuase eshop games not physical?

Only physical carts do this.

I'm just running a corrupted save on Emunand now. when it's fixed I'll just use Pokebank to tranfer my good pokemon (If there isn't an issue with my save file, that is). I was in it for the story anyway, and it was a good one.

 

[hashcheck1]

love the pic above!!

 

[lambstone]

Only physical carts do this.

I'm just running a corrupted save on Emunand now. when it's fixed I'll just

Yeah, wonder if this issue can ever be fixed. It's really strange because if emunand is still using 4.x crypto for the save file like many have reported, pokemon x used 6.x crypto. Trying to load pokemon save on emunand wouldn't work because of different save file crypto.

Assuming that this is true. By all accounts 7.x official system nand should be using 7.x crypto and should not be able to load pokemon x save files due to different crypto.

 

[Huntereb]

Yeah, wonder if this issue can ever be fixed. It's really strange because if emunand is still using 4.x crypto for the save file like many have reported, pokemon x used 6.x crypto. Trying to load pokemon save on emunand wouldn't work because of different save file crypto.

Assuming that this is true. By all accounts 7.x official system nand should be using 7.x crypto and should not be able to load pokemon x save files due to different crypto.

Dunno how it works, it just expects something that isn't there. Ask Nintendo, I'm sure they're be glad to share.

 

[lambstone]

Dunno how it works, it just expects something that isn't there. Ask Nintendo, I'm sure they're be glad to share.

Yeah the ongoing theory is different cryptography used in different firmware revisions for save files.

 

[profi200]

How often? It can't be fixed. It's pointless, what some ($$$)company promises, this never will be fixed until the bootrom is dumped.

 

[nervx]

someone should ask the gateway team about this and if they'll be able to fix it then post the response on the forum.

 

[gamesquest1]

someone should ask the gateway team about this and if they'll be able to fix it then post the response on the forum.

What's stopping you?

 

[mathieulh]

In order to generate 6.0.0+ savedata, a KeyY initialized by the NATIVE_FIRM version 10833 or newer is used. That key is initialized using a RSA keyslot, itself initialized by the bootrom.
The RSA keyslot is cleared when a CXI is loaded, this means that on a system where an older revision of NATIVE_FIRM was loaded by the bootrom, the keyY keyslot isn't loaded and the key required to generate the final KeyY stored in the RSA keyslot has been cleared long before your own code is running (therefore, long before 6.0.0+ NATIVE_FIRM is running from emuNAND)

This means the KeyY used on emuNAND 6.0.0. NATIVE_FIRM to generate the new 6.0.0+ savedata will always be different to the one used on 6.0.0 NATIVE_FIRM run from sysNAND. There is nothing, short of running code on a live 6.0.0. system BEFORE a CXI is loaded (this means early in the boot process), that can get you the real key.

I am studying some ventures, such as performing a reboot on the ARM9 core while keeping the ARM11 cores running but I have serious doubts as to whether this would bear any fruits whatsoever.

 

[Huntereb]

I am studying some ventures, such as performing a reboot on the ARM9 core while keeping the ARM11 cores running but I have serious doubts as to whether this would bear any fruits whatsoever.

Do I smell converting broken saves maybe?

 

[mathieulh]

Do I smell converting broken saves maybe?

Oh ! I don't care so much about the new savedata crypto (although I wouldn't mind dumping the RSA keyslots and any registers I can at boot time)

I am much more interested in dumping the actual bootrom if that's even possible. It seems rather very well protected as it's unmapped and cleared at the time we get to run anything on the system.

 

[Huntereb]

Oh ! I don't care so much about the new savedata crypto (although I wouldn't mind dumping the RSA keyslots and any registers I can at boot time)

I am much more interested in dumping the actual bootrom if that's even possible. It seems rather very well protected as it's unmapped and cleared at the time we get to run anything on the system.

But maaaaybeeee...?

 

[mathieulh]

But maaaaybeeee...?

At this point dumping the RSA keyslot and/or generating the proper KeyY for 6.0.0. games seems very far fetched. I doubt that the Gateway engineers managed to get this key either or are anything close to getting it so I wouldn't count on it.

In fact, as it stands, Nintendo could use a very similar security scheme to prevent newer ROMs from running, such as the encrypting the games' ExeFS with a new key that cannot be dumped through the rsa_verify request vulnerability used by Gateway and that isn't set/initialized by 4.5.0 NATIVE_FIRM.

Possibly the only reason they haven't done that already is because they do not care.

 

[Huntereb]

At this point dumping the RSA keyslot and/or generating the proper KeyY for 6.0.0. games seems very far fetched. I doubt that the Gateway engineers managed to get this key either or are anything close to getting it so I wouldn't count on it.

Alright then, I guess I'll just use Pokebank to store my Poke's before my game is useless in the future (If that works, like I've been saying).

 

[profi200]

Like i said, without dumping the bootrom, it is impossible.

@mathieulh:
You can't dump the Bootrom. Not even neimod with his RAM dumping setup can. The bootrom is unmapped, before you even can do anything and it can not be remapped. That is permanently disabled until you power off the system.

 

[gamesquest1]

Like i said, without dumping the bootrom, it is impossible.

@mathieulh:
You can't dump the Bootrom. Not even neimod with his RAM dumping setup can. The bootrom is unmapped, before you even can do anything and it can not be remapped. That is permanently disabled until you power off the system.

And how many times have we heard you can't and you won't down the years? Pretty sure we "couldn't" run homebrew on the 3ds.........people always forget the "yet" it might seem "impossible" but often the impossible is achieved by trying

 

[profi200]

This has nothing to do with trying. It's a fact. If sometimes the infos, how Nintendo do it, is public avialable, you will understand why. I don't go in details here. It's 100% not possible without decapping.

 

[mathieulh]

Like i said, without dumping the bootrom, it is impossible.

@mathieulh:
You can't dump the Bootrom. Not even neimod with his RAM dumping setup can. The bootrom is unmapped, before you even can do anything and it can not be remapped. That is permanently disabled until you power off the system.

I know it's unmapped and long gone before you anyone can run code. I even said so in my very posts so you are repeating what I just wrote. (Did you read my posts?)

As to why a hardware ram dump setup cannot read this, it's because the bootrom never leaves the (ARM9 presumably) cpu cache.

Why do you think I mentioned resetting the ARM9 core while having a loop running the ARM11 cores ?

I never mentioned a high probability of success in this attempt did I ?

There are also other venues I'd like to explore. For instance it's fairly safe to say the bootrom is decrypted through the AES hardware engine, maybe nintendo weren't smart enough to clear the slots after the bootrom was gone, it's unlikely but it's worth looking into.