A New Kind of Nintendo DS

The Nintendo DSi arrived as a revision, but calling it a thinner DS Lite misses the reason it became historically interesting to hardware researchers. Nintendo’s Japanese announcement in October 2008 described larger screens, two cameras, an SD-card slot, internal storage, DSi Camera, DSi Sound and downloadable software. The machine still accepted Nintendo DS Game Cards and retained the familiar dual-screen, touch-controlled format, yet it also introduced a second layer of hardware and software that the earlier DS models did not possess.

That distinction became especially important after Nintendo released the DSi in Japan on November 1, 2008, followed by wider-market launches in 2009. To a casual owner, the new model looked like a more convenient DS: slimmer, camera-equipped and able to store photographs. To developers, it was a platform with a faster processor mode, more memory, revised wireless hardware, NAND flash storage and a system menu capable of managing downloaded titles. Those additions created new capabilities, but they also created new places where Nintendo could enforce trust.

The DSi XL, introduced in 2010, enlarged the two displays to 4.2 inches without replacing that underlying architecture. Its software compatibility remained centered on Nintendo DS and Nintendo DSi titles. The larger body changed viewing comfort and the way low-resolution graphics appeared, but it did not create a separate security ecosystem. For the history of modification, the original DSi and DSi XL therefore belong to the same family, even if their screens and physical handling are noticeably different.

The Older Console Inside the New One

Nintendo’s developer material uses related names for the DSi’s two software environments. NITRO, often shortened to NTR in reverse-engineering documentation, refers to the older Nintendo DS-compatible world; TWL refers to the DSi environment. The terminology reflects more than branding. A conventional DS program can continue to run with the assumptions of the original handheld, while DSi-aware software can request additional memory, processing power, storage, cameras or newer wireless features.

Technical and reverse-engineering documentation places the DSi’s main memory at 16 megabytes, compared with 4 megabytes on the earlier DS family, and identifies an ARM9 processor capable of running at roughly 133 MHz alongside a 33 MHz ARM7 subsystem. Those figures are reconstructed technical facts rather than launch specifications from Nintendo’s consumer manuals. Their practical significance is clearer than the numbers themselves: DSi software could be built for a substantially better-provisioned machine without abandoning compatibility with the existing DS library.

The wireless system made the split particularly visible. The DSi retained a legacy NITRO wireless path for backwards-compatible software while adding a TWL wireless module for DSi-native applications. The newer path supported stronger protocols, including WPA and WPA2, whereas ordinary DS software continued to operate under the older compatibility model. The two paths were not simply interchangeable settings. A program’s execution mode determined which hardware and system services it could use.

Nintendo’s developer documentation also separated the DSi’s storage into distinct categories. System NAND held firmware, settings and installed applications. The SD card was removable storage intended for photographs, music and other approved data. Game Cards carried their own ROM and, where implemented, save memory. A title launched from one medium did not automatically gain permission to read every other medium. The DSi was therefore not a general computer that happened to have an SD slot, but a controlled system with narrowly defined routes between storage and software.

Why the SD Slot Was Not an Open Door

The presence of an SD card encouraged an understandable assumption. If the DSi could read files from removable storage, perhaps it could simply run programs placed there. Nintendo’s software model did not work that way. DSiWare titles were installed and launched through the DSi’s system-managed title environment, yet their ability to access protected services remained governed by title-management and operating-system layers. Developer documentation distinguished system NAND, SD storage, Game Cards and backup memory as separate media classes rather than treating them as interchangeable directories.

TWL software also introduced additional integrity checks. Nintendo’s developer documentation directly records TWL ROM-data hash checking and the associated boot-time cost. Later reverse-engineering records identify RSA-related material, signatures, headers and title metadata in particular DSiWare and TWL-related paths. Together these support a layered account, but not a claim that one identical cryptographic procedure protected every DSi asset or title class.

That distinction also clarifies the difference between confidentiality and authentication. Encryption can make content difficult to read or alter without a key. A signature or hash can help the system recognize content that has been changed or was not authorized. The DSi’s security history involved both ideas, but the practical barrier faced by early experimenters was often whether the console would accept a particular cartridge, title or save structure at all.

The Cartridge Problem Carries Forward

Before the DSi, enthusiasts had already spent years studying Nintendo DS game copiers, commonly called flashcarts or linkers. These aftermarket cartridges placed storage and a loader behind a Game Card-shaped interface, attempting to make the console treat the device as an accepted game card. The surrounding legal record from the period describes products with built-in memory or removable memory cards and discusses how substantial game code was transferred into the console’s RAM.

