Hacking Discussion Still having a little trouble understanding system updates.

[EhRabz]

So I just bought an unpatched switch last night along with a 128gb SDXC memory card, I have got everything up until booting Atmosphere working ( it goes through the bootup process then bricks itself forcing me to hold power for 15 sec and manually restarting ) and I think this has to do with the fact I'm currently on the 8.0.1. update, I keep reading about these fuses blowing after system updates, but that's where I get lost.... How can there be atmosphere for anyhing above 3.0? I thought that was the cutoff for unpatched consoles... Or is firmware and the system update different?

Right now when I insert my SD card and boot into SX OS it tells me I need to update ( presumable 8.1 ) but the whole reason I bought my switch is for homebrew... So I'm a little confused here, if I update.. Will I not lose my ability for CFW?

 

[bowser]

Yes No but you'll get amazing StabilityTM

 

[EhRabz]

Yes but you'll get amazing StabilityTM

So it's safe to do the update through the switch? And maintain CFW after? Why do I fell like you trolling me

 

[bowser]

So it's safe to do the update through the switch? And maintain CFW after? Why do I fell like you trolling me

Oh no no please don't update

I was just making a joke. I know nothing about Switch hacking so I hope someone knowledgeable comes along to help you.

 

[EhRabz]

Oh no no please don't update

I was just making a joke. I know nothing about Switch hacking so I hope someone knowledgeable comes along to help you.

Bahaha good thing I trusted my gut on this one you bridge dweller ,

UPDATE: It was due to my SD being formatted to exFAT , but my question still begs, how do I get from 8.0.1. to 8.10 safely without blowinng fuses or losing CFW ability?

 

[bowser]

https://nh-server.github.io/switch-guide/
https://switch.homebrew.guide/

I think these are the best guides out there. You should read them thoroughly before touching your Switch to gain a good understanding of all the terminology. Don't follow any YouTube videos since those get outdated really quickly.

 

[EhRabz]

I actually already read these and succussfully running hombrew , but still don't get this Fuse/FW thing

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

I think these are the best guides out there. You should read them thoroughly before touching your Switch to gain a good understanding of all the terminology. Don't follow any YouTube videos since those get outdated really quickly.

Everything I read says don't update to 8.1 till further notice, so there's clearly a high risk of moving to it without having some sort of guide as im new to the homebrew scene for switches. Though not new to CFW and modding overall. I see there's atmosphere for 8.1 , so there's clearly a way to get there without screwing everything up , just not sure how to do that as of now

But I have already read these 2 and actually followed the HB one and am running a CFW and homebrew already , so I think I understad MOST thing so far, but can't seem to understand the upgrade process of unpatched switches

 

[bowser]

From what I understand, fuses are like one-way gates. Every firmware has a fuse associated with it. Every time you update to a new firmware the gates corresponding to the older firmwares get shut (burnt fuses). So you can't go back. Even if you do somehow install an older firmware whose fuse has been burnt then the Switch gets bricked or something.

There's a way to update without burning fuses and your Switch has to be in AutoRCM mode I think to do it. I think there is a homebrew to safely update when in AutoRCM mode. Using this you can freely move between whatever firmware version you want as long as those firmware fuses haven't been burnt already either by you or the previous owner.

 

[EhRabz]

From what I understand, fuses are like one-way gates. Every firmware has a fuse associated with it. Every time you update to a new firmware the gates corresponding to the older firmwares get shut (burnt fuses). So you can't go back. Even if you do somehow install an older firmware whose fuse has been burnt then the Switch gets bricked or something.

There's a way to update without burning fuses and your Switch has to be in AutoRCM mode I think to do it. I think there is a homebrew to safely update when in AutoRCM mode. Using this you can freely move between whatever firmware version you want as long as those firmware fuses haven't been burnt already either by you or the previous owner.

