[vii]

Same for the Nintendo Switch.

Older firmware has exploits, which allow installing Ubuntu, etc. To prevent exploiting, old firmware refuses to boot if the new firmware has ever booted. This is marked by blowing fuses.

Note - there is even a fuse that when blown, prevents other fuses from being blown!

https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-323...

[saagarjha]

This is what distinguishes a normal iPhone from one that Apple engineers use, as well. If the fuse is blown, as it is in a production device, you can no longer control the boot chain.

[strombofulous]

Is there a downside to blowing that anti-blow fuse? Can its state be read?

[numpad0]

It’s like an EEPROM that holds major version numbers and debug configurations. If fuse says “major version:20 allow debug: no, allow unsigned: no” and updater is for version 17->18, the user is trying to force a downgrade on a production board. Usually the updater refuses to continue and kernel do the same upon boot. Updater itself is signed and verified so checks are supposed impossible to bypass.

I believe Xbox 360 one was rewritable while Switch one is not. They also require higher voltages than rest of CPU to write. So modders used to modify PCB to block writes or tried to write old values. For Switch they had unrelated nonupdatable boot exploits to bypass signature checks for early batches.

[Dylan16807]

Right, but they weren't asking about those normal fuses, they were asking about the special fuse that disables fuse-blowing.

And the simplest answer is that code could check if the fuses are reading out too early a version and abort. Which you could try to patch around but it won't be easy.