A Brief Look at the 3DS Cartridge Protocol
blog.winter-software.com
blog.winter-software.com
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.
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.
The 3DS didn’t have any of those checks so you could actually play online with pirated games.
They didn’t put the game file download process behind an auth layer until very late in the system’s life.
https://wiki.raregamingdump.ca/index.php/Acer_Cloud_Technolo...
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
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
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
[4] Company that built almost the entire N64.
The Gamecube also has the ATI logo on it, it features prominently on the bottom right corner of the front side.
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?
https://github.com/iversonjimmy/acer_cloud_wifi_copy/blob/f7...