A flashcart therefore approached the machine from the cartridge boundary. It supplied hardware that had to behave convincingly enough during card recognition and data transfer, then used its own software to select what would run. That was very different from an ordinary DS program discovering a hidden operating system privilege. Passing the initial cartridge checks did not automatically grant access to the DSi’s cameras, NAND or TWL-only services.

Nintendo responded to the expanding copier market with both technical countermeasures and litigation. A 2009 United States preliminary-injunction order named several DS- and DSi-compatible copier products, including models marketed for the newer handheld. A 2010 English High Court judgment likewise examined game-copying devices and their interaction with authentication and memory loading. These decisions are useful historical evidence of how the companies and courts characterized the devices, but they do not prove that every product behaved identically or that every owner used one for infringement.

The DSi raised the stakes because Nintendo could use system software to identify and reject known cartridge products. This made compatibility a moving target. A copier’s behavior depended on its hardware, loader and firmware support; Nintendo’s updates could change the result without altering the physical cartridge slot. The machine was still cartridge-centered in one sense, but it was no longer a static target.

The DSi’s Boot Chain

Reverse engineers eventually described the DSi startup process as a sequence of stages rather than a single BIOS-style barrier. Separate ARM9 and ARM7 boot components, protected memory areas, firmware-loading structures and RSA-related material all played roles in deciding what the machine would execute. Some analysis indicated that the ARM9 began at a lower speed during early verification work before switching to its faster operating state for cryptographic calculations. These findings came from studying firmware and hardware behavior, not from Nintendo’s consumer manuals.

The resulting privilege boundaries mattered more than any individual technical curiosity. A program running as a normal DS cartridge application did not automatically become a supervisor of the DSi. NTR software entered the older compatibility environment. TWL software could use additional resources, but only within the permissions granted by the system. DSiWare titles were installed and launched through the DSi’s system-managed title environment, yet their ability to access protected services remained governed by title-management and operating-system layers.

Nintendo’s update history illustrates the continuing contest without revealing every detail. The North American system progressed from version 1.3U through 1.4U in August 2009, 1.4.1U in September 2010 and later revisions, eventually reaching 1.4.5U in December 2012. Nintendo’s public notes often described performance or behind-the-scenes changes rather than naming specific security fixes. Claims that a particular update blocked a particular exploit therefore require evidence from the exploit’s contemporary developers, not assumptions based solely on the menu version.

Emulation as a Separate Line of Inquiry

The DSi’s early technical history also overlapped with no$gba, the emulator and debugger associated with Martin Korth. During the period when physical documentation was scarce, experimental DSi support in no$gba gave researchers an additional software environment for observing documented DSi behavior. Surviving release records show incremental DSi-related support, but they do not by themselves establish a complete chronology or prove that every register, storage behavior or timing characteristic was accurately reproduced.

That qualified contribution still mattered. An emulator could provide a controlled place to compare software expectations and inspect how documented features were represented, while sparing researchers repeated experiments on original hardware. The surviving public chronology is distributed across release records and community archives rather than one definitive developer announcement, so claims about the first or most complete DSi emulation should remain cautious.

no$gba remained an emulator and debugger, not a bypass of the original hardware’s boot chain. Code running in an emulator demonstrated what that emulator reproduced; it did not prove that an unmodified DSi would accept the same code. Emulation, browser or application-based code execution, and a hardware boot-chain compromise are separate events.

From a Single Exploit to a Community Practice

SudokuHax demonstrated that the DSi’s approved software path could be turned against its own assumptions, but it was not yet a comfortable homebrew platform. It depended on one specific application, a particular savedata relationship and a process that ordinary owners could not reasonably mistake for an official feature. Its importance was therefore architectural rather than practical: it showed that the boundary around DSi-native execution could be crossed from within a signed title.

The next phase was shaped by communities that treated each new exploit as a research instrument. DSiBrew collected observations about hardware registers, firmware behavior, storage formats and exploit compatibility. HackMii documented public releases and credited contributors. Later guides translated that specialist knowledge into repeatable, user-facing entry points. These projects did not all share the same aims. Some focused on discovering vulnerabilities, some on preserving the platform, some on writing new software and others on making existing homebrew easier to launch. Their combined effect was to turn isolated demonstrations into an ecosystem.

