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.