Homebrew Question IPatched Unit: Is it safe to downgrade?

[PRAGMA]

TL-DR; Yes its safe, I downgraded from this v4.1.0, to v4.0.1, then had to get cnmt.nca's and its accompanying .nca's from v4.0.1 as it was required for going down to v4.0.0, but it did work, and was very simple in practice.
Important Notice: To anyone possibly doing it with the same ideology as me, trying to get to lowest firmware possible, beware that v4.0.0 does NOT have PegaScape support!

Reminder that you can only downgrade to whatever firmware your system's fuse count allows.
You can find your burnt fuse count via Hekate, and you can find out what firmwares your fuse count allows here: https://switchbrew.org/wiki/Fuses#Anti-downgrade

Original Thread:

Asking specifically since AutoRCM cannot be (or at least should not be) used.
And that it is writing to the NAND, not an EmuMMC.

Basically, I now have a Switch on v4.1.0 with 5 burnt fuses (out of the box, with no internet connection used)
Since its 5 burnt fuses, I should be able to downgrade to v4.0.0 reliably no?

I'm just worried that if I downgrade here without the AutoRCM option ticked, i'm worried it will burn fuses or refuse to boot since this is to OFW/NAND not an EmuNAND/EmuMMC.

 

[nicoboss]

If you ever enable AutoRCM on an IPatched unit it's dead forever as ther is no way to ever boot it again as no payload required for it to boot or disabeling AutoRCM can be injected. Downgrading to 4.0.0 might be posible but compleately useless and way too risky. One single mistake and you Switch is dead. If you realy want to downgrade make sure to erase all data to lower the posibility of it not booting and being bricked forever. You don't have to worry about downgrading ever burrning an efuse as only upgrading will (it burns if and only if the current OS has a higher fusee count then the one of your Switch). Please keep in mind that 4.0.0 doesn't offer any benefits over 4.1.0 in terms of exploits as far I'm aware.

 

[Hayato213]

There isn't really any benefit of you being on 4.0.0 than 4.1.0.

 

[Lacius]

Asking specifically since AutoRCM cannot be (or at least should not be) used.
And that it is writing to the NAND, not an EmuMMC.

Basically, I now have a Switch on v4.1.0 with 5 burnt fuses (out of the box, with no internet connection used)
Since its 5 burnt fuses, I should be able to downgrade to v4.0.0 reliably no?

I'm just worried that if I downgrade here without the AutoRCM option ticked, i'm worried it will burn fuses or refuse to boot since this is to OFW/NAND not an EmuNAND/EmuMMC.

In short, it's technically possible for you to downgrade to 4.0.0 or 4.0.1. However, there's nothing to be gained from the downgrade, and if something goes wrong, you have no way to recover from a brick (without a hardmod and a NAND backup).

 

[PRAGMA]

If you ever enable AutoRCM on an IPatched unit it's dead forever as ther is no way to ever boot it again as no payload reqired for it to boot or disabeling AutoRCM can be injected. Downgrading to 4.0.0 might be posible but compleately useless and way too risky. One single mistake and you Switch is dead. If you realy want to downgrade make sure to erase all data to lower the posibility of it not booting and being bricked forever. You don't have to worry about downgrading ever burrning an efuse as only upgrading will (it burns if and only if the current OS has a higher fusee count then the one of your Switch). Please keep in mind that 4.0.0 doesn't offer any benefits over 4.1.0 in terms of exploits as far I'm aware.

There isn't really any benefit of you being on 4.0.0 than 4.1.0.

I see thats kinda what I thought with the fuses for downgrading and upgrading, wanted to be 100% sure.
I downgraded to 4.0.1 but cant to 4.0.0 as it errors saying: Missing meta nCA for 01008bb00013c000 4.0.0.200
But it worked flawlessly. Still 5 fuses all G.

And I know there may not be any benefit but I thought I might aswell be lowest firmware.
But I did hear (not sure if true) that SuperNag (browser update nag) first started on 4.1.0, meaning older firmwares dont even have the possibility of it happening? idk so I thought I might as well downgrade just incase thats true.

 

[PRAGMA]

Word to the wise, It says "Spinner will freeze on firmwares 4.0.0 - 4.1.0" on the page that shows inside your Switch, but 4.0.0 isnt actually supported.
Got pretty fooled by that. Almost locked out of support.
Thankfully, I have a Cartridge that requires 4.1.0, so I just plugged it in, clicked OK to accept its update (MAKING SURE I HAD INTERNET CONNECTIONS DELETED FIRST!!!!!!!)
Then I was back to 4.1.0, ready to go back to 4.0.1

 