That transformation required a change in language. In the early period, “a DSi hack” could mean a flashcart, an exploit in a downloaded title, an emulator feature or an experimental firmware modification. By the middle of the platform’s homebrew history, developers increasingly separated entry points from payloads, boot control from menus and native execution from emulation. The distinctions were not merely editorial. They helped developers explain why the same program could work from one route and fail from another, and why a successful exploit did not necessarily imply unrestricted access to every component.

Entry Points, Boot Control and Permissions

A temporary exploit is useful for proving that a vulnerability exists, but persistence changes how a community uses a machine. Memory Pit begins inside the DSi Camera application, while Flipnote Lenny begins inside Flipnote Studio. Both require the console to launch an official application before unofficial code can run. They leave the internal boot code untouched, making them useful research and recovery entry points, but every session begins with the same trusted application and each payload inherits limitations from its launching context.

Those limitations are specific rather than universal. Memory Pit has blocked Slot-1 access and blocked DSP access that results in worse sound in GBARunner2. Flipnote Lenny and stylehax generally offer better compatibility in these respects, but they also do not provide Unlaunch’s full Slot-1 access. An application exploit can therefore be perfectly adequate for one program while unsuitable for another; “homebrew works” is incomplete without naming the entry point.

Unlaunch altered that balance by moving unofficial control earlier in startup. It modifies the boot path, allowing earlier control over what the console launches and enabling access that restricted application exploits do not provide. This can include broader Slot-1 access and improved conditions for certain DSi-mode software, while individual services and launch contexts still depend on the software being run. The DSi Guide describes Unlaunch as protecting against most ways a DSi could be bricked, while also documenting that installing or removing bootcode carries a distinct brick risk; that is a project-guide characterization, not a universal guarantee.

This was a qualitatively different breakthrough from SudokuHax. An application exploit takes advantage of a mistake in a program that the system already permits to run. A bootcode modification changes the launch point before ordinary application restrictions apply. The two techniques belong to the same history, but they solve different problems. Writing to boot-relevant NAND also creates a different failure mode from copying files to removable storage, which is why recovery behavior and console-specific backups became important engineering concerns.

The SD Card Becomes a System Environment

Once boot control was available, developers could ask whether part of the DSi’s internal system environment could be represented on removable storage. hiyaCFW’s project documentation describes an SDNAND arrangement that redirects selected NAND activity toward an SD-backed copy of system data. The original hardware continues executing the code; selected file operations are redirected away from internal flash. This is an alternate runtime environment, not a generic firmware disk or a complete emulation of internal flash.

Internal NAND contains console-specific identity and configuration data, and software may depend on region information, title metadata, paths or services that an alternate environment must reproduce. SafeNANDManager’s documentation consequently treats an ordinary NAND backup as belonging to its source console, while describing restoration of another console-unique NAND only under constrained conditions. Even the same console’s image can change through ordinary system activity. A backup is therefore best understood as a historical state and recovery resource for one machine, not as universally portable firmware.

This arrangement revealed the DSi’s unusual position between appliance and computer. Nintendo had designed NAND and SD storage around tightly controlled applications, but homebrew could redirect their relationship. That did not remove assumptions about title metadata, regions, permissions or directory structures; it exposed those assumptions as objects developers could study and, within limits, reproduce.

SDNAND and native SD loading solve different problems. hiyaCFW’s documented approach redirects selected system activity, whereas nds-bootstrap adapts supported cartridge-access functions so DS-family software can execute from SD. A NAND backup records console-specific state. These techniques may coexist, but none should be treated as interchangeable or as the definition of DSi custom firmware.

TWiLight Menu++ is primarily a frontend: it browses software, presents settings and hands launches to an appropriate backend. nds-bootstrap addresses the underlying storage problem because commercial DS software expects a Game Card, not an ordinary filesystem. It patches or redirects supported cartridge-access functions so supported programs can read and write SD-backed data. The software still executes on the DSi’s processors; this is native execution with a compatibility layer, not emulation and not perfect reproduction of every Game Card timing or peripheral behavior.

Some titles require per-game settings or remain imperfectly compatible. DSi-enhanced software presents the clearest test of that distinction. Some preserved titles lack the DSi-specific binaries or data required for native DSi execution. Such a title may still boot in DS mode, but it behaves like the DS version and cannot gain missing DSi features through a menu setting. The software must contain the appropriate DSi code, and the launch environment must be capable of supplying it.

The launch path also matters. Application exploits and flashcarts expose different permissions from Unlaunch, and those differences can affect Slot-1 access, DSi-mode behavior and individual loader features. A compatibility report is therefore meaningful only when it identifies the console model, launch path, loader version and execution mode. “Homebrew works” is too broad to describe every combination.