Yeah I understand the hardware aspect of it ( I've actually designed a few PCB's with those kind of "gates" ) , it's more so the sofware ... so you're saying there's a payload I can push that can bump me to 8.1 without blowing fuses?

 

[hiroakihsu]

how do I get from 8.0.1. to 8.10 safely without blowinng fuses or losing CFW ability?

Use ChoidujourNX to update and remember to set AutoRCM on when updating.

 

[EhRabz]

Use ChoidujourNX to update and remember to set AutoRCM on when updating.

This guy fux. Thank you, will attempt now!

 

[PHiLiPZ]

Burning fuses has no effect on CFW on a fusee gelee hackable console. You start CFW using hekate (or different custom bootloader) which completely ignores the fuse count. Fuses only matter for OFW and prevent you to downgrade to OFW with lower expected fuse count. When during booting the OFW sees more burnt fuses it knows it’s been downgraded and doesn’t start. This is so that you can’t lower your OFW to a version with working exploits.

Your console has a hw exploit so whatever FW version you install you’ll always be able to boot CFW and even any OFW, but only with custom bootloader which ignores fuse count.

 

[Itsuki235]

How can there be atmosphere for anyhing above 3.0? I thought that was the cutoff for unpatched consoles... Or is firmware and the system update different?

System updates are used to update the firmware so can be thought of as the same thing.

There is a flaw in the read-only bootrom for the switch consoles. This was mitigated a year ago and consoles manufactured after that point have the RCM/Fusée Gelée flaw mitigated.

Due to the nature of the flaw, unpatched consoles will forever be able to run CFW/Homebrew regardless of firmware version or fuse counts. Patched consoles are a different story, and should definitely not be updated if CFW is to exist in their future at some point.

For unpatched consoles, people always say not to update when newer official firmware (OFW) versions get released because it takes a few days/few weeks for the keys to get leaked and the CFW software to get updated to support the new OFW version. However, none of these system updates can ever stop CFW on Fusée Gelée vulnerable consoles.

The danger in updating is not having access to CFW during that time period after OFW first gets released and before CFW gets patches to support it. It took 2-3 days to update the CFW with this latest 8.1 OFW update and now most things are working again (except Hekate->Atmosphere booting).

 

[EhRabz]

System updates are used to update the firmware so can be thought of as the same thing.

There is a flaw in the read-only bootrom for the switch consoles. This was mitigated a year ago and consoles manufactured after that point have the RCM/Fusée Gelée flaw mitigated.

Due to the nature of the flaw, unpatched consoles will forever be able to run CFW/Homebrew regardless of firmware version or fuse counts. Patched consoles are a different story, and should definitely not be updated if CFW is to exist in their future at some point.

For unpatched consoles, people always say not to update when newer official firmware (OFW) versions get released because it takes a few days/few weeks for the keys to get leaked and the CFW software to get updated to support the new OFW version. However, none of these system updates can ever stop CFW on Fusée Gelée vulnerable consoles.

The danger in updating is not having access to CFW during that time period after OFW first gets released and before CFW gets patches to support it. It took 2-3 days to update the CFW with this latest 8.1 OFW update and now most things are working again (except Hekate->Atmosphere booting).

Yesssss, this is the kinda info I'm looking for , okay sick, I think I got it working, and now have a WAYYY better undestanding thanks to this

 

[Itsuki235]

Yesssss, this is the kinda info I'm looking for , okay sick, I think I got it working, and now have a WAYYY better undestanding thanks to this

Any more theory related questions?

 

[EhRabz]

Any more theory related questions?

