Hacking Atmosphere-NX - Custom Firmware in development by SciresM

[Onibi]

This is the key point.

Lets say we have low level owned. We say allow official key, and 000000 (our key). At that point we can run anything on the system we want.

New Firmware comes in. Changes official key. We can see that, probably also see key - key is used to start the new kernel. Kernel is hardened against all known attacks.

We try to look at its behavior, it uses memory address space randomization. We have a hard time doing that. Even though we own the system, we cant read new keys (for other stuff) in the kernel.

This might be a difficult problem. Probably solvable, but the timeframe is important too.

I think this is how it works - but I'm not an expert. Just someone proficient at logic.

Hmm. I think in the switch, the keys are stored in the TZ, meaning we will always own them. Also, while the kernel may be obfuscated, it must be able to decrypt packages to load them. So we can just tell the kernel "go decrypt this" and it will. Worst case, since we are running from the TZ, where the kernel can not see us we always have the upper hand, no?

 

[TotalInsanity4]

Hmm. I think in the switch, the keys are stored in the TX, meaning we will always own them. Also, while the kernel may be obfuscated, it must be able to decrypt packages to load them. So we can just tell the kernel "go decrypt this" and it will. Worst case, since we are running from the TX, where the kernel can not see us we always have the upper hand, no?

What do you think "TX" means?

 

[notimp]

That basically it. Obfuscation, vs. time to get to them vs. release intervals.

I've owned other hacked devices before, that allowed homebrew - which wasnt defeatable - but the manufacturer made sure, that people quickly lost the "motivation" of modifying any of the UI, or the company backend stuff - and hackers were shut out from newer models. Which segmented the scene, which...

 

[Onibi]

What do you think "TX" means?

In this case trustzone execution (but should be TZ for clarity true)

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

That basically it. Obfuscation, vs. time to get to them vs. release intervals.

I've owned other hacked devices before, that allowed homebrew - which wasnt defeatable - but the manufacturer made sure, that people quickly lost the "motivation" of modifying any of the UI, or the company backend stuff - and hackers were shut out from newer models. Which segmented the scene, which...

Yea, I think we agree on what can be done I am maybe a bit more optimistic, but until we actually see countermeasures we have to see. I mean if they add for example anti-cheat engines to this already not super strong system, it may become slower then they can allow. Who knows But yea, it will be interesting and you are right they can do quite a bit.

 

[TotalInsanity4]

In this case trustzone execution (but should be TZ for clarity true)

Ah ok lol, I thought you were talking about "Team Xecuter" and I was beyond confused

 

[Onibi]

Ah ok lol, I thought you were talking about "Team Xecuter" and I was beyond confused

Yea, in this case TX was total bogus because I was talking about the Trustzone as (storage) environment and not the Trustzone code execution directly.
I guess TX and TZ are to close in this topic so that I keep Freudian-slipping on it ... I keep an eye out

Also doesn't help that I would naturally call "trustzone (code) execution" TX ... (I guess I go with TZX ..)

 

[reminon]

Since the bootrom is not upgradeable, all current and future firmwares are required to be compatible with our current bootrom. At this point keys are not relevant. Each link of the boot chain believes that the link before it was legit, "otherwise it couldn't decrypt and start me". So if the first link of the chain is rogue, then the others fall in line. They can play cat and mouse making it harder to patch out checks and signatures I guess...but they can't stop us from starting an updated ofw, while keeping our efuses and such untouched...then it's a matter of updating the cfw as needed.

 

[TheCyberQuake]

Keys are handled by TZ, and are contained somewhere in the update. With full TZ control future key changes are irrelevant, because we can just grab the keys with TZ with the updated emuNAND. And afaik kaslr also shouldn't be a big problem either with TZ control. TZ gives full system control, even over kernel if I'm correct. May be as simple as using TZ to "ask" kernel for the memory maps.

 

[Deleted User]

