6.x crypto save files on emunand

Discussion in '3DS - Flashcards & Custom Firmwares' started by lambstone, Jan 7, 2014.

  1. lambstone
    OP

    lambstone No. Nyet. 不. Non. Nein.

    Banned
    615
    167
    Aug 14, 2011
    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?
     


  2. hashcheck1

    hashcheck1 GBAtemp Fan

    Member
    424
    125
    Aug 5, 2013
    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?
     
  3. Huntereb

    Huntereb GBAtemp Addict

    Member
    2,748
    949
    Sep 1, 2013
    United States

    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 likes this.
  4. hashcheck1

    hashcheck1 GBAtemp Fan

    Member
    424
    125
    Aug 5, 2013
    love the pic above!!
     
    Huntereb likes this.
  5. lambstone
    OP

    lambstone No. Nyet. 不. Non. Nein.

    Banned
    615
    167
    Aug 14, 2011
    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.
     
  6. Huntereb

    Huntereb GBAtemp Addict

    Member
    2,748
    949
    Sep 1, 2013
    United States

    Dunno how it works, it just expects something that isn't there. Ask Nintendo, I'm sure they're be glad to share. :rofl2:
     
    hashcheck1 likes this.
  7. lambstone
    OP

    lambstone No. Nyet. 不. Non. Nein.

    Banned
    615
    167
    Aug 14, 2011
    Yeah the ongoing theory is different cryptography used in different firmware revisions for save files.
     
  8. profi200

    profi200 Banned

    Banned
    330
    216
    Sep 3, 2011
    Gambia, The
    How often? It can't be fixed. It's pointless, what some ($$$)company promises, this never will be fixed until the bootrom is dumped.
     
  9. nervx

    nervx GBAtemp Fan

    Member
    308
    45
    May 29, 2006
    Canada
    someone should ask the gateway team about this and if they'll be able to fix it then post the response on the forum.
     
  10. gamesquest1

    gamesquest1 Nabnut

    Member
    14,134
    9,477
    Sep 23, 2013
    What's stopping you?
     
  11. mathieulh

    mathieulh GBAtemp Fan

    Member
    335
    394
    Feb 28, 2008
    France
    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.
     
  12. Huntereb

    Huntereb GBAtemp Addict

    Member
    2,748
    949
    Sep 1, 2013
    United States

    Do I smell converting broken saves maybe?
     
  13. mathieulh

    mathieulh GBAtemp Fan

    Member
    335
    394
    Feb 28, 2008
    France
    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.
     
  14. Huntereb

    Huntereb GBAtemp Addict

    Member
    2,748
    949
    Sep 1, 2013
    United States

    But maaaaybeeee...?
     
  15. mathieulh

    mathieulh GBAtemp Fan

    Member
    335
    394
    Feb 28, 2008
    France
    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.
     
  16. Huntereb

    Huntereb GBAtemp Addict

    Member
    2,748
    949
    Sep 1, 2013
    United States

    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).
     
  17. profi200

    profi200 Banned

    Banned
    330
    216
    Sep 3, 2011
    Gambia, The
    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.
     
  18. gamesquest1

    gamesquest1 Nabnut

    Member
    14,134
    9,477
    Sep 23, 2013
    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
     
  19. profi200

    profi200 Banned

    Banned
    330
    216
    Sep 3, 2011
    Gambia, The
    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.
     
  20. mathieulh

    mathieulh GBAtemp Fan

    Member
    335
    394
    Feb 28, 2008
    France
    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.
     
    ground likes this.