Hacking Question Technical reason for lack of permanence in CFW?

[jetlego]

Does anybody know the reason that there is no current way to establish permanence of CFW even with ring 0 (?) access before horizon even boots? I understand that there is currently no software coldboot exploit on any firmware other than 1.0.0 (maybe), and that only <=4.1 will have a software warmboot exploit. However, those are merely discussing entrypoints, and with rcm access, surely it should be possible to create some sort of exploit chain that can enable the exploit to persist between reboots.

For example, while at one point gateway or rxtools exploits needed to be executed every time the 3ds booted up, the NTRBoot bootrom exploit only needs to be executed once in order to permanently install CFW.

Is this impossible for of a technical reason regarding the design of the switch's OS? Or is it simply not a priority for the current developers working on low level CFW/OS
development?

I understand that an internal modchip can achieve a similar effect, but I would like to know more about the technical challenges, if any, that are present. Additionally, if anyone has links to writeups or presentations on the design on Horizon, I would greatly appreciate them!

 

[Draxzelex]

The Switch won't accept anything that isn't signed with Nintendo's personal signing key. And before you ask why it hasn't been cracked yet, this key is 2,048 characters long. Also, what you're referring to installing an exploit not a CFW. On the 3DS, we never achieved permanently installing a CFW. So basically, we never have nor will install CFW permanently but we might be able to discover a more permanent exploit in the distant future. B9S was released several years after the 3DS came out and it has only been a year and a half since the Switch came out. However, don't hold your breath and believe lightning strikes the same place twice.

 

[jetlego]

Thank you very much for your explanation! I have one question though:

On the 3DS, we never achieved permanently installing a CFW.

Isn't the part on 3ds. guide "Finalizing setup Section VI - CTRNAND Luma3DS" permanently installing Luma3DS to nand as a fallback? I understand that usually the luma3ds boot.firm is loaded from the SD card at boot by B9S.

 

[ghjfdtg]

b9s exploits vulnerabilities which kick in at loading time of the firmware by the bootrom. As such it can be directly installed and persists. On the Switch nothing like that exists and probably never will.

 

[Draxzelex]

Thank you very much for your explanation! I have one question though:


Isn't the part on 3ds. guide "Finalizing setup Section VI - CTRNAND Luma3DS" permanently installing Luma3DS to nand as a fallback? I understand that usually the luma3ds boot.firm is loaded from the SD card at boot by B9S.

b9s exploits vulnerabilities which kick in at loading time of the firmware by the bootrom. As such it can be directly installed and persists. On the Switch nothing like that exists and probably never will.

This. Although Luma is being flashed to the NAND, it can't be loaded without an exploit hence why I said:

Also, what you're referring to installing an exploit not a CFW.

Theoretically, we can eventually flash any CFW to the NAND (or eMMC in the case of the Switch) but the console would only boot up if we are using the current bootrom exploit Fusee Gelee which involves more than just an SD card.

 

[LightOffPro]

Attention that in the Switch, just like Luma3DS, we are not integrating a completely new OS.
Luma3DS patches the existing OFW on every boot, this is why with each new firmware update released by Nintendo you can still update and keep Luma.
The OFW is never fully replaced. Only patched.
We are doing the exact same thing with Switch and the OFW Horizon. We are patching the OFW, not fully replacing it.

 

[DocKlokMan]

Thank you very much for your explanation! I have one question though:


Isn't the part on 3ds. guide "Finalizing setup Section VI - CTRNAND Luma3DS" permanently installing Luma3DS to nand as a fallback? I understand that usually the luma3ds boot.firm is loaded from the SD card at boot by B9S.

We're not installing custom firmware files to the NAND, overwriting the stock firmware files and having the 3DS boot those files like they were official files. We're just using the NAND as a storage location, but the actual hack is installing a permanent exploit. That exploit runs when we boot the 3DS and then the exploit runs the CFW memory patches that patch the official firmware after it's been loaded. On top of that, B9S was only possible due to severe issues in Nintendo's verification of their signature key. This is unlikely to happen again with the Switch. Installing an exploit in Switch's RCM would require us spoofing Nintendo's signature or exploiting the verification, neither of which are very feasible right now.

 

[badcat]

Is there a better resource to read about the details of how this kind of boot process works? I'm ignorant about boot security but willing to read long boring things for fun.

--------------------- MERGED ---------------------------

Looks like you can google "tegra boot flow" to find a doc.

 

[The Catboy]

Just tossing out there, but you actually can install Luma to your FIRM0. I can make a thread about it if anyone is interested

 

[SomeGamer]

Just tossing out there, but you actually can install Luma to your FIRM0. I can make a thread about it if anyone is interested

Please do, I'm interested.

 

[The Catboy]

Please do, I'm interested.

I shall make a thread either later tonight or tomorrow.