Homebrew We now have all encryption/decryption keys for 3DS, so can we expect true CFW?

[Just3DS]

As the title says what I have been seeing in forums that by downgrading 3DS/N3DS all the way to firmware 3.0 we were able to retrieve all system keys that is non-unique for 3DS/N3DS consoles (so now emuNAND support can be guaranteed) until there is a new hardware revision.

So can we now expect true CFW like PSP CFW on PSP 1001 (coldboot sysNAND) any time soon?
We already been able to decrypt the sysNAND even before this recent accomplishment, but maybe we were not able to coldboot as we didn't knew all the keys before (there were no publicly available exploits for < 4.x), but now we know so maybe it is possible to create a script or program that performs permanent patches to the sysNAND.

I could be wrong, but I want to know what you guys think (or know) about it...

EDIT: I just noticed that I should have created it in "3DS - Flashcart and Custom Firmwares" section, if some staff can move it, sorry!

 

[Townsperson]

As the title says what I have been seeing in forums that by downgrading 3DS/N3DS all the way to firmware 3.0 we were able to retrieve all system keys that is non-unique for 3DS/N3DS consoles (so now emuNAND support can be guaranteed) until there is a new hardware revision.

So can we now expect true CFW like PSP CFW on PSP 1001 (coldboot sysNAND) any time soon?
We already been able to decrypt the susNAND even before this recent accomplishment, but maybe we were not able to coldboot as we didn't knew all the keys before (there were no publicly available exploits for < 4.x), but now we know so maybe it is possible to create a script or program that performs permanent patches to the sysNAND.

I could be wrong, but I want to know what you guys think (or know) about it...

No. The problem is we have no public exploits that early during boot (Arm9loaderhax does, but it is not something that is accessible for most users). So, you're stuck with menuhax being the best you're going to get for the time being.

 

[Just3DS]

No. The problem is we have no public exploits that early during boot (Arm9loaderhax does, but it is not something that is accessible for most users). So, you're stuck with menuhax being the best you're going to get for the time being.

As far as I know, the bootrom is hardcoded but the rest of the firmware isn't. Maybe we can make some changes in system applets and re-sign them using the keys we have?

 

[Xenon Hacks]

https://github.com/delebile/arm9loaderhax/

 

[windwakr]

As far as I know, the bootrom is hardcoded but the rest of the firmware isn't. Maybe we can make some changes in system applets and re-sign them using the keys we have?

Unless you have some way of factoring a 2048-bit semiprime, you're not going to be 're-sign'ing anything any time soon.

 

[Just3DS]

Thanks for this new info about arm9loaderhax you guys shared which I didn't know until now!

I did watch that conference and understood their concept of how the exploit code stays in memory even after reboot or something, I think it is related to that.

 

[FenrirWolf]

What would the advantage of a permanent sysnand cfw be anyway? to me, emunand seems like a far better solution since you can mess with it all you like with little to no risk of bricking the actual hardware you're running on.

 

[Xenon Hacks]

What would the advantage of a permanent sysnand cfw be anyway? to me, emunand seems like a far better solution since you can mess with it all you like with little to no risk of bricking the actual hardware you're running on.

This is for people with hard mods anyways and you would essentially have full control of the system and access to all services.

 

[Rosselman]

What would the advantage of a permanent sysnand cfw be anyway? to me, emunand seems like a far better solution since you can mess with it all you like with little to no risk of bricking the actual hardware you're running on.

arm9loaderhax could in theory provide a recovery to hard bricks, so you could mess with your sysNAND.

 

[FenrirWolf]

arm9loaderhax could in theory provide a recovery to hard bricks, so you could mess with your sysNAND.

Ah, that makes sense. I guess that would make it similar to the Wii homebrew situation, where I never bothered using emunand setups because BootMii lets me come back from anything.

 

[SomeGamer]

arm9loaderhax could in theory provide a recovery to hard bricks, so you could mess with your sysNAND.

BootMii comes to my mind here...
EDIT: Ninja'd

 

[Rosselman]

Ah, that makes sense. I guess that would make it similar to the Wii homebrew situation, where I never bothered using emunand setups because BootMii let me come back from anything.

arm9loaderhax is in theory the 3DS version of BootMii.

 

[zecoxao]

Unless you have some way of factoring a 2048-bit semiprime, you're not going to be 're-sign'ing anything any time soon.

on that topic, can we actually write to CFG_SYSPROT9 with full ARM9 access?

 

[capito27]

in a sense, a true CFW Should be possible, now that the arm9loaderhax is public knowledge, it would require people to develop the tools to extract the OTP region on o3ds and N3ds (the easiest would be through MSET, since the 4.x mset works with 2.x firm just fine) and to run arm9 payloads (restore nand backup) then, once that is public domain, can we really see proper CFW developpment , with tutorials about how to dump OTP for both o3ds and N3ds without hardmod

 

[FenrirWolf]

The thing I'm still puzzled about though is that apparently there's some way of being able to utilize arm9loaderhax on N3DS without dumping the OTP? Or was it an exploit that lets you dump the OTP without having to downgrade to <=3.0? Or maybe it was none of those things.

 

[capito27]

on that topic, can we actually write to CFG_SYSPROT9 with full ARM9 access?

i believe that you can only increment it's value (value 0 = bootrom access , value 1 = otp access, value 2 = nothing worthwhile), but i may be terribly wrong about that

 

[Rosselman]

The thing I'm still puzzled about though is that apparently there's some way of being able to utilize arm9loaderhax on N3DS without dumping the OTP? Or was it an exploit that lets you dump the OTP without having to downgrade to <=3.0? Or maybe it was none of those things.

The n3DS apparently has an exploit to dump OTP without downgrading

 

[zecoxao]

i believe that you can only increment it's value (value 0 = bootrom access , value 1 = otp access, value 2 = nothing worthwhile), but i may be terribly wrong about that

yeah, i guess there's nothing on wiki about it

 

[capito27]

The thing I'm still puzzled about though is that apparently there's some way of being able to utilize arm9loaderhax on N3DS without dumping the OTP? Or was it an exploit that lets you dump the OTP without having to downgrade to <=3.0? Or maybe it was none of those things.

well, otp hash is what is actually needed, to get the proper keys, and there is a N3DS method to get it, but it's annoying as hell to develop and use

 

[capito27]

What would the advantage of a permanent sysnand cfw be anyway? to me, emunand seems like a far better solution since you can mess with it all you like with little to no risk of bricking the actual hardware you're running on.

not necessarly, if done properly, the update of the actual firm partition could be prevented and as such, the arm9exploit remain present, even if you attempt to update native_firm.
If done properly, a default payload, allowing for a nand backup to be restored if present in the sd card (if the file "RESTORE_NAND.bin" is present, restore nand using the file) thus achieving as safe as possible of a CFW, since it could restore nand at early boot if something goes wrong. but i digress, such a thing is still months away