No , I think I understand all I need to for now! Any other issues I have are just google searches away right now ( can't get backups to load ) but I doub't I could ask them here anwyays!

Thanks a bunch!

 

[Itsuki235]

No , I think I understand all I need to for now! Any other issues I have are just google searches away right now ( can't get backups to load ) but I doub't I could ask them here anwyays!

Thanks a bunch!

Direct links cannot be provided but other questions are fine, like how to install them or errors that you encounter while running them. The usually culprit for NSPs not working is that they need signature and ES patches to load when using Atmosphere CFW. They need to be in the /Atmosphere folder and the official GitHub Atmosphere.zip does not include them by default. ReiNX and SX OS do not need them/have them built in.

From what I understand, fuses are like one-way gates. Every firmware has a fuse associated with it. Every time you update to a new firmware the gates corresponding to the older firmwares get shut (burnt fuses). So you can't go back. Even if you do somehow install an older firmware whose fuse has been burnt then the Switch gets bricked or something.

Each firmware has a fuse "count" associated with it, not a particular fuse. https://switchbrew.org/wiki/Fuses#Anti-downgrade

Here is the exactly what happens:
The Switch uses a common anti-downgrade technique that utilizes microscopic fuses built into the CPU (ie. fuses that cannot be replaced). When turning on the Switch through regular means, the firmware performs a fuse check. On boot the following process is performed:

1. The bootloader will first check for how many fuses are burnt.
2. If there are less fuses burnt than the bootloader expects for a firmware version, the bootloader will enable fuse programming, burn up fuses up to as many as it expects, write the expected value to fuse indexes 0x3A and 0x3C, disable fuse programming and reboots via a watchdog timer checking for panic value 0x21. (new firmware added to an older switch - normal update)
3. On a subsequent boot, after the anti-downgrade fuses are checked again, the PMC_RST_STATUS register (0x7000E5B4) is checked and if set to 0x01 (watchdog reset) the PMC_SCRATCH200 register (0x7000EC40) will be checked for the panic value 0x21. PMC_RST_STATUS will only be set back to 0 (power on reset) if the fuse count matches the new expected value, otherwise the system will panic again.
   
4. If there are exactly enough fuses burnt as the firmware expects, it will allow the Switch to load the firmware. (normal reboot)
5. If there are too many fuses burnt, the Switch’s native bootloader will panic immediately, not allowing the firmware to boot. (older firmware boots a newer switch - system has been downgraded, so refuses to boot)

The bootloader cannot start reading the required fuse count associated with the firmware when the Switch is put into recovery mode (RCM). Entering recovery mode happens prior to the bootloader reading from the firmware on the sysNand. This has the effect of "skipping" the part of the bootloader that burns fuses. Thus, if automatic recovery mode (RCM) is enabled, no fuses will ever be burnt. Thus, because the rcm bug/Fusée Gelée exploit happens prior to the fuse check, any switch vulnerable to FG will forever be vulnerable to it. The fuse count does not matter for CFW at all.

The sole purpose of the fuses is to prevent downgrading and, on a FG vulnerable switch, they do not work. Downgrading from a OFW 8.1-> 4.1.0 is 100% do-able and the firmware will work normally because the fuse-check is bypassed completely when entering recovery mode.

Boot->recovery mode->[any firmware version].

Without going into recovery mode, the fuse check will occur and the firmware will not normally boot. The switch just shuts off. What people describe as a "brick" when downgrading is either misinformation, from people not understanding what is happening, or refers to having to enter recovery mode manually, or having to enable autoRCM, which itself can be described as a "controlled brick".

edit: grammar

 

[The Real Jdbye]

Direct links cannot be provided but other questions are fine, like how to install them or errors that you encounter while running them. The usually culprit for NSPs not working is that they need signature and ES patches to load when using Atmosphere CFW. They need to be in the /Atmosphere folder and the official GitHub Atmosphere.zip does not include them by default. ReiNX and SX OS do not need them/have them built in.


Each firmware has a fuse "count" associated with it, not a particular fuse. https://switchbrew.org/wiki/Fuses#Anti-downgrade

Here is the exactly what happens:
The Switch uses a common anti-downgrade technique that utilizes microscopic fuses built into the CPU (ie. fuses that cannot be replaced). When turning on the Switch through regular means, the firmware performs a fuse check. On boot the following process is performed:

1. The bootloader will first check for how many fuses are burnt.
2. If there are less fuses burnt than the bootloader expects for a firmware version, the bootloader will enable fuse programming, burn up fuses up to as many as it expects, write the expected value to fuse indexes 0x3A and 0x3C, disable fuse programming and reboots via a watchdog timer checking for panic value 0x21. (new firmware added to an older switch - normal update)
3. On a subsequent boot, after the anti-downgrade fuses are checked again, the PMC_RST_STATUS register (0x7000E5B4) is checked and if set to 0x01 (watchdog reset) the PMC_SCRATCH200 register (0x7000EC40) will be checked for the panic value 0x21. PMC_RST_STATUS will only be set back to 0 (power on reset) if the fuse count matches the new expected value, otherwise the system will panic again.
   
4. If there are exactly enough fuses burnt as the firmware expects, it will allow the Switch to load the firmware. (normal reboot)
5. If there are too many fuses burnt, the Switch’s native bootloader will panic immediately, not allowing the firmware to boot. (older firmware boots a newer switch - system has been downgraded, so refuses to boot)

The bootloader cannot start reading the required fuse count associated with the firmware when the Switch is put into recovery mode (RCM) because entering recovery mode happens prior to the bootloader reading from the firmware on the sysNand. This has the effect of "skipping" the part of the bootloader that burns fuses. Thus, if automatic recovery mode (RCM) is enabled, no fuses will ever be burnt. Thus, because the rcm bug/Fusée Gelée exploit happens prior to the fuse check, any switch vulnerable to FG will forever be vulnerable to it. The fuse count does not matter for CFW at all.

The sole purpose of the fuses is to prevent downgrading and, on a FG vulnerable switch, they do not work. Downgrading from a OFW 8.1-> 4.1.0 is 100% do-able and the firmware will work normally because the fuse-check is bypassed completely when entering recovery mode.

Boot->recovery mode->[any firmware version].

Without going into recovery mode, the fuse check will occur and the firmware will not normally boot. The switch just shuts off. What people describe as a "brick" when downgrading is either misinformation, from people not understanding what is happening, or refers to having to enter recovery mode manually, or having to enable autoRCM, which itself can be described as a "controlled brick".

Or downgrading incorrectly (trying to downgrade with ChoiDujourNX, or by restoring an older NAND backup without the boot0/boot1 files)
It's also worth noting that Fusee Gelee *would* be patchable if there was any room left for bootrom updates, but that space was filled up from the factory.

Edit: You could also brick by downgrading on a RCM patched console, because it is indeed possible to exploit those through other methods, and there's no easy way to unbrick them.

 

[Itsuki235]

Or downgrading incorrectly (trying to downgrade with ChoiDujourNX, or by restoring an older NAND backup without the boot0/boot1 files)

I have never tried downgrading with ChoiDujourNX. Granted that it is pointless to do so, but is there a "proper" way of downgrading to a lower-than-required fuse count? Like to from OFW 8.1->1.0.0?

Edit: For bricking patched consoles with rcm, just enabling autoRCM is enough to brick those. It does not have to be a full downgrade attempt. Hekate was updated to never allow for autoRCM to be enabled on a patched switch so it should no longer be possible. Considering that the exploits for >4.1.0 firmware are private, bricking them is minimal since so few people have CFW access at all.

 

[The Real Jdbye]

I have never tried downgrading with ChoiDujourNX. Granted that it is pointless to do so, but is there a "proper" way of downgrading to a lower-than-required fuse count? Like to from OFW 8.1->1.0.0?

Edit: For bricking patched consoles with rcm, just enabling autoRCM is enough to brick those. It does not have to be a full downgrade attempt. Hekate was updated to never allow for autoRCM to be enabled on a patched switch so it should no longer be possible. Considering that the exploits for >4.1.0 firmware are private, bricking them is minimal since so few people have CFW access at all.

Yes, by using ChoiDujour (non-NX)