Homebrew Decrypting a NAND backup without the original system

Sky The Destroyer

Member
Newcomer
Joined
Mar 31, 2016
Messages
9
Reaction score
3
Trophies
0
XP
115
Country
United States
I remember reading a thing a while back about how with SigHax, we could decrypt NAND backups without the original system if you have the otp.bin of that system.

I have NAND backups of my Old (and bricked) 3DS with its otp.bin - is there currently a way to decrypt and get access to the files from NAND backups through the use of otp.bin?
 
Last edited by Sky The Destroyer,
Any more possible, I should've said. It's always been dump-able by getting to 2.1.0. :P
you can dump the one time programmable (otp) and the full arm9 bootrom (boot9) and the full arm11 bootrom (boot11) anytime you want on any firmware you want, as long you have Micheal's implementation of SigHax (boot9strap) written to your firm partitions.
 
you can dump the one time programmable (otp) and the full arm9 bootrom (boot9) and the full arm11 bootrom (boot11) anytime you want on any firmware you want, as long you have Micheal's implementation of SigHax (boot9strap) written to your firm partitions.
I'm aware. It's already been possible, it still is possible, and it's more easily doable with B9S.

What's your point
 
I think you guys misunderstood each other, is all. You both pretty much said the same things about otp.bin's ability to be dumped...either way, I already have the otp.bin for that NAND backup, so I'm not sure how the discussion went into how otp.bin is able to be dumped.

Back on topic: this is what I've heard about decrypting NAND backups:

"If you have boot9.firm (common to all systems) and otp.bin (specific to each system), you can decrypt the eMMC keys from otp.bin and use them to decrypt NAND dumps from that system without xorpads."

My question is how I would go about doing that.
 
I think you guys misunderstood each other, is all. You both pretty much said the same things about otp.bin's ability to be dumped...either way, I already have the otp.bin for that NAND backup, so I'm not sure how the discussion went into how otp.bin is able to be dumped.

Back on topic: this is what I've heard about decrypting NAND backups:

"If you have boot9.firm (common to all systems) and otp.bin (specific to each system), you can decrypt the eMMC keys from otp.bin and use them to decrypt NAND dumps from that system without xorpads."

My question is how I would go about doing that.
so set up yellows8's boot9tools and then decrypt9 the otp, then if you have a python knowledge you could rewrite one of the tooks or 3dsconv to use the otp's keys to decrypt a nand backup
 
so set up yellows8's boot9tools and then decrypt9 the otp, then if you have a python knowledge you could rewrite one of the tooks or 3dsconv to use the otp's keys to decrypt a nand backup
I can probably get as far as decrypting otp.bin (though I'm not sure what the boot9 binary file is), but beyond that step, I have no knowledge on the decryption process.
 
Last edited by Sky The Destroyer,
something changed ?
Can someone please explain me why we can now theoretically decrypt a NAND Backup and how ???

I know how to program but idk where to find this Script called 3dsconv....
 
something changed ?
Can someone please explain me why we can now theoretically decrypt a NAND Backup and how ???

I know how to program but idk where to find this Script called 3dsconv....
It's the bootrom dump that SigHax brought us. That was the missing part of the puzzle for the remaining keys we needed to allow decrypting without needing to do it on the 3DS itself.
 
I think you guys misunderstood each other, is all. You both pretty much said the same things about otp.bin's ability to be dumped...either way, I already have the otp.bin for that NAND backup, so I'm not sure how the discussion went into how otp.bin is able to be dumped.

Back on topic: this is what I've heard about decrypting NAND backups:

"If you have boot9.firm (common to all systems) and otp.bin (specific to each system), you can decrypt the eMMC keys from otp.bin and use them to decrypt NAND dumps from that system without xorpads."

My question is how I would go about doing that.
yellows8 has some tools that can be used for this.
"ctr-nandcrypt" from https://github.com/yellows8/3dscrypto-tools/tree/master/ should be able to do what you want.
Supposedly it can use the keys obtained with https://github.com/yellows8/boot9_tools
However, I'm not sure if boot9 and OTP contain all the keys needed, some keys are contained in FIRM and ctrnand as well (obviously the ctrnand keys aren't needed for this, but the FIRM keys may be)
But pretty much all the keys are available online if you know where to look. Hint: Google Spreadsheets

I tried playing around with 3dscrypto-tools, but wasn't really able to get any of it working, and there's hardly any documentation.
When I tried ctr-nandcrypt it just closed without an error. I didn't fill in all the parameters, because I wasn't sure what NAND CID and NAND CTR were. So that might be why it didn't work for me.
It's supposed to generate xorpads that you can then use with a xor tool.

Edit: NAND CID appears to be in the ARM9 ITCM memory, which can be dumped with GodMode9, but that requires access to the console. Still no clue about NAND CTR.

NAND CTR for CTRNAND appears to be the first 16 bytes of the SHA256 sum of NAND CID. NAND CTR for TWLNAND seems to be the SHA1 sum of the same, but in reversed order.
Seems like NAND CID is just the an identifier of the NAND chip, you could probably get it using a hardmod.
This is all confusing though. That's just what I gathered from looking at the SafeB9SInstaller source here: https://github.com/d0k3/SafeB9SInstaller/blob/master/source/nand/nand.c
Someone else who knows more about the 3DS' inner workings than me will have to explain it.

It might be easier to just wait for ntrboothax, or get a hardmod, and unbrick the 3DS.
Seems like you'll need a hardmod anyway in order to get the NAND CID.
 
Last edited by The Real Jdbye,

Site & Scene News

Popular threads in this forum