Keys are handled by TZ, and are contained somewhere in the update. With full TZ control future key changes are irrelevant, because we can just grab the keys with TZ with the updated emuNAND. And afaik kaslr also shouldn't be a big problem either with TZ control. TZ gives full system control, even over kernel if I'm correct. May be as simple as using TZ to "ask" kernel for the memory maps.

you are not 100% correct to relay Robabla he said that the TZ on 5.0 changed Heavly so i am not sure you could just go and grab something yet

 

[TheCyberQuake]

you are not 100% correct to relay Robabla he said that the TZ on 5.0 changed Heavly so i am not sure you could just go and grab something yet

Pretty sure that only majorly affects sysNAND, ie mitigating exploits. Not sure if it will actually affect the cfw running emuNAND much as it's running a completely custom Secure Monitor (TZ) anyway. Though I would love to hear some info on this from @SciresM if the update does actually affect anything currently developed in atmosphere.

 

[Garro]

Time to enjoy Splatoon 2 and MK8D Online while it's possible.

 

[Y0sh1]

The exosphere part of the CFW is pretty much done, but it seems to me like the first stage loader (fusee) is not yet uploaded to github because people will start bricking their switches like crazy. Or maybe they are waiting for some hacks to use them as the entry point for the CFW installs ¯\_(ツ)_/¯

 

[Onibi]

The exosphere part of the CFW is pretty much done, but it seems to me like the first stage loader (fusee) is not yet uploaded to github because people will start bricking their switches like crazy. Or maybe they are waiting for some hacks to use them as the entry point for the CFW installs ¯\_(ツ)_/¯

The trustzone should eventually provide a low level flash ability (like fastboot) to avoid any (well most common) bricks. However, I do agree, to make the project safe to install a good bit more work will need to be done.

I hope we will soon see the exploit released to get a larger dev and beta test community rolling. Otherwise I expect that a stable release will be several month away

 

[TheCyberQuake]

The trustzone should eventually provide a low level flash ability (like fastboot) to avoid any (well most common) bricks. However, I do agree, to make the project safe to install a good bit more work will need to be done.

I hope we will soon see the exploit released to get a larger dev and beta test community rolling. Otherwise I expect that a stable release will be several month away

Trustzone didn't get us something like fastboot, that would be the trustzone exploit to get us that

 

[Onibi]

Trustzone didn't get us something like fastboot, that would be the trustzone exploit to get us that

No I mean in the CFW implementation of the TZ, so that reflashing will be simple for higher level components (kernel, userspace). Less ability to brick.

 

[TheCyberQuake]

No I mean in the CFW implementation of the TZ, so that reflashing will be simple for higher level components (kernel, userspace). Less ability to brick.

You don't flash anything with basic cfw and emuNAND, except the SD card with the initial setup of emuNAND. I may just be misunderstanding what you are trying to say though.

 

[TotalInsanity4]

You don't flash anything with basic cfw and emuNAND, except the SD card with the initial setup of emuNAND. I may just be misunderstanding what you are trying to say though.

I think he's saying that the bootloader will probably have a way to reflash NAND for brick protection

 

[TheCyberQuake]

I think he's saying that the bootloader will probably have a way to reflash NAND for brick protection

That's unlikely. Like I said before that kind of brick protection would require bootrom, not just TZ. You need code executing before most of nand starts to load. Unless they mean emuNAND brick protection.

 

[TotalInsanity4]

That's unlikely. Like I said before that kind of brick protection would require bootrom, not just TZ. You need code executing before most of nand starts to load. Unless they mean emuNAND brick protection.

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

 

[Onibi]

That's unlikely. Like I said before that kind of brick protection would require bootrom, not just TZ. You need code executing before most of nand starts to load. Unless they mean emuNAND brick protection.

Yes, it would require bootrom hardware support if done as a perfect brick protection (like fastboot). However, the next best thing will be to support the same from the TZ. Essentially, updating the higher level CFW will typically not touch the TZ. At best, both parts will update separately. This will allow people to dev on the higher level CFW without bricking.