Hacking Atmosphere-NX - Custom Firmware in development by SciresM

[TheCyberQuake]

Doesn't TrustZone boot before everything EXCEPT for bootrom?
(Plus isn't there a bootrom exploit for all first revision Switches?)

Yes there is a bootrom exploit. But without that release you don't have brick protection. The TZ exploits aren't permanent like a bootrom exploit, you'll need to relaunch the exploit from sysNAND to get back to cfw emuNAND. It's like cfw emuNAND on 3ds before a9lh. SysNAND was not brick protected. If we had brick protection it would negate the need for emuNAND because we would have code execution early enough to just apply cfw to an updated sysNAND.

 

[Onibi]

Yes there is a bootrom exploit. But without that release you don't have brick protection. The TZ exploits aren't permanent like a bootrom exploit, you'll need to relaunch the exploit from sysNAND to get back to cfw emuNAND. It's like cfw emuNAND on 3ds before a9lh. SysNAND was not brick protected. If we had brick protection it would negate the need for emuNAND because we would have code execution early enough to just apply cfw to an updated sysNAND.

Somewhat correct, however, the switch TZ works a bit different and has a bit different capabilities. It can isolate the sysNAND.
In addition, nobody says that you have to re-flash the TZ code nearly as often as you flash the rest of the system. Especially, the OFW under emuNAND should not be able to touch the TZ code by accident. Neither should it require us to patch the service (or any OFW component).

 

[TotalInsanity4]

The TZ exploits aren't permanent like a bootrom exploit, you'll need to relaunch the exploit from sysNAND to get back to cfw emuNAND.

Wait, hang on... I assumed that TZH would be coldboot and a one-time install thing. Is that not the case?

 

[Onibi]

Wait, hang on... I assumed that TZH would be coldboot and a one-time install thing. Is that not the case?

It is definitely cold boot. I think what he means is that it resides in flash-able NAND and thus is not safe. (But I am a bit confused by the text as well.)

 

[charlieb]

Wait, hang on... I assumed that TZH would be coldboot and a one-time install thing. Is that not the case?

that's not the case I'm afraid. every boot will require the same back trigger before the console will be exploited

 

[TheCyberQuake]

It is definitely cold boot. I think what he means is that it resides in flash-able NAND and thus is not safe. (But I am a bit confused by the text as well.)

No its not. It's like 3ds loading cfw with hbl before a9lh. It requires an entry point on sysNAND to enter cfw emuNAND, right now being the browser. Will require reloading the exploit every time you reboot the console, just like the current hbl exploit. I don't know where everyone gets the idea its a one and done thing, which would require coldboot exploit like bootrom.

Somewhat correct, however, the switch TZ works a bit different and has a bit different capabilities. It can isolate the sysNAND.
In addition, nobody says that you have to re-flash the TZ code nearly as often as you flash the rest of the system. Especially, the OFW under emuNAND should not be able to touch the TZ code by accident. Neither should it require us to patch the service (or any OFW component).

You don't reflash anything for this cfw. It loads everything from SD. I don't think you quite understand how cfw, emuNAND and exploits work.

 

[Onibi]

No its not. It's like 3ds loading cfw with hbl before a9lh. It requires an entry point on sysNAND to enter cfw emuNAND, right now being the browser. Will require reloading the exploit every time you reboot the console, just like the current hbl exploit. I don't know where everyone gets the idea its a one and done thing, which would require coldboot exploit like bootrom.



You don't reflash anything for this cfw. It loads everything from SD. I don't think you quite understand how cfw, emuNAND and exploits work.

I think you are missing the difference in hardware. Why would you not flash sysNAND / TZ? I understand perfectly well how emuNAND on SD works. What I don't understand is why you both assume that you have to non-perma do this and run it through the user-space every time.

Please elaborate!

 

[TheCyberQuake]

I think you are missing the difference in hardware. Why would you not flash sysNAND / TZ? I understand perfectly well how emuNAND on SD works. What I don't understand is why you both assume that you have to non-perma do this and run it through the user-space every time.

Please elaborate!

You don't flash TZ or sysNAND. You would need either nintendo's private keys to resign it afterward to prevent a system panic, or code executing early enough to patch signature checks of those files.
Just take a look at the fusee project in the github. It loads everything, including the modified packages for TZ, from SD.
If we could just flash TZ or sysNAND there would be no point in using emuNAND.
The TZ exploits aren't permanent. Care to elaborate where you got the idea that they are?

 

[salamandrusker]

for now a cfw based on emunand is perfect. when are you going to release that cfw based on emunand with the sd to test it in 3.0.0?

 

[TotalInsanity4]

No its not. It's like 3ds loading cfw with hbl before a9lh.

I don't quite understand why you keep using this example, because as far as I'm aware the reason we couldn't coldboot on 3DS is because we didn't have control over anything early enough in the boot process to fakesign boot code. In this case, TrustZone is the hypervisor and in theory should be able to load anything it's told to if it's modified

 

[Onibi]

You don't flash TZ or sysNAND. You would need either nintendo's private keys to resign it afterward to prevent a system panic, or code executing early enough to patch signature checks of those files.
Just take a look at the fusee project in the github. It loads everything, including the modified packages for TZ, from SD.
If we could just flash TZ or sysNAND there would be no point in using emuNAND.
The TZ exploits aren't permanent. Care to elaborate where you got the idea that they are?

I apologize

I had a few missconceptions about the situation. Most vitally, I thought that the key security mode used was broken and thus that the trust chain can be broken (however that happens in another much less vital part of the system and not in the key area). Thus, that does not seem so

This makes me wonder why people down the TX mod-chip (and also makes me even more angry at people holding back mod-chip designs and threaten TX to ruin their income). I would like to have a solid cold boot ability.

Hmm. I am thinking about upgrading one of my switches now ... since I will clearly mod-chip them Also makes me want to get a third one, since I now understand the limits of the softmod fully ... Bootrom bug clearly THE way to go

 

[TheCyberQuake]

I don't quite understand why you keep using this example, because as far as I'm aware the reason we couldn't coldboot on 3DS is because we didn't have control over anything early enough in the boot process to fakesign boot code. In this case, TrustZone is the hypervisor and in theory should be able to load anything it's told to if it's modified

This isn't a persistent exploit. This is not a boot time exploit. It takes over TZ after boot. You would need to take over the system BEFORE TZ starts in order to take control of TZ at boot, ie a bootrom exploit. Deja vu doesn't install anything to the system. It's even explained in the github that in lieu of a bootrom exploit release, they are using emuNAND. Because without the bootrom exploit we can't control the system at boot.

 

[Onibi]

I don't quite understand why you keep using this example, because as far as I'm aware the reason we couldn't coldboot on 3DS is because we didn't have control over anything early enough in the boot process to fakesign boot code. In this case, TrustZone is the hypervisor and in theory should be able to load anything it's told to if it's modified

Sadly not. The fuses are used and can not be set after the initial bootloader. Essentially, the code to deploy new keys runs before the TZ and disables the ability to set keys and thus to invalidate or overwrite anything signed with the keys, including the TZ. The whole system has a trust chain of keys that can not be circumvented after boot1.

 

[TotalInsanity4]

Sadly not. The fuses are used and can not be set after the initial bootloader. Essentially, the code to deploy new keys runs before the TZ and disables the ability to set keys and thus to invalidate or overwrite anything signed with the keys, including the TZ. The whole system has a trust chain of keys that can not be circumvented after boot1.

Ok, THAT was the explanation I was looking for, and I guess after thinking about it that makes sense; modifying TZ would invalidate the key the bootloader is looking for and make the system unbootable

 

[TheCyberQuake]

Ok, THAT was the explanation I was looking for, and I guess after thinking about it that makes sense; modifying TZ would invalidate the key the bootloader is looking for and make the system unbootable

You would need either nintendo's private keys to resign it afterward to prevent a system panic, or code executing early enough to patch signature checks of those files.

I mentioned it earlier, though not as in depth.

 

[Onibi]

Ok, THAT was the explanation I was looking for, and I guess after thinking about it that makes sense; modifying TZ would invalidate the key the bootloader is looking for and make the system unbootable

I think I have to correct myself. It's not the fuses but the BCT (http://switchbrew.org/index.php?title=BCT#bootloader0_info and bct_signature) which is signed and creates the issue. The problem as understood is the same thou. Essentially, as said, the trust chain can not be broken and is provided by the bootloader before the TZ.

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

But wait, didn't failoverflow etc. tease that they had cold boot software ability? I think that is why we assumed that TZ would be cold boot able

 

[TotalInsanity4]

I mentioned it earlier, though not as in depth.

I know you did, I just didn't fully understand what you were talking about

 

[Onibi]

But wait, didn't failoverflow etc. tease that they had cold boot software ability? I think that is why we assumed that TZ would be cold boot able

Yes, the "fusée gelée" bug and the failoverflow bugs are both claimed to be cold boot software bugs

So I think we where not too far of to have mixed that in with the TZ exploit ... Shouldn't SciresM have access to it and include it into the CFW deployment?

 

[TheCyberQuake]

I think I have to correct myself. It's not the fuses but the BCT (http://switchbrew.org/index.php?title=BCT#bootloader0_info and bct_signature) which is signed and creates the issue. The problem as understood is the same thou. Essentially, as said, the trust chain can not be broken and is provided by the bootloader before the TZ.

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

But wait, didn't failoverflow etc. tease that they had cold boot software ability? I think that is why we assumed that TZ would be cold boot able

Yeah, it's confirmed multiple devs have bootrom exploit. Even reswitched (including SciresM) has it. It just won't be released for a while.

 

[TheCyberQuake]

Yes, the "fusée gelée" bug and the failoverflow bugs are both claimed to be cold boot software bugs

So I think we where not too far of to have mixed that in with the TZ exploit ... Shouldn't SciresM have access to it and include it into the CFW deployment?

He does have it. Just won't release it for a while. Unsure why since now we know it's being patched in a hardware revision anyway.