Conceptual question: Why can't we NAND swap now?

Discussion in '3DS - Homebrew Development and Emulators' started by drfsupercenter, Apr 8, 2016.

  1. drfsupercenter
    OP

    drfsupercenter Flash Cart Aficionado

    Member
    1,898
    234
    Mar 26, 2008
    United States
    I have been trying to do this for over a year and now that we finally have programs which make decryption easy (looking at Decrypt9), I don't understand, conceptually, why this still doesn't work.

    I have two hardmodded O3DS XLs (for sake of discussion - I actually have more than that!). One was bought in the US and has -U firmware, one was imported from Japan and has -J firmware. I have the OTP.bin for both.

    The hardware is identical - both have the 943MB NANDs.

    I had previously tried rxTools to inject the NAND FAT16 partition (also called CTRNAND) to the other console, which resulted in a brick. I knew there was more to a NAND backup than that, so I waited.

    Now, using Decrypt9, I can dump all(?) six partitions from either system. TWLP, TWLN, AGB_SAVE, FIRM0, FIRM1 and then the big one, CTRNAND. Looking at these in a hex editor shows that they actually do dump decrypted, as the CTRNAND as well as the TWLs are actual FAT16 images that I can read with WinImage.

    I can update or downgrade that same 3DS XL, then go back into Decrypt9 and inject the six partitions. It works.

    But yet if I put those in the other 3DS XL and try to inject, I still get bricked.

    What more is missing at this point? Clearly we can decrypt and encrypt contents freely now, and the only actual unique seed between 3DSes is the OTP, which I have for both (not that it matters when running Decrypt9)
    Clearly something has to be causing the 3DS to not like the result, and thus a brick.

    Additionally, somebody mentioned that with your console's OTP, you can decrypt the entire NAND image (you know, the 943MB one) rather than just the FAT16. But I haven't seen any proof of that or anyone actually attempting it. HAS anyone done such a thing? Or even generated a xorpad for the whole NAND rather than just the FAT16?
     
    TheKawaiiDesu and Minnow like this.
  2. mgrev

    mgrev Music Addict, Video Game Fanatic

    Member
    GBAtemp Patron
    mgrev is a Patron of GBAtemp and is helping us stay independent!

    Our Patreon
    1,835
    2,209
    Apr 13, 2015
    Norway
    Under Tomato Hentai's stairs
    the nand images are not signed
     
  3. drfsupercenter
    OP

    drfsupercenter Flash Cart Aficionado

    Member
    1,898
    234
    Mar 26, 2008
    United States
    What do you mean by that? And also, I tested it emuNAND to emuNAND too, the CFW ignores invalid signatures and it STILL soft-bricked, so that can't be the reason.

    As far as "not being signed", I don't understand. The FAT16 itself isn't signed... hence why you can get a xorpad and decrypt it. I've confirmed this, I was able to edit a file in WinImage and re-xor it and flash it back, it worked even in sysNAND. Just only on the same system.
     
  4. ih8ih8sn0w

    ih8ih8sn0w Koreaboo

    Member
    1,658
    720
    Aug 22, 2015
    United States
    Hell
    CFW ignores signatures from SD installed CIAs, not firmwares. Things in FW are console specifically signed, even after OTPs, it still has to match signatures of the console. In theory you could change all that, but its kinda pointless and you need to have OTPs from both consoles in order to convert the nand images.
     
  5. KaduPSE

    KaduPSE Revolution and cake

    Member
    235
    171
    Dec 26, 2015
    Brazil
    You can however change the region of your console using A9LHax, I've seen a method floating around here, but you won't be swapping your NAND with another console's, as in, one won't be a clone of the other.
     
  6. drfsupercenter
    OP

    drfsupercenter Flash Cart Aficionado

    Member
    1,898
    234
    Mar 26, 2008
    United States
    I do have OTPs from both consoles. Explain how I go about doing this?
    Can I take the 943MB NAND.img (which is a byte for byte backup, all sigs intact) and decrypt it using the OTP?

    Also, again... how come it works when you go encrypted -> decrypted -> encrypted on the same console? It's the decrypting and re-encrypting that would break the signatures (like cryptofixing now in CIA files)
     
  7. Noroxus

    Noroxus Margen67 Supporter

    Member
    405
    234
    Jul 7, 2013
    Germany
    Glorious Nippon
    If you wanna know more about the cryptosystem of the 3DS, I recommend you to read yifanlus article about it

    http://yifan.lu/2016/04/06/the-3ds-cryptosystem/

    Maybe this will clear up some of your questions. But yeah swapping NAND isnt as simple as dumping partitions and injecting them into another console.
     
  8. FenrirWolf

    FenrirWolf GBAtemp Psycho!

    Member
    4,347
    329
    Nov 19, 2008
    United States
    Sandy, UT
    They were able to swap nand dumps back in the Wii days, but that's because they were able to get all the keys for that console (barring the private key of course). Chances are that certain keys for the 3DS will always remain hidden behind the bootloader, but I suppose that we can never say never either.
     
    PokeAcer likes this.
  9. drfsupercenter
    OP

    drfsupercenter Flash Cart Aficionado

    Member
    1,898
    234
    Mar 26, 2008
    United States
    OK, so basically the native_firm is encrypted based on the NAND chip's serial. But isn't that FIRM0 and FIRM1? There is a native_firm inside CTRNAND but I don't think that's related.

    How can you do it via OTP? Even if you guys think it's pointless, I have my reasons for wanting to do it.
     
  10. ih8ih8sn0w

    ih8ih8sn0w Koreaboo

    Member
    1,658
    720
    Aug 22, 2015
    United States
    Hell
    OTP =/= NAND serial, you will not be able to do this at all, even with OTP (so i was wrong about it being possible)
     
  11. drfsupercenter
    OP

    drfsupercenter Flash Cart Aficionado

    Member
    1,898
    234
    Mar 26, 2008
    United States
    Well... I still don't fully understand this.

    Decrypt9 dumps the CTRNAND decrypted, right? So how does it re-encrypt it?

    Or let me word it differently. We've been able to make FAT16 xorpads for ages. And I have tested taking the encrypted full-NAND-backup, using cearp's 3DSFat16 script to extract the encrypted one, then did a xor and I was able to open it in WinImage. I modified a file or two (back when I was trying to mess with play coins), saved it, re-xored and injected back into the image. Wrote that back to the 3DS and it booted just fine. This was on sysNAND, too, not emuNAND so it wasn't a patching thing.

    So we can safely assume that the CTRNAND partition doesn't have any unique signature on it. So what makes it not work if you take a decrypted CTRNAND from 3DS A and xor it with 3DS B's? That was one of the first things I tried, over a year ago.
     
  12. Noroxus

    Noroxus Margen67 Supporter

    Member
    405
    234
    Jul 7, 2013
    Germany
    Glorious Nippon
    Pretty sure it doesnt need to "re-encrypt" it, because the CTRNAND partition is derived from your emuNAND which was created using the consoles sysNAND. Why would you need keys for something that you have already have access to? The point is that you can not swap NANDs because of console specific encryption. The emuNAND you create on your 3DS is not universal.
     
    Gray_Jack likes this.
  13. drfsupercenter
    OP

    drfsupercenter Flash Cart Aficionado

    Member
    1,898
    234
    Mar 26, 2008
    United States
    I'm talking about xorpads, not emuNAND. I can flash it back to sysNAND using the hardmod and it works fine. Using the xorpad IS decrypting it in a sense, is it not?
     
  14. Dartz150

    Dartz150 GBATemp Official Lolicon Onii-chan™

    Member
    1,406
    845
    May 5, 2010
    Mexico
    On a Strange Journey
    Well, it's very simple to understand actually... However, how to explain it easily is complex...

    Before I explain, let me clear and state that I'm not an expert on 3DS hacking nor homebrewing, so maybe I'm wrong on something, but after reading lots and lots of content on 3D Brew and the fact that I'm stufiying similar matters, that let me somehow to understand how this works. Jeez, If I had enough time I could jump into making something for the 3DS because is my main console.

    I may not use very technical information, only the necesary info to understand this better:


    Well, first, afaik, all the 3DS programs (kernel, loader, Firmware, everyting that needs to be checked by the Crypto security system) needs at minimun two checks.

    • The first in the boot by the bootloader (Contains console specific and unique keys, technically called cryptographic certificates or public keys).
    • The second by Arm9 and Procces9. (It handles if the content is properly signed to allow it to run).

    Now, let's see this in another perspective, how the Homebrew Decryption tools we have at this moment work.

    As you said above, them already are decrypted and readable once you extrat them, in your theory, the Homebrew does the procces of decryption, and thats partially true.

    The simple explanation is that the Homebrew programs only do the second step, the first is already done because we execute those homebrews after Bootloader establishes the unique console keys.

    So, the encrypted content you get after using programs such as Decrypt9 still are console dependant, as they have the signs of the unique console key, despite them being readable on the PC or another devices that aren't 3DS, and is because those stystems actually ignore such thing as a foreign crypto algorithm.

    If we want to swap NANDS or partitions, we need decrypted content but with both steps made by us, the users, and not the cosole, because we don't have access to the bootloader nor the console unique keys yet.
     
    Last edited by Dartz150, Apr 9, 2016
  15. drfsupercenter
    OP

    drfsupercenter Flash Cart Aficionado

    Member
    1,898
    234
    Mar 26, 2008
    United States
    Alright, let me ask this... when you use a hardmod to connect the NAND chip of a 3DS to your computer like a SD card... then you use a program like Win32DiskImager or dd on Linux (byte-for-byte raw copy of everything), are you saying that's not including both layers of checks?

    Because obviously you cannot take one of those backups and restore it to any other 3DS.

    But you CAN use the xorpad to decrypt your CTRNAND, modify files, re-encrypt and flash it back using that same method (byte-for-byte writing, not using homebrew or any other signature-bypassing methods). I understand what you're saying, but you're assuming I'm using homebrew to do the decrypting (which is not what I'm talking about right now!)
     
    Last edited by drfsupercenter, Apr 9, 2016
  16. Dartz150

    Dartz150 GBATemp Official Lolicon Onii-chan™

    Member
    1,406
    845
    May 5, 2010
    Mexico
    On a Strange Journey
    1. It has already been signed by the console when installed (step 1), and not only does that on install, it checks the sign integrity again at every boot.

    2.
    You're quite wrong there dude, tell me, where and how do you get the xorpads in the first place?... :creep:.


    As I said, We need yes or YES the normal key (console unique) wich is locked on the bootloader, and it'll remain there untill some research is properly done to expose, though, as I read more about the subject, that could be sooner that we can expect.
     
  17. drfsupercenter
    OP

    drfsupercenter Flash Cart Aficionado

    Member
    1,898
    234
    Mar 26, 2008
    United States
    1. Yes, I know it's already been signed by the console. But what I'm saying is you can edit the CTRNAND partition inside that big image without it breaking.
    2. Again, yes, I know... you get the xorpad itself using an entrypoint. But you're doing the actual xor operation on a computer, not using the 3DS' crypto chip itself.

    From what I understand (and the reason you can't mix and match xorpads, at least for NANDs), there is something similar to ncchinfo but in the 3DS' internal hardware that determines what the AES chip outputs.

    Using a basic example... let's say your FAT16 is binary data 11111111. 3DS #1 might have that raw data stored as 10101010, and the internal file generates 01010101 from the AES chip. The 3DS xors that to get the 11111111, and similarly if you use homebrew to generate a xorpad, your xorpad will have 01010101 as well.

    3DS #2 on the other hand, might store the raw data as 10001000, and the AES chip gives it 01110111. Different xorpad, but same end result. (Because for example, all FAT16 partitions have to start with the same stuff, it literally has "FAT16" stored in there too)

    So in theory, you could swap them easily. You'd have your decrypted FAT16 file, and either xor it with 01110111 or 01010101 depending on which 3DS you're putting it on.

    A friend did some poking around 3DBrew and I think I know why it isn't that simple.

    According to http://3dbrew.org/wiki/Flash_Filesystem - "Note that re-encrypting a NAND image alone from another 3DS for use on a different 3DS is not enough to use that NAND image on a different 3DS: certain files in the "nand" partition would need modified/replaced as well. "
    And then on http://3dbrew.org/wiki/Talk:Flash_Filesystem we have:
    • There are files on the FAT16 partition, which have signatures specific to that console.
    • They can be updated, so the keys are available to the 3DS.
    • From what's written there, the keys making the signatures are outside the FAT16, but the 3DS checks things inside the FAT16 with them, so they have to be paired.
    • Just for this, even if no other issue, you'd probably need some 're-pairing' homebrew to fix that.
    I'm not entirely convinced you would need "homebrew" though. There are files inside the CTRNAND that have signatures unique to that console... that basically answers the question. And considering we can decrypt the FAT16, I think all you'd have to do is just swap those out in something like WinImage. Homebrew would only be necessary if you're doing it on the 3DS and not a computer.

    Now, the million-dollar question is: which files?

    I read a region-swapping tutorial before that was very hack-y and I didn't like it, you ended up with two eShops for example. But it involved editing some files in the CTRNAND and deleting some save data so the system recreates it. You had to take the SecureInfo_A and swap that out too, etc. But rather than what I have in mind (take the "good" system you want to put on a different 3DS and ONLY swap out what's specific to the original), they did something of the reverse - take the decrypted NAND from your target system, inject a couple files into it and so on. Which was fairly half-baked and left a really obnoxious, obviously-hacked system. (Oh, and obviously it required sigpatching to even boot)
     
  18. Dartz150

    Dartz150 GBATemp Official Lolicon Onii-chan™

    Member
    1,406
    845
    May 5, 2010
    Mexico
    On a Strange Journey
    Modifying anything form a file, even the minimun amount of data breaks signatures, you CAN'T extract or edit a single byte without "breaking it".

    That being said, all you say after can't be done so simple as that.

    The Xorpads are still console specific and can function on a PC because they're designed to do that.

    Is only step 1 copy-pasted, and that doesn't mean is widely open, is still unknown what keys generate the Xorpad data because that, again and I will say million times, are locked on the 3DS bootrom.

    EDIT: And region-change is not like changing critical data on the 3DS, is only a hacky method to make:

    1.-Nintendo Servers think the 3DS is from another region.

    2.- Enable the console to read out of region content, AKA Region Free patching.
     
    Last edited by Dartz150, Apr 9, 2016
  19. drfsupercenter
    OP

    drfsupercenter Flash Cart Aficionado

    Member
    1,898
    234
    Mar 26, 2008
    United States
    Yes, I know that. But you're confusing "editing a file" with "editing a filesystem". The FAT16 partition itself is not signed - it can't be! FAT is an old partitioning scheme that's been around longer than most of us have been alive.

    For example, let's say you want to delete the save data of a system title. Like you want to wipe out your activity log so it doesn't show that you ran [such and such homebrew program] 100 times. You can simply find the save file in /data/wherever and delete it.

    It will work. You're not breaking signatures, you're just deleting something inside an unsigned filesystem.

    The reason it's so difficult is that we don't know which files are keyed to the specific hardware and which are not. The decrypted CTRNAND (as in, using xorpads) has some files in plain text, user-readable (like the activity log) and other things are still encrypted even inside the NAND (ticket.db for example)