How the Nintendo Switch prevents downgrading
With the recent announce that Nintendo Switch 3.01 patches a critical vulnerability of the Switch OS, people on the scene are asking around if a downgrade of the console is possible. It’s not, and here’s why.
Why do people so badly want to downgrade their consoles?
Typically (although that’s not always true), the more up-to-date your console is, the more secure it is. As hackers find vulnerabilities on the device, a manufacturer such as Nintendo will fix the vulnerabilities to make it hard for tinkerers to hijack the device.
Historically, on previous generations of gaming consoles, a way that had been found to bypass this, was to downgrade the console to a former revision of the firmware that still had all the vulnerabilities and hacking tools. In the old PSP days, it was very common for people to downgrade their consoles to firmware 1.50 in order to enjoy the many benefits of that very vulnerable firmware.
Arguably, downgrading through software means often implied that a kernel/root exploit was involved, which in theory means that if you were on a firmware that could be downgraded, you could potentially be able to run homebrew on that same firmware. But downgrading to a popular homebrew firmware was a much quicker way to get access to all the homebrew tools, than wait for hackers and developers to port all of the tools to higher firmwares.
Without access to software exploits, downgrade has still been possible through hardware means. These hacks would for example restoring an old backup of the console’s firmware, or patching it to allow for a downgrade. In most cases, due to how the firmwares are tied to a console uniquely, these techniques would require a backup made from the exact same console that is being downgraded.
How the Nintendo Switch and other modern consoles block downgrades
How does a console manufacturer prevent its users from re-writing a clean backup of an older version of the firmware to their console? The answer, according to the Switchbrew wiki, is eFuses.
eFuses, similar to their macro electrical counterparts, are tiny elements inside the CPU that can be “burnt” to permanently change the state of the CPU.
Specifically, when you successfully install a new Firmware on the Nintendo Switch, it will burn some eFuses on the CPU to “mark” a point of no return.
For example: Firmware version 3.0.0 expects 3 fuses to be burnt, but firmware version 3.0.1 expects 4 fuses to be burnt. When you install firmware 3.0.1 on the Switch, the console will make sure it burns enough fuses to reach a total of 4. If you try later on to downgrade to 3.0.0, the console will expect to have 3 burnt fuses or less. Realizing there are already 4 of them, the console will enter system panic and refuse to do anything. From the Switchbrew wiki:
System version Expected number of burnt fuses (retail) Expected number of burnt fuses (non-retail) 1.0.0 1 0 2.0.0-2.3.0 2 0 3.0.0 3 1 3.0.1 4 1
If too many fuses are burnt the bootloader will panic immediately.
If too few are burnt, the bootloader will enable fuse programming and write the expected value to fuse indexes 0x3A and 0x3C. Afterwards, fuse programming is disabled and a magic value (0x21 == TEGRA210) is written to PMC_SCRATCH200 register (0x7000EC40). Finally, the watchdog timer is initialized and programmed to force a reset.
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 magic value (0x21 == TEGRA210). 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.
Abandon all hope of a Switch Downgrade?
All of this happens at a very low level on the CPU. Even without looking at the Nvidia Tegra’s specification, it’s probably obvious that these fuses, whether they are mechanical or software constructs, can only been set to “1” and never back to “0” (unset), mimicking real life old school fuses.
Interestingly, the eFuse concept was invented by IBM with the original intent to prevent defects (much like real life fuses) by modifying the behavior of chips at runtime. However companies such as
Sony*, Microsoft (According to Wikipedia, The PS3 and the Xbox 360 have similar eFuses), and lately Nintendo have used eFuses to prevent downgrades, with the mechanism described above.
* Update/correction from Wololo: hacker Mathieulh stated that Sony is not using the PS3 eFuses to prevent downgrades, but instead to program some unique-per-console keys at manufacturing time. He says:
Sony did not (and still does not) uses eFuses to prevent downgrading (they are dedicated to store per console settings at factory). Downgrading is prevented using hashes in syscon’s NVS, revocation lists (on ps4/ps vita) and stripping PUP header keys from existing modules. The per cpu key used for metldr and bootloader encryption is programmed using the fuses.
However it is confirmed that the XBox 360 used eFuses to some extent to prevent downgrades.
Nintendo using eFuses to prevent downgrades does not necessarily mean that downgrades are completely impossible. There might be ways to bypass the fuse verification, at a hardware or software level. But like other securities on a gaming console, this is here to at least significantly delay tinkering attempts on the Nintendo Switch.