Wii U SDBoot1 Exploit “paid the beak” • Hacker News Board

Re: Wii U SDBoot1 Exploit “paid the beak”

#21

Post by c0l0 » Sat, Jul 19, 2025, 7:36 AM UTC

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…

Alas, it will virtually exclusively "be shipped to consumers as a default".

Re: Wii U SDBoot1 Exploit “paid the beak”

#22

Post by speps » Sat, Jul 19, 2025, 9:08 AM UTC

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…

Some SBC handhelds do support Pico-8 platform apparently, worth a try:https://youtu.be/R5jZRV2D-rM

Re: Wii U SDBoot1 Exploit “paid the beak”

#23

Post by kotaKat » Sat, Jul 19, 2025, 11:22 AM UTC

bri3d wrote: post #4

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

Oh. TIL they found the pins to trigger Manufacturing Mode in the last ~4 years on the final few 'unbrickable' PSP models... neat!

Re: Wii U SDBoot1 Exploit “paid the beak”

#24

Post by Nursie » Sat, Jul 19, 2025, 11:26 AM UTC

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…

> never sign any executable that can boot on shipped hardware unless you'd be ok with everyone running it on shipped hardware.

How about if, when the lead engineers are on holiday, you ship the first batch of production units with a root a key that’s on everyone’s laptop and has been pushed to bitbucket, and been used to sign all sorts of things for dev units? Then, when confronted with that, you say “oh right, well… can we delete it from those places and import the key to the HSM? We’ll use it as the prod key going forwards?”

I was sad when that payment terminal never made it to market, but in the end perhaps it was for the best.

Re: Wii U SDBoot1 Exploit “paid the beak”

#25

Post by cout » Sat, Jul 19, 2025, 11:37 AM UTC

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…

Even if you had the machine, it is not enough.

What was magical about that coding environment is that you could go to the store and pick up a computing magazine and type in a game. Then you could play it and tweak it as you wanted. I have no idea what the equivalent would be today; the cost analogue I can think of is watching Mario maker or Minecraft videos and then implementing what you learn in your own world or level.

Re: Wii U SDBoot1 Exploit “paid the beak”

#26

Post by crims0n » Sat, Jul 19, 2025, 12:59 PM UTC

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 think the golden years for this were around the PSP/DS homebrew scene circa 2006. I have some really fond memories of following the latest developments in the community, experimenting with toolchains, and general learning about programming and hardware.I was kinda playing around with C before this, but the scene really sparked a lifelong interest.

Re: Wii U SDBoot1 Exploit “paid the beak”

#27

Post by numpad0 » Sat, Jul 19, 2025, 3:02 PM UTC

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.

Left two in the first image and two at the bottom in the second image, possibly top right too, contain Chinese characters. The rest is Japanese. Chinese characters cannot be typed on Japanese systems in normal means and vice versa, so, Chinese factory dumpster leak?

Re: Wii U SDBoot1 Exploit “paid the beak”

#28

Post by BobbyTables2 » Sat, Jul 19, 2025, 4:22 PM UTC

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…

Indeed, having done the whole developement/test/manufacturing workflow using hardware based secure boot , I realized likely very few people ever do it properly.

We had developer keys and production keys. Burning one-time fuses with the production key meant developer code would be rejected.

It took a high amount of discipline and a lot of work in the build process (separate developer/production builds of components and corresponding signing).

Very few people had access to the production signing mechanism and I avoided signing root enabled builds, even though such would be extremely convenient. Other teams… freely published production signed internal use developer firmware internally (to the whole company).

Sadly, nobody gets an award for doing it right, and rarely face consequences for doing it wrong.

Re: Wii U SDBoot1 Exploit “paid the beak”

#29

Post by ProtoAES256 » Sat, Jul 19, 2025, 4:42 PM UTC

numpad0 wrote: post #27

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.

Left two in the first image and two at the bottom in the second image, possibly top right too, contain Chinese characters. The rest is Japanese. Chinese characters cannot be typed on Japanese systems in normal means and vice versa, so, Chinese factory dumpster leak?

I think you've mistook Kanji characters(Japanese) as Chinese characters, some chars are the same even in writing order, even though not shared in the same char codespace.

Re: Wii U SDBoot1 Exploit “paid the beak”

#30

Post by numpad0 » Sun, Jul 20, 2025, 5:30 AM UTC

ProtoAES256 wrote: post #29

numpad0 wrote: post #27

Earlier quoted context omitted.

Left two in the first image and two at the bottom in the second image, possibly top right too, contain Chinese characters. The rest is Japanese. Chinese characters cannot be typed on Japanese systems in normal means and vice versa, so, Chinese factory dumpster leak?

I think you've mistook Kanji characters(Japanese) as Chinese characters, some chars are the same even in writing order, even though not shared in the same char codespace.

Unicode Hanzi/Kanji map is a huge political mess, but writings in CJK are divergent enough that anyone fluent in one can often just tell which one a character is from. Mutual intelligibility never existed and very little content is shared across the language spheres, which lead to each ones having its own self-emergent mannerisms with regularized shapes of characters and which ones to use.

In this instance, "稱" and "號" used on some of printed labels in place of "称" and "号" are outside of current Japanese common use(though "號" wasn't uncommon until very late in 20th century) and I can tell that the system used to print those labels must have been configured for Traditional Chinese(HK/TW). As for the handwriting, it just looks Chinese to me.