Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wii U SDBoot1 Exploit “paid the beak”

consolebytes.com

Post reply on HN
Print view View original

11–20 of 31 posts

Re: Wii U SDBoot1 Exploit “paid the beak”

#11

Post by aspenmayer »

Razengan wrote: post #10

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 indi…

> 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.

I’m not sure if this will do what you want, but it is Linux on a DS! No active developers at the moment. They have instructions to build your own images as well as some software built for it.

https://www.dslinux.org/

Re: Wii U SDBoot1 Exploit “paid the beak”

#12

Post by dlenski »

josephcsible wrote: post #9
mjg59 wrote: post #5

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 mechan…

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.

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.

Re: Wii U SDBoot1 Exploit “paid the beak”

#13

Post by bananaboy »

Razengan wrote: post #10

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 indi…

There is the commander x16 from the 8-bit guy https://www.commanderx16.com/ although it’s not in a handheld form factor.

Re: Wii U SDBoot1 Exploit “paid the beak”

#14

Post by dontlaugh »

Razengan wrote: post #10

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 indi…

Probably the closest thing is a Steam Deck with a custom Linux distro.

Re: Wii U SDBoot1 Exploit “paid the beak”

#16

Post by mjg59 »

josephcsible wrote: post #9
mjg59 wrote: post #5

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 mechan…

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.

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

Re: Wii U SDBoot1 Exploit “paid the beak”

#17

Post by bananaboy »

wileydragonfly wrote: post #15
bananaboy wrote: post #8

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.

Nice try, Nintendo lawyer.

Haha, I’m not though. I’m actually a professional game developer and have worked on the Wii and wiiu. But there’s no way I can express curiosity about this without sounding like a lawyer. Have an upvote though haha.

Re: Wii U SDBoot1 Exploit “paid the beak”

#18

Post by Cerium »

mjg59 wrote: post #16
josephcsible wrote: post #9

Earlier quoted context omitted.

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.

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 busi…

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.

Re: Wii U SDBoot1 Exploit “paid the beak”

#19

Post by RainyDayTmrw »

josephcsible wrote: post #9
mjg59 wrote: post #5

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 mechan…

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.

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.

Re: Wii U SDBoot1 Exploit “paid the beak”

#20

Post by aspenmayer »

Razengan wrote: post #10

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 indi…

Sorry to double reply, but I wanted to make sure you also saw this: Linux (edit: and Android!) on a Switch.

https://switchroot.org/

Post reply on HN