←back to thread

Wii U SDBoot1 Exploit “paid the beak”

(consolebytes.com)
160 points sjuut | 6 comments | 18 Jul 25 20:30 UTC | HN request time: 0.215s | source | bottom
Show context
mjg59 ◴[18 Jul 25 23:49 UTC] No.44611125[source]▶
Having spent a while working in embedded and learning that this is not a lesson that's been internalised: this is why you never sign any executable that can boot on shipped hardware unless you'd be ok with everyone running it on shipped hardware. You can not promise it will not leak. You can not promise all copies will be destroyed. If it needs to run on production hardware then you should have some per-device mechanism for one-off signatures, and if it doesn't then it should either be unsigned (if fusing secure boot happens late) or have the signature invalidated as the last thing that happens before the device is put in the box.

A lot of companies do not appear to understand this. A lot of devices with silicon-level secure boot can be circumvented with signed images that have just never (officially) been distributed to the public, and anyone relying on their security is actually relying on vendors never accidentally trashing a drive containing one. In this case Nintendo (or a contractor) utterly failed to destroy media in the way they were presumably supposed to, but it would have been better to have never existed in this form in the first place.

replies(4): >>44611219 #>>44611369 #>>44614565 #>>44616825 #
1. josephcsible ◴[19 Jul 25 00:28 UTC] No.44611369[source]▶
I don't like this advice because it seems like it's only useful to people who want to do tivoization in the first place. I hope people who try to do that keep failing at it, because "success" is bad for the rest of us.
replies(3): >>44611740 #>>44612230 #>>44612944 #
2. dlenski ◴[19 Jul 25 01:34 UTC] No.44611740[source]▶
Agreed. I'm rooting for the continued failure of everyone who locks down hardware (and software) to prevent its users from modifying or fully controlling it.
3. mjg59 ◴[19 Jul 25 03:10 UTC] No.44612230[source]▶
At a social level we should know how to do this well because there are cases where it needs to be done well. Some hardware is operating in incredibly safety critical scenarios where you do want to have strong confidence that it's running the correct software[1].

Should this be shipped to consumers as a default? Fuck no. This technology needs to exist for safety, but that doesn't mean it should be used to prop up business models. Unfortunately there's no good technical mechanism to prevent technology being used in user-hostile ways, and we're left with social pressure. We should be organising around that social pressure rather than refusing to talk about the tech.

[1] and let's not even focus on the "Someone hacked it" situation - what if it accidentally shipped with an uncertified debug build? This seems implausible, but when Apple investigated the firmware they'd shipped on laptops they found that some machines had been pulled off the production line, had a debug build installed to validate something, and had then been put back on the production line without a legitimate build being installed - and if Apple can get this wrong, everyone can get this wrong

replies(2): >>44612681 #>>44613378 #
4. Cerium ◴[19 Jul 25 04:50 UTC] No.44612681[source]▶
Great point, in general I find that the story for security is always hackers but the result is that far more commonly you hack yourself with manufacturing process variation.
5. RainyDayTmrw ◴[19 Jul 25 05:58 UTC] No.44612944[source]▶
I think Apple is time and again proof that Tivoization is highly effective, and that if we want to fight it, the fight needs to be legal, not technical, as much as that may dismay the technically inclined.
6. c0l0 ◴[19 Jul 25 07:36 UTC] No.44613378[source]▶
Alas, it will virtually exclusively "be shipped to consumers as a default".