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