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.
bri3d 43 minutes ago [-]
I think they _might_ have thought a little farther than this; as far as I can tell this tool was _supposed_ to only boot images with the same security checks as the actual fused state of the console, and the issue was that the section header parsing code was vulnerable to a trivial attack which allowed arbitrary execution, which of course could then bypass the lifecycle state checks.
I'd extend your thesis to "you need to audit your recovery tools with the _exact same_ level of scrutiny with which you audit your production secondary bootloader, because they're effectively the same thing," which is the same concept but not _quite_ as boneheaded as you suggest.
Recently, I see this class of exploit more commonly, too: stuff like "there's a development bootloader signed with production keys" has gone away a little, replaced with "there's a recovery bootloader with signature checking that's broken in some obvious way." Baby steps, I guess...
josephcsible 19 minutes ago [-]
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.
bri3d 2 hours ago [-]
This reminds me a lot of the PSP Pandora's Battery: a special factory "boot from external flash" system with exploitable vulnerabilities - on PSP, the special Pandora's Battery "JigKick" serial number 0xFFFFFFFF or the factory battery challenge/response "Baryon Sweeper" on newer consoles, followed by a rather complicated exploit in the "ipl.bin" signature checking process on the external hardware. On the Wii U, the "unstable power" battery jig followed by a simple overflow in SDBoot1.
That was super interesting! Are there any details on how/where they found the sd and memory cards? It seems like you’d have to be incredibly lucky to find something like that.
int0x29 40 minutes ago [-]
I've seen people exploit hardware by messing with the power supply before. I've never seen it be the intended manufacturer maintenance key.
Razengan 9 minutes ago [-]
Sort of a related tangent:
Some of the best gaming time in my life has been on handheld consoles, even when the games were available on PC or TV.
I wish there was a modern platform (not just a hobbyist Raspberry Pi kit or something) in the Switch or DS form factor, that boots straight into a coding environment like the legendary Commodore 64 and other "computer-consoles" of that era, with a central app store for indie devs to publish to for free. Add in dedicated support from a game engine like Godot, and I think something like that could spark a renaissance of solo devs/buddy teams experimenting with new game ideas and stuff.
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.
I'd extend your thesis to "you need to audit your recovery tools with the _exact same_ level of scrutiny with which you audit your production secondary bootloader, because they're effectively the same thing," which is the same concept but not _quite_ as boneheaded as you suggest.
Recently, I see this class of exploit more commonly, too: stuff like "there's a development bootloader signed with production keys" has gone away a little, replaced with "there's a recovery bootloader with signature checking that's broken in some obvious way." Baby steps, I guess...
https://www.psdevwiki.com/psp/Pandora
https://github.com/khubik2/pysweeper
Some of the best gaming time in my life has been on handheld consoles, even when the games were available on PC or TV.
I wish there was a modern platform (not just a hobbyist Raspberry Pi kit or something) in the Switch or DS form factor, that boots straight into a coding environment like the legendary Commodore 64 and other "computer-consoles" of that era, with a central app store for indie devs to publish to for free. Add in dedicated support from a game engine like Godot, and I think something like that could spark a renaissance of solo devs/buddy teams experimenting with new game ideas and stuff.