[HN Gopher] A Brief Look at the 3DS Cartridge Protocol
       ___________________________________________________________________
        
       A Brief Look at the 3DS Cartridge Protocol
        
       Author : todsacerdoti
       Score  : 26 points
       Date   : 2024-06-02 16:39 UTC (2 days ago)
        
 (HTM) web link (blog.winter-software.com)
 (TXT) w3m dump (blog.winter-software.com)
        
       | jasonjayr wrote:
       | 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.
        
         | kmeisthax wrote:
         | 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
         | 
         | [4] Company that built almost the entire N64.
        
       | kmeisthax wrote:
       | 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.
       | 
       | [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.
        
         | sillywalk wrote:
         | 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).
         | 
         | https://www.copetti.org/writings/consoles/nintendo-3ds/
        
       ___________________________________________________________________
       (page generated 2024-06-04 23:01 UTC)