The current DSi Guide recommends TWiLight Menu++ and nds-bootstrap for many supported DSiWare launches, while identifying installation into internal memory or hiyaCFW’s SDNAND as an alternative for titles that remain incompatible with the loader. That is a project-guide recommendation, not a universal judgment about every title or setup. Flashcarts remain a separate route with their own hardware, loaders and compatibility limits.

The DSi XL has larger 4.2-inch screens while retaining compatibility with Nintendo DS and Nintendo DSi software. Those display differences are separate from the shared exploit, boot and loader architecture. Individual console identity still matters for NAND work, and individual software still determines whether DSi mode is genuinely used.

Why DSi Mode Required New Tools

The DSi’s native capabilities became more visible as development tools improved. A program written for ordinary DS mode could not automatically use the second camera, the newer wireless module or the DSi’s additional memory simply because it was launched on a DSi. Those features required suitable binaries, libraries and execution conditions. Modern DSi development has therefore depended on more than loaders: it has needed a toolchain that understands the hardware Nintendo added but did not broadly open to hobbyist programmers.

BlocksDS represents that later stage of the community’s work. Its development environment targets DS and DSi software in C and C++, with examples and libraries covering areas such as cameras, wireless networking, filesystem access, DSP-related functions and video capture. The significance is not that it makes every undocumented register easy to use, but that it gives developers a maintained foundation from which to investigate and build. A new program no longer has to begin by reconstructing the entire platform alone.

Wireless networking illustrates the divide particularly clearly. BlocksDS documentation supports DSi-mode Wi-Fi with stronger protocols including WPA2, while NiFi remains a backwards-compatible DS-mode facility. A program’s network abilities therefore depend on its build target and launch mode, not merely on the presence of a wireless chip in the casing. Camera and DSP examples make the same point: the hardware is available to native software under appropriate conditions, but access is not automatically granted to every exploit-launched program.

This marks a shift from access research to original software. Memory Pit, Flipnote Lenny and Unlaunch concern routes into the machine; TWiLight Menu++ and nds-bootstrap concern the use of existing software and storage; BlocksDS enables developers to write new applications that treat the DSi as an embedded computer with cameras, touch input, two displays, networking and specialized audio hardware. That is a different achievement from bypassing a title restriction, and it gives the platform a future beyond loading its commercial library.

Nintendo’s Response Moves From Hardware to Distribution

Nintendo’s reaction to DSi modification was shaped by the fact that several attack surfaces belonged to software it had approved. In the cartridge era, a company could target the behavior of aftermarket hardware and pursue distributors. On the DSi, it could also remove vulnerable downloadable titles, issue system updates and alter the checks applied during title loading. SudokuHax’s public release is a clear example: the vulnerable Sudoku application was corrected, and its availability through the DSi Shop was temporarily interrupted.

That response did not mean that Nintendo publicly described every security change. Official update histories often used broad language such as performance improvements or behind-the-scenes changes. The North American record lists versions 1.3U, 1.4U, 1.4.1U and later revisions through 1.4.5U, but the absence of a named exploit from a changelog cannot by itself establish precisely what an update blocked. Exploit developers’ dated announcements and compatibility records are needed to connect a particular release with a particular change.

The 2009 U.S. preliminary-injunction order named specific DS- and DSi-compatible game-copier products and restrained trafficking in circumvention technology. The 2010 English judgment supplies more detailed evidence about game-card communication, memory loading and the operation of the devices examined there. Neither record proves that every listed product behaved identically, that every owner used a copier for infringement, or that homebrew, emulation and piracy were technically identical.

The DSi’s layered design made the industry response similarly layered. Nintendo could patch or withdraw a vulnerable application without redesigning the cartridge slot. It could identify known aftermarket products through system software without eliminating legitimate SD-card functions. It could preserve backward compatibility while tightening the newer TWL environment. These measures did not end experimentation; they changed which entry points remained available and encouraged researchers to move from individual title exploits toward deeper understanding of boot behavior and hardware permissions.

The Platform Outgrows Its Original Scene

By the time contemporary projects such as BlocksDS and the DS-Homebrew tools had become active development targets, the DSi scene had moved beyond the question that defined its earliest period: whether unofficial code could run at all. The harder questions concerned quality and fidelity. Could a program use the DSi’s additional memory without breaking DS compatibility? Could a loader preserve the DSi-specific half of a title? Could wireless code select the correct hardware path? Could a system backup be preserved without treating one console’s identity as a transferable file?

