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

[drfsupercenter]

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?

 

[mgrev]

the nand images are not signed

 

[drfsupercenter]

the nand images are not signed

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.

 

[ih8ih8sn0w]

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.

 

[KaduPSE]

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.

 

[drfsupercenter]

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.

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)

 

[Noroxus]

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.

 

[FenrirWolf]

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.

 

[drfsupercenter]

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.

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.

 

[ih8ih8sn0w]

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.

OTP =/= NAND serial, you will not be able to do this at all, even with OTP (so i was wrong about it being possible)

 

[drfsupercenter]

OTP =/= NAND serial, you will not be able to do this at all, even with OTP (so i was wrong about it being possible)

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.

 

[Noroxus]

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.

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.

 

[drfsupercenter]

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.

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?

 

[DSoryu]

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.

 

[drfsupercenter]

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.

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!)

 

[DSoryu]

1.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.

2.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!)

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?... .


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.

 

[drfsupercenter]

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?... .


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.

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)

 

[DSoryu]

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.

 

[drfsupercenter]

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)