[Basketto]

If you ever enable AutoRCM on an IPatched unit it's dead forever as ther is no way to ever boot it again as no payload reqired for it to boot or disabeling AutoRCM can be injected. Downgrading to 4.0.0 might be posible but compleately useless and way too risky. One single mistake and you Switch is dead. If you realy want to downgrade make sure to erase all data to lower the posibility of it not booting and being bricked forever. You don't have to worry about downgrading ever burrning an efuse as only upgrading will (it burns if and only if the current OS has a higher fusee count then the one of your Switch). Please keep in mind that 4.0.0 doesn't offer any benefits over 4.1.0 in terms of exploits as far I'm aware.

This has me confused. If you could somehow enable AutoRCM on a Patched Switch, would that not require a payload in the first place ;p.

 

[Hayato213]

This has me confused. If you could somehow enable AutoRCM on a Patched Switch, would that not require a payload in the first place ;p.

The concept is that if a patched unit was in autoRCM mode then it would be stuck there forever which you get a bricked state as you can't sent any payload through RCM mode.

 

[Draxzelex]

This has me confused. If you could somehow enable AutoRCM on a Patched Switch, would that not require a payload in the first place ;p.

Caffeine and Nereba both utilize payloads to boot CFW. However these are triggered when the console is hooked up to the Internet. AutoRCM boots the console into RCM which can only accept payloads in RCM which a patched console cannot accept.

 

[Basketto]

The concept is that if a patched unit was in autoRCM mode then it would be stuck there forever which you get a bricked state as you can't sent any payload through RCM mode.

I understand that part, but I still don’t understand how you would get to it Autorcm without sending a payload in the first place . I imagine its just in theory?

 

[Hayato213]

I understand that part, but I still don’t understand how you would get to it Autorcm without sending a payload in the first place . I imagine its just in theory?

You can launch cfw through the software base exploit that @Draxzelex mentioned above, but if the person enable autorcm through hekate then the unit would brick, as it would be stuck in autorcm mode, requiring an external eMMC programmer to fix.

 

[Basketto]

Caffeine and Nereba both utilize payloads to boot CFW. However these are triggered when the console is hooked up to the Internet. AutoRCM boots the console into RCM which can only accept payloads in RCM which a patched console cannot accept.

You can launch cfw through the software base exploit that @Draxzelex mentioned above, but if the person enable autorcm through hekate then the unit would brick, as it would be stuck in autorcm mode forever.

I see, so even with a patched switch ,the above online exploits can still be utilized to send payloads provided your under X FW. Useful to know, Ty.

 

[Hayato213]

I see, so even with a patched switch ,the above online exploits can still be utilized to send payloads. Useful to know, Ty.

Yea rcm mode, and software base exploit are just entry points allowing you to launch CFW.

 

[rfg]

Word to the wise, It says "Spinner will freeze on firmwares 4.0.0 - 4.1.0" on the page that shows inside your Switch, but 4.0.0 isnt actually supported.
Got pretty fooled by that. Almost locked out of support.
Thankfully, I have a Cartridge that requires 4.1.0, so I just plugged it in, clicked OK to accept its update (MAKING SURE I HAD INTERNET CONNECTIONS DELETED FIRST!!!!!!!)
Then I was back to 4.1.0, ready to go back to 4.0.1

do you still have the supernag after downgrading to 4.0.0 and coming back to 4.1.0?

 

[PRAGMA]

do you still have the supernag after downgrading to 4.0.0 and coming back to 4.1.0?

I never had the super nag to begin with, but I was downgrading to try lessen the likeliness of it occuring

 

[Teamofwinter]

Hello please some one respond
I bought a switch from a month and i was never able to use it
I am new to the hacking stuff can someone explain to me what are the fuses excatly like security or actual fuses and also i have a patched switch which i updated withouT knowing i shouldn't

 

[Draxzelex]

Hello please some one respond
I bought a switch from a month and i was never able to use it
I am new to the hacking stuff can someone explain to me what are the fuses excatly like security or actual fuses and also i have a patched switch which i updated withouT knowing i shouldn't

Fuses are used to prevent downgrades. This is done through the console expecting a certain number of burnt fuses for every firmware version. If you have more fuses burnt than the firmware you are trying to boot, the console will not launch. Since you already updated your patched console, your options are to sell it and buy an unpatched console or if you have soldering skills, to wait for TX's new modchip.