It's funny comparing the effort Nintendo went through in locking down the 3DS, both to how slapdash the BroadON-developed scheme in the iQue, Wii, and DSi were, and to how thoroughly the system got owned and stayed owned once people had a foot in the door. The 3DS had hardware key derivation, strict NX enforcement, DMA attack mitigations, a separate secure zone CPU, hardware-locked save files[0] and a custom microkernel OS with strictly-regulated privileges across separate server processes.
But at the same time, the amount of mistakes[1] Nintendo made implementing these is egregious. That DMA attack mitigation? Wasn't even enabled until a year after smea was distributing exploits that used it. You just asked the GPU to overwrite the application you were exploiting and it happily did so. Firmware builds of the OS intended to service backwards compatibility[2] or service modes were never updated, so you could boot into them and attack that. Most egregiously, they tried re-securing the New3DS with a new bootloader, which actually made the platform less secure as it'd run happily on old hardware and had exploitable bugs.
To make matters worse, the boot ROM was exploitable and Nintendo never bothered to fix it[3]. It even had a hidden service mode that would execute code off a DS flashcart if you held the right button combination while the hinge was closed. You didn't even need to have functioning storage on the device. Not even the Wii was owned this badly.
[0] To be clear, this isn't a good thing for consumers, but it makes it way harder to install entrypoints. On the Wii any system could create save data for any other system, so exploit saves were incredibly easy to install.
[2] Which, mind you, includes managing a built-in GBA flashcart in the 3DS hardware that Nintendo only used for the Ambassador Games because... reasons.
[3] Despite, oddly enough, telling the FCC that they were launching a new 3DS revision with an updated boot ROM.
Among one of the excellent articles on game consoles is the on on the 3DS that references the 3dbrew articles, but provides an easier to higher level explanation of the flaws (along with how the rest of the machine works).
Incompetence is way more likely than intentional sabotage. It was probably just some guy in a suit demanding that they have everything that looks secure so it's not a repeat of the NDS, while giving no time to actually implement anything properly.
The button combination with a closed hinge one is all but confirmed to be deliberate. To my understanding it's meant to be used in Nintendo repair centres to flash a new firmware for refurbished devices. Of course not described as such to repair centre employees, but that was the intended usecase.
Unlikely. It's very difficult to write vulnerabilities that won't immediately be detected by coworkers, who will rightfully implicate you as adding backdoors to the firmware.
The vast majority of software developers are not Freedom-loving Stallmanites like we[0] are. In an economic system in which only scarce things are valuable, moral opposition to enforcing artificial scarcity melts away very quickly, at least in the hearts of the people who make the software. They don't have to be fully on board with the DRM agenda either, they just have to have enough moral indifference to show up to work that day and write the software that does the thing their boss asked for.
[0] To be clear, I think RMS is a terrible person, I just happen to agree with him that proprietary software and the DRM that protects it is harmful.
Most likely none. I doubt any developer working on this intentionally created a security flaw and snuck it in under the radar. Much more likely these are all fuckups caused by the top brass requiring much more security for their devices to "protect" themselves from piracy build by developers who didn't have experience in hardware security.
That is what I thought, too. (There are probably more than one people working on it and some people want to do some of such things deliberately) At least some of the things might be deliberate (such as the working of the hidden service mode); others probably aren't.
Online gaming ended up being the real death of piracy. I’ve got a hacked switch and the experience is significantly degraded since you can’t use any online features.
That’s because on the Switch they figured out how to bind online sessions to digital certificates unique per game copy signed by Nintendo themselves. This way “copied” games can’t get online without being detected.
The 3DS didn’t have any of those checks so you could actually play online with pirated games.
You could download full games directly from the official online store servers using a homebrew front end. They did all the purchase auth on the 3DS but a hacked firmware could bypass it.
They didn’t put the game file download process behind an auth layer until very late in the system’s life.
But that is one of the reason static blog generators are better. It doesn't take that much power to regen the whole site anymore, and it enables serving at a scale, even on a potato VPS
The Article pages are statically generated and cached, that's not the issue here
There seems to be a memory leak going on with my image rn that only came up yesterday when I did the last update. I suspect rn it's related to https://github.com/dotnet/aspnetcore/issues/54405 and am trying out an older build
the VPS has 8gb of RAM and the blog usually doesn't use more than 500mb even when the blog gets hit by fedi, so there is something dubious going on since it kept running up to 4gb RAM over time and then getting killed by linux
The Wii console had RSA logos pretty prominently in the package, I think that suggests that Nintendo contracted or partnered with them to build and implement this scheme.
AFAIK the Wii had hardware crypto in the GPU's IO controller and that's where most of it's DRM happens. Wouldn't be surprised if they licensed the hardware block from RSA. The DS also had the same logo AFAIK but the way the DS and 3DS handled DRM is completely different from the Wii.
For context: the Wii is pretty much a split-brain system. Games run "OS-less" on the PPC, but the IO controller is responsible for, among other things, starting and sandboxing them. Whenever the Wii needs to launch software, the IO controller loads the appropriate code from either the DVD drive or the NAND, then reboots both the main CPU and, if necessary[2], itself. The system menu you're used to interacting with is just a built-in game installed into title slot 0x0000000100000002 (1-2), and that's why the Wii's system software was so primitive.
The Wii's DRM scheme is a derivative of the one used in the iQue[1], which was designed by BroadOn (originally RouteFree, later iGware, finally Acer Cloud Computing). RouteFree itself was founded by Dr. Wei Yen, an ex-ArtX[3], ex-SGI[4] guy who is basically responsible for a good chunk of Nintendo history. The 3DS used, as far as I'm aware, almost none of the code developed for the Wii, mainly because it was a house of cards anyway.
[0] Not to be confused with Apple iOS or Cisco IOS.
[1] Imagine an N64 with the Wii Shop Channel, but everything's in Chinese.
[2] Wii games are built and run to work with a specific major version of the IO controller firmware, and the IO controller will downgrade itself to match the game. This is even user visible. You know the little animation on the disc slot light? If you play a really old game and your Wii gets a push notification, it will actually play the old version of the animation.
[3] Company that built the GameCube GPU before being bought out by ATI, which is why the Wii had an ATI logo on it
> Wouldn't be surprised if they licensed the hardware block from RSA.
The only hardware crypto blocks the Wii had were SHA and AES, there wasn't a hardware RSA block.
Which makes sense, it had to run both SHA and AES over large blocks of data; But RSA was only ever used on small amounts of data to verify tickets, and only when launching a new title.
I'm not sure what they licensed from RSA. The patents for RSA had already expired, so maybe the code?
They probably meant RSA the company (https://en.wikipedia.org/wiki/RSA_Security), which was founded by the inventors of the algorithm, but has sold various other crypto devices and algorithms over the years, though I don't know if they ever sold hardware IP cores, and haven't been able to find anything about it. I feel like it's more likely they licensed patents or maybe code from them though.
But at the same time, the amount of mistakes[1] Nintendo made implementing these is egregious. That DMA attack mitigation? Wasn't even enabled until a year after smea was distributing exploits that used it. You just asked the GPU to overwrite the application you were exploiting and it happily did so. Firmware builds of the OS intended to service backwards compatibility[2] or service modes were never updated, so you could boot into them and attack that. Most egregiously, they tried re-securing the New3DS with a new bootloader, which actually made the platform less secure as it'd run happily on old hardware and had exploitable bugs.
To make matters worse, the boot ROM was exploitable and Nintendo never bothered to fix it[3]. It even had a hidden service mode that would execute code off a DS flashcart if you held the right button combination while the hinge was closed. You didn't even need to have functioning storage on the device. Not even the Wii was owned this badly.
[0] To be clear, this isn't a good thing for consumers, but it makes it way harder to install entrypoints. On the Wii any system could create save data for any other system, so exploit saves were incredibly easy to install.
[1] https://www.3dbrew.org/wiki/3DS_System_Flaws
[2] Which, mind you, includes managing a built-in GBA flashcart in the 3DS hardware that Nintendo only used for the Ambassador Games because... reasons.
[3] Despite, oddly enough, telling the FCC that they were launching a new 3DS revision with an updated boot ROM.