
How the Nintendo Switch prevents firmware downgrades - jonluca
https://hackernoon.com/how-the-nintendo-switch-prevents-downgrades-by-irreparably-blowing-its-own-fuses-884bd3b7a8ba
======
BillinghamJ
The wording of the title makes for a kinda misleading implication. This is
pretty standard - they're called e-fuses. It isn't "blowing" in the sense that
an actual fuse does, but it is permanently/irreversibly writing bits to
indicate the minimum version.

~~~
apostacy
Apple and Google will coerce you into installing updates that irreversibly
remove functionality, so think describing the fuses as being "blown" is the
best word to use, since it implies damage being done to your device.

I can at least understand game console developers doing this. But it has
become standard practice now.

I forgot my new pin on my iPad, and Apple forced me to take an update that I
didn't want in order to restore it, which broke several features that I
liked[1]. After iOS8, there is no way to decline updates, they will just keep
getting downloaded.

My mother and grandmother both had their iPads hobbled by destructive updates
as well. My Mom was going to give her old iPad 4 to one of her students so
they could use this learning app, but Apple updated her iPad while she was
sleeping one night, and iOS10 is so slow it is barely usable.

Can we please stop excusing this behavior by using neutral language? Companies
clearly know that these updates are unwanted, or else they would let your roll
them back. Retroactively removing features and damaging devices that people
have paid for should be illegal.