Those questions produced a more disciplined kind of homebrew engineering. Developers documented assumptions, exposed incompatibilities and separated experimental features from stable ones. A loader’s failure with a particular title could arise from missing DSi binaries, card timing or an unavailable privilege—not from a single mysterious “bad ROM” explanation. A network problem could reflect DS-mode limitations rather than a defective wireless chip. A NAND restoration problem could result from console-specific data rather than an incomplete menu installation.

The result was a platform with several simultaneous identities. For preservationists, it was a record of a transitional digital-distribution system and a library of software with DSi-only components. For developers, it was a small ARM-based computer with cameras, touch input, two displays and unusually interesting storage boundaries. For enthusiasts, it was a more convenient way to run homebrew and compatible software from removable storage. These uses overlapped, but none should be treated as the whole story.

The middle era’s lasting breakthrough was therefore organizational as much as technical. Exploit authors, reverse engineers, toolchain developers, loader maintainers and preservation communities turned scattered weaknesses into a body of knowledge. The DSi’s security model remained layered, and its constraints remained real, but the community learned to work at the correct layer instead of treating every problem as a demand for one universal hack.

A Handheld Still Being Finished

Nintendo designed the DSi as a controlled extension of the DS, but its added hardware gave later developers the outline of a small embedded computer. The first generation of public exploits supplied access through approved applications. Bootcode research made that access persistent. SDNAND experiments showed that system storage could be redirected. Menus and loaders made the result practical, while modern toolchains made the cameras, wireless hardware and DSi-specific memory model inviting targets for new software.

The DSi XL belongs to the same continuing story rather than a separate chapter. Its larger 4.2-inch screens alter physical display size, but the relevant exploit, boot and loader architecture remains shared. Individual console identity still matters for NAND work, and individual software still determines whether DSi mode is genuinely used. Those details prevent the XL from becoming either an imaginary security fork or a completely consequence-free clone.

The platform’s future is unlikely to be defined by one final exploit. It is more likely to remain a maintained collection of tools, documentation and original programs whose compatibility improves unevenly. The ecosystem will continue to advance by layer: preservation projects may retain DSi-specific software, loader updates may improve difficult titles, and BlocksDS may expose hardware Nintendo barely used.

That is the DSi’s most durable legacy. Its second life does not consist simply of defeating a menu or replacing a company’s software. It consists of making the machine’s boundaries visible, then deciding which ones matter for preservation, development or ordinary use. The result is a handheld that remains recognizably Nintendo hardware while functioning, decades later, as a documented native platform—one whose cameras, storage, networking and two execution worlds can still be explored on the original screens.

The Distribution Layer Fades Into History

The DSi’s modification history cannot be separated from the changing status of Nintendo’s own distribution system. DSiWare was designed as a managed service: titles were acquired through the DSi Shop, installed into the console’s title environment and tied to the storage and account assumptions of that system. When Nintendo ended new DSi Shop purchases on March 31, 2017, the historical problem changed. Researchers were no longer examining only how software was authorized; they were also preserving a platform whose official acquisition route had ceased to operate in its original form.

That change helps explain why later projects focus on loaders, title metadata, NAND state and original hardware rather than treating an SD card as a replacement storefront. A loader can reproduce enough of a title’s expected launch context to make supported software run, but it does not recreate Nintendo’s transaction service. An SDNAND arrangement can redirect selected system activity, but it does not turn a console-specific identity into a portable account. Preservation therefore involves documenting both the software and the conditions under which the software was meant to exist.

The distinction is historically useful when discussing DSiWare exploits. SudokuHax depended on a particular officially distributed application and its savedata behavior. Later entry points such as Memory Pit and Flipnote Lenny reduced dependence on one vulnerable commercial title, but they did not make the DSi’s original service architecture irrelevant. They exposed a route into native execution while leaving title management, storage permissions and hardware privilege boundaries as separate subjects.

This is also why legitimate homebrew has become a more durable part of the DSi story than any individual storefront workaround. Original camera tools, wireless experiments, diagnostics, accessibility projects and new games remain meaningful even when an official service disappears. They use the surviving console as hardware rather than attempting to recreate every discontinued commercial function, and they give preservation a purpose beyond retaining files alone.

Explore more modding histories

Compare these experiments with our original PlayStation modding history, original Xbox modchip and homebrew history and Dreamcast boot discs and homebrew story. Find more long reads in Editorial Spotlight and explore our game walkthrough library.