[1]:
[https://news.ycombinator.com/item?id=11986500](https://news.ycombinator.com/item?id=11986500)

~~~
nkristoffersen
Perhaps you don't work in software, but you definitely want constant updates
for an internet connected device. Apple has a track record for providing
software updates for a long time past initial device release. Do you think
more manufactures should be following their lead? The "cyber" world would be a
much more secure place with constant updates.

~~~
pritambaral
Perhaps you don't work with non-user-hostile software, but you definitely want
constant _security_ updates for an internet connected device.

No reason for constant _feature_ updates to keep the cyber world secure. It's
a shame some software vendors bundle them together inseparably.

~~~
Operyl
On the other hand, you’re implying that they should maintain patches for every
single version of iOS released? Because every minor includes new features.
That’s asinine.

~~~
pritambaral
Ubuntu, a free, open source OS, maintains and backports security patches for
n-2, n-1, and n LTS releases.

LineageOS, a free, volunteer-run open source mobile OS, maintains and
backports security patches for n-2, n-1, and n Android versions for phones.

Red Hat, the maker of RHEL, a paid, open-source OS — and its free, open-source
duplicate CentOS — maintains and backports security patches for 10 years.

Microsoft Windows 10, a paid, closed-source OS pushed aggressively by
Microsoft to the point of being sued, bundles feature and security updates on
users like every real-world installation is for beta-testing. The LTSB branch
is not available/accessible to individual users, and it looks like that will
also start bundling feature updates with security updates.

Apple's iOS, a paid, closed-source, locked-to-hardware OS that supports
devices sold in the past three years bundles feature and security updates and
aggressively pushes updates on people's devices. There is no LTS branch of
iOS.

~~~
Operyl
I'd argue that these operating systems are much, much simpler than the entire
stack that is iOS and its built in applications and services.

~~~
pritambaral
I strongly disagree — not that that would be sufficient excuse.

It's not like the kernel and drivers are spread across disparate layers of the
iOS stack. It's not like iOS doesn't have libraries and system services and
thus has to duplicate code across disparate layers of the iOS stack. It's not
like Apple can't or doesn't have special code accessible only to Apple's apps
and iOS internals.

As of right now, there are only a handful of hardware configurations iOS has
to support, and a single software configuration. Compared to the tens of
different hardware and software configurations LineageOS has to support, or
the hundreds of different hardware and software configurations Ubuntu and Red
Hat have to support, or the thousands of different configurations Microsoft
has to support, Apple's job here is a lot easier.

------
sjm-lbm
FWIW, the concept here isn't exactly new - at least the Xbox 360 and a few
other devices have had similar functionality[1].

[1] [http://www.tested.com/tech/585-how-efuses-work-and-why-
theyr...](http://www.tested.com/tech/585-how-efuses-work-and-why-theyre-not-
as-bad-as-you-think/)

~~~
haZard_OS
The very first paragraph of the article made this clear already. It even
mentioned the Xbox by name.

------
bArray
>Blowing a fuse is irreversible— once it’s been set it can never be undone.

Sounds impossible, until you find out that if you don't blow them hard enough
you can get fuse re-flow under hot conditions. Good fun to debug.

In theory (untested to my knowledge), if you super cool the chip you could
lower the resistance of the fuse and prevent it from blowing and absorb heat
around the fuse, but it's probably not all that practical for casual game
players.

As for getting to the problem at hand (force downgrading your system), some
potential solutions (nothing easy):

* Careful control over the chip's power and you could perform a power supply timing attack, tricking the processor logic. This seems like a bit of a stab in the dark though.

* Assuming the bootloader is loaded into some form of RAM, you could look towards modifying the RAM as the chip boots to contain some kind of "skip" code for set pins. Game consoles have hardly been beyond the realm of needing mod-chips to access different features...

* The other option would be to replace the chip containing the bootloader with a non-upgraded one.

------
leggomylibro
>It’s theoretically possible to physically modify the SoC and replace the
fuses, but it’s so prohibitively invasive and expensive that it’s not a real
option.

Are there any examples of this being done? Not necessarily on the Switch, just
with these sorts of fuses. It can be really interesting to see people repair
SoCs, like in this iPhone repair:
[https://www.youtube.com/watch?v=nap0gtds5tQ](https://www.youtube.com/watch?v=nap0gtds5tQ)

------
ythn
Seems like you could still "downgrade" via an upgrade:

1\. Disable firmware digital signature verification (not sure if this is at
the hardware level or not)

2\. Modify the older firmware such that its reported version is newer than
your current version

3\. "upgrade" to the older firmware version

~~~
notriddle
> 1\. Disable firmware digital signature verification (not sure if this is at
> the hardware level or not)

That's supposed to be very difficult to do.

~~~
Scaevolus
Exactly, every stage of the boot is supposed to validate the next stage before
continuing.

The recently discovered bootrom exploits break that chain of trust, allowing
unsigned code to execute.

------
polyomino
E fuses require a lot of power to burn in the fuse. So find the pin in the
chip with high voltage, and suppress it to prevent e fuses from burning in.

~~~
koala_man
I would assume that the firmware also verifies that the fuses have been burnt
before continuing booting.

~~~
dpiers
It does, but this prevents your system from being irreversibly updated by
accident. I remember removing R6T3[1] on my Xbox 360 so that it wouldn't
accidentally be updated to a non-homebrew/exploitable version. Without the
resistor present, the voltage wasn't high enough to burn the eFuses. An update
could run, fail to boot, and I could reflash it to the old version.

1: [http://www.free60.org/wiki/R6T3](http://www.free60.org/wiki/R6T3)

------
internalfx
How many fuses does it have?

~~~
jonluca
There are 256 bits in ODM_RESERVED, and 8 ODM_RESERVED, so I think there are
32 bits. That's 32 major FW revisions (as it seems they're only blowing a fuse
for every X.0.0 version)

~~~
zylent
If there are 256 bits, wouldn't they just burn one bit per major revision
leaving 256 possible revisions?

Is there something I'm missing here?

~~~
NedIsakoff
256 bits in all ODM_RESERVED. There are 8 ODM_RESERVEDs. 256/8 = 32 eh?

~~~
zylent
Ahh, I didn't catch that and was thinking ODM_RESERVED_8 = 256 bits.

Thanks!

------
zorkw4rg
Maybe for their next console they could wire the case so it will destroy some
crypto chips when anyone attempts to open it. Another idea might be to wire in
a radio clock with a set date in the future that causes a over voltage in the
SoC, that could be more accurate than to rely on the obsolescence of the glued
in battery. Also I think they should learn from Sim City (2013), I know EA
eventually released a patch that put the server side single player code in the
client again, but Nintendo should learn from that mistake.

But with all seriousness, Nintendo really should learn from the failures in
their past, I mean come-on! I can _still_ play Zelda on my original Game Boy
Pocket I can even replace the batteries without any tools, come on what were
they thinking!

/edit although.. I do like that you damage the switch everytime you put it in
the dock, must give them that

