A Handheld Built in Layers
The Nintendo 3DS looked like a continuation of the DS, but its security model belonged to a different generation. Its two screens, stylus and hinged body made the family resemblance obvious; underneath, Nintendo had built a machine in which separate processors handled applications, system services and the decisions that determined what software could be trusted. That division shaped every early modification attempt. Finding a way to make the 3DS run a small unofficial program was one problem. Reaching the part of the machine that verified software, managed storage and controlled the boot process was another entirely.
The distinction is easy to lose when the period is described simply as “3DS hacking.” A game exploit, a commercial flashcart, a homebrew launcher and custom firmware were not interchangeable things. They occupied different positions in the console’s architecture and granted different powers. The history therefore begins less with a particular cartridge than with the question that confronted researchers: which processor had been reached, and what authority did code running there actually possess?
The ARM11 and ARM9 Divide
In native 3DS mode, the main application side uses a dual-core ARM11 processor. One core is generally associated with games and applications, while the other supports system software. Alongside it sits an ARM9 processor, inherited in part from the design lineage that made Nintendo DS compatibility possible but far more important in the 3DS’s native security arrangement. The ARM9 side runs Kernel9 and Process9, a privileged system process responsible for tasks including storage, cryptographic operations, game-card communication and the verification of software titles.
A useful analogy is an office with a public workroom and a locked records department. Code running as an ordinary application can perform impressive work inside the workroom: it can draw graphics, read permitted files and execute its own logic. It cannot automatically open the records department. On the 3DS, ARM11 userland—the term for application-level execution—was the workroom. ARM11 kernel execution meant authority over the kernel supervising those applications. ARM9 kernel and Process9 execution reached a more security-sensitive part of the machinery, but it was not identical to boot-ROM control or to every later stage of FIRM execution.
Nintendo’s firmware was divided accordingly. The FIRM package contained an ARM11 section and an ARM9 section, with the latter carrying the low-level kernel and Process9 components. That arrangement explains why an exploit that launched a homebrew game did not necessarily permit the console to accept an unauthorized commercial title. It also explains why early public demonstrations could seem revolutionary while remaining technically limited: code execution had been achieved, but not necessarily at the layer where signatures and protected storage were governed.
The original 3DS family is commonly documented by reverse engineers as using an ARM11 MPCore running at roughly 268 MHz. The New Nintendo 3DS family used a quad-core ARM11 configuration, adding two cores to the original dual-core arrangement, along with more memory and a larger cache. Supported software could use a substantially higher performance mode, commonly cited at about 804 MHz. Nintendo’s announcement emphasized the visible results—faster software, a C-Stick, ZL and ZR buttons, improved face-tracking 3D and built-in NFC—rather than publishing a full processor specification. The detailed figures therefore belong to technical documentation, not to Nintendo’s consumer description.
That distinction mattered to exploit authors. A payload is a small program or piece of data delivered by an exploit; it performs the next stage after the initial vulnerability has been triggered. Payloads depend on memory addresses, system calls and hardware behavior. A payload prepared for an original 3DS could not simply be assumed to work on a New Nintendo 3DS. The two families shared a name and much of their software library, but they did not present identical targets.
Before the Public Homebrew Era
The earliest experiments are difficult to narrate with absolute “firsts.” Private demonstrations, incomplete proof-of-concepts and discoveries never published in a form that survives today may have preceded the best-known releases. The record is much firmer once projects began publishing their own software, documentation and contributor credits. That is why Gateway is best described as the first widely documented and commercially consequential 3DS flashcart platform, not automatically the first device of its kind ever made.
Gateway was publicly promoted in late May 2013 and marketed or distributed by June, according to surviving company material and a later U.S. federal indictment describing the government’s characterization of its commercial circumvention role. The product resembled a 3DS game card but used a microSD card to hold software. Its operation was not simply a matter of an unmodified console accepting an ordinary retail card: Gateway combined aftermarket cartridge hardware with an exploit entry point, a proprietary launcher and a custom software environment that attempted to provide game-card emulation and related functions.
The surviving Gateway documentation described support for older system versions, region-free behavior, firmware spoofing and, later, multiple game images. Those were company claims, and mirrored pages do not always preserve a clean publication history, so individual launch dates and feature rollouts should not be treated as perfectly established. What is secure is the product’s place in the chronology: a commercial system arrived before the first widely publicized general-purpose public homebrew route, and it demonstrated that the 3DS’s defenses could be studied and packaged for customers.
Gateway’s two-card arrangement illustrated the layered nature of the attack. Its red card was intended for 3DS-mode software; a blue DS-mode card helped establish the initial software condition through the older DS compatibility environment. Later reverse-engineering reconstructions describe the blue card as being used to alter or exploit the DS Profile/DS-mode state before the 3DS Settings application triggered the Gateway payload; Gateway’s own documentation did not provide an equally transparent technical account. These reconstructions are later community analyses rather than Gateway’s own explanation, and the exact exploit chain changed over time.
The commercial model also exposed a weakness in the flashcart idea itself. The cartridge was the visible product, but the launcher file was its essential software. Because that file could be copied, modified and examined, the system became vulnerable to clones and unofficial alterations. In early 2014, reports appeared of consoles that would no longer boot after users employed modified or clone-related Gateway software. Gateway attributed the failures to corruption caused by flawed copying or modification and warned against unofficial launchers. Later community analyses alleged that affected Gateway launcher software contained a destructive anti-clone or anti-modification path.
The controversy became known by the nickname “Brickway,” but the surviving record does not establish that every reported failure had one cause. Some incidents involved modified launchers, clones or incomplete data; Gateway rejected the broader accusation. The careful historical point is narrower: later community analyses alleged that affected Gateway software contained a destructive path, while Gateway attributed the failures to corrupted or modified launcher files. The surviving record does not establish the mechanism or scope of every reported failure. A flashcart was not merely imitating a game card. It was combining an aftermarket accessory, an exploit package, a custom software environment and a commercial trust model of its own.
The Second System on the SD Card
Gateway’s most influential technical idea was emuNAND, short for emulated NAND. The name can mislead. This was not emulation in the usual sense of pretending to be a different console. NAND referred to the internal flash storage containing the system software; emuNAND redirected many operations to a copy of that system image stored on the SD card.
The practical problem was straightforward. Updating the internal system could remove the vulnerability needed to start Gateway. Yet newer software features often required newer firmware. The solution was to preserve an older, exploitable internal environment while running a second system image from the SD card. The internal copy became commonly known as SysNAND, while the redirected copy was called emuNAND or, in related earlier terminology, redNAND.
Later technical histories credit smealum with an earlier redNAND demonstration, while Gateway later commercialized and popularized a related SD-resident system-image approach. The surviving Gateway material securely documents Gateway’s own implementation and marketing, but does not settle the complete origin story. Because the terminology and implementation lineage overlap, it is safer to describe Gateway as a prominent commercializer of the concept than to assign sole invention to either project.
EmuNAND changed the perceived economics of experimentation. An owner could regard the internal system as a relatively fixed base and the SD-based environment as a more changeable layer. That boundary was never a guarantee against mistakes, and the two environments were not as independent as a modern computer’s separate virtual machines. Nevertheless, the idea became a bridge between the commercial flashcart period and later custom-firmware practice. It taught users and developers to think of the 3DS not as one indivisible firmware image, but as a collection of storage areas, boot stages and privileges that could be redirected or patched separately.
Cubic Ninja Opens the Door
The public homebrew story changed on November 20, 2014, when smealum released ninjhax, a userland exploit built around AQ Interactive’s Cubic Ninja. The game included level-sharing and QR-code features. Ninjhax used that ordinary game functionality as the visible trigger, but the important achievement was broader: a retail title became a repeatable doorway into a general-purpose homebrew launcher.
Jordan “smealum” Rabet was the public face and principal author of the project, but the project’s own credits identify a wider group, including yellows8, plutoo and contributors involved in exploit research, auditing, testing, the Homebrew Launcher and the supporting ctrulib software. The credits matter because exploit histories often compress collaborative engineering into a single heroic discovery. The surviving documentation supports recognition of the named team; it does not establish a single “first 3DS hacker” behind every earlier experiment.
Ninjhax arrived shortly after Nintendo’s New Nintendo 3DS launched in Japan on October 11, 2014. Nintendo had announced the new models on August 29 and said that no North American or European release would occur during 2014. The timing produced two related but distinct targets: the original hardware already widespread in other regions, and a newer machine whose processor arrangement and system software required separate attention. The initial ninjhax documentation supported firmware versions in the 4.0 through 9.2 range, while later versions of the project developed different payloads and broader support.
Its first boundary was as important as its breakthrough. Ninjhax provided userland execution. It could launch unsigned homebrew applications, including games, utilities and emulators, but it did not by itself provide the deeper authority required to run unauthorized commercial copies. That limitation separated the Homebrew Launcher from Gateway’s commercial game-card emulation. The same console could host both kinds of work, yet they were not technically or historically the same achievement.
The project’s 3DSX executable format reflected that uncertainty. Rather than treating an exploit as a one-off trick tied to one fixed memory arrangement, the Homebrew Launcher used a relocatable format whose code, read-only data and writable data could be placed independently in memory. In plain terms, the program could be loaded into different available spaces instead of assuming that every system would arrange memory identically. This was an engineering response to a moving target: new entry points, hardware revisions and firmware updates could change the conditions under which homebrew ran.
Cubic Ninja consequently became known as an unusually valuable exploit host, but exact price peaks and sales figures remain poorly supported without contemporary retailer or marketplace records. The secure historical claim is that demand and scarcity increased sharply after ninjhax became public. The more important change was cultural. Modification no longer required buying a specialized commercial ecosystem. A normal game, a published exploit and a launcher created a public route for experimentation, development and preservation—though still within the narrow permissions granted by userland.
From a Game to the Browser
The next step was to remove the special-cartridge requirement. Browserhax moved the entry point into the 3DS web browser, whose WebKit engine contained vulnerabilities that varied by firmware, model and region. Project documentation records separate exploit families for original and New Nintendo 3DS hardware, as well as firmware ranges in which particular flaws were fixed. The browser could therefore serve as a doorway to ARM11 code execution, but it did not automatically promote that code to kernel or ARM9 authority.
That distinction made browserhax both accessible and fragile. Its advantage was that many owners already possessed the required application. Its weakness was dependence on an exact browser build and on Nintendo’s ability to close the underlying flaw through a system update. The history had begun moving from a proprietary commercial launcher toward public software exploits, but every new convenience also exposed the community to a narrower set of version-specific conditions.
Tubehax and the Network as a Temporary Door
Tubehax extended the same idea through Nintendo’s YouTube application. Its significance lay less in the application’s purpose than in its distribution. Many 3DS owners had access to YouTube without owning Cubic Ninja, and the exploit could be reached through a network request redirected by a specially configured DNS service. The Homebrew Launcher documentation describes it as a temporary entry point rather than a permanent modification: alter the network arrangement, and the route disappeared.
That impermanence distinguished tubehax from both a cartridge accessory and a firmware installation. No physical alteration was made to the console, and the exploit did not survive independently of the application and the network behavior that delivered it. The DNS service also blocked Nintendo’s update and eShop servers while active, a practical consequence that made the method more than a clever remote trigger. It became part of a cautious contest over which server a console was permitted to reach and which software version it was allowed to retain.
The YouTube application used WebKit components, but tubehax should not be described simply as an exploit in the ordinary 3DS browser. It was an exploit in the YouTube application’s own software environment, reached through the application’s network behavior. 3dbrew’s technical documentation records that a YouTube update released on October 15, 2015 fixed the vulnerability used by tubehax. That date is more informative than the loose claim that Nintendo “quickly patched” the exploit: it shows how a public entry point could have a clearly bounded life without ever becoming a permanent console feature.
Gateway’s earlier research was relevant to the story, but attribution requires care. The Homebrew Launcher credits Gateway with drawing attention to the WebKit bug class involved in tubehax. That does not make Gateway the author of tubehax. The public implementation, launcher integration and homebrew-facing release were credited to the homebrew developers, including smealum and collaborators. A commercial circumvention project and a public homebrew project could study related weaknesses while pursuing different goals. The former sought a proprietary product environment; the latter emphasized general unsigned software.
What the Homebrew Launcher Made Possible
The Homebrew Launcher gave the 3DS scene a common stage. Before it, an exploit could be impressive but isolated: a demonstration tied to one game, one payload or one developer’s private toolchain. A launcher turned that achievement into an application environment. Developers could write programs intended for ordinary users rather than asking every project to carry its own exploit logic. The result was a widening catalogue of small games, emulators, media experiments, file tools and development tests.
The 3DSX format helped make that catalogue practical. Its relocatable sections allowed program code, read-only data and writable data to be placed independently in memory. That design was not a minor packaging preference. Entry points differed in how much memory they left available, where they placed the launcher and which system processes were present. A format tied to fixed addresses would have made each new exploit or firmware revision an invitation to rebuild the entire application ecosystem. Relocation made the launcher a layer between unstable exploit conditions and comparatively stable homebrew software.
The technical culture around the launcher also encouraged a more honest description of what “unsigned code” meant. Nintendo’s software-signing system was designed to determine which titles and system components the console should trust. The Homebrew Launcher did not simply switch that system off. It created a process in which code had been placed into memory and executed under the authority granted to the exploited application. That was sufficient for legitimate independent software, but it did not automatically turn every commercial title into an acceptable application. The distinction was sometimes obscured in popular discussion because “running homebrew” and “breaking the security” sounded like the same accomplishment. They were not.
This mattered especially for emulation. A 3DS program that emulated an older system was an unofficial application running on the 3DS; it was not the same as a flashcart presenting unauthorized software as a retail game card, and neither was equivalent to Nintendo’s own authorized Virtual Console products. Homebrew developers could study older hardware, create original software and preserve technical knowledge without those activities requiring a copied commercial library. The platform’s openness therefore expanded the legitimate uses of modification even while commercial circumvention remained part of the surrounding history.
Menuhax and the Home Screen as an Entry Point
Menuhax, released on September 25, 2015 according to yellows8’s project archive, moved the trigger closer to the console’s everyday starting point. It exploited the Home Menu’s handling of theme-related data. Instead of opening a particular game or application, the user reached the Home Menu and allowed the altered condition to trigger during startup. The Home Menu was not merely a decorative shell: it was a system application with its own data formats, memory behavior and version history. Theme support introduced the vulnerability that made this route possible on the relevant firmware families.
The change was practical as much as technical. A game-based exploit required access to the right title. Browserhax required the right browser and usually a network route. Tubehax depended on a particular YouTube build and DNS behavior. Menuhax made the console’s own front door part of the launch sequence. That reduced friction and made homebrew feel less like a special demonstration and more like an alternative operating habit, even though the underlying execution still began in a restricted environment.
Its persistence also needed precise language. Menuhax could arrange for the Home Menu to load a payload automatically, but it was not a boot-ROM exploit and did not mean that the console had acquired permanent low-level control. The project documentation described failures as Home Menu crashes or boot loops rather than necessarily irreparable hardware damage. Removing the SD card or changing the relevant Home Menu data could restore normal startup in the documented failure cases. This distinction was important in a period when “brick” was used casually for everything from an inconvenient crash to a console that genuinely could not reach its normal boot process.
Menuhax’s support was correspondingly conditional. Theme formats, regional builds, system versions and Old3DS/New3DS differences affected its behavior. Nintendo released a rapid sequence of system updates during this period, including versions 9.0, 9.2, 9.3, 9.4 and 9.5. Project releases separately documented how changing Home Menu versions, theme formats and payload conditions affected compatibility; the article should not imply that every listed update directly targeted menuhax. The scene’s apparent progress was therefore not linear. Each public method simplified one part of access while creating another set of compatibility boundaries.
A Moving Contest Between Updates and Entry Points
Nintendo’s update process gave this period its rhythm. An update could add a consumer feature, repair a security flaw or alter memory and system-service behavior in ways that broke an existing payload without directly targeting the homebrew community. The community, in turn, mapped those changes and separated working configurations by model and firmware. The result was a peculiar form of software archaeology: a version number was not just a date marker but a description of which doors remained open.
That did not make every update a deliberate response to a named exploit. Public documentation can establish that a vulnerability was fixed in a particular application or system version; it cannot always establish Nintendo’s internal motivation for every adjacent change. The responsible historical claim is therefore specific. 3dbrew’s technical documentation records that a YouTube update released on October 15, 2015 fixed the tubehax vulnerability. Browser and Home Menu changes affected other entry points across their own release histories, but each causal claim should be tied to the relevant project documentation rather than inferred from a list of version numbers.
The company’s public hardware and software position also contained several different categories that should not be merged. Nintendo sold authorized peripherals, games and network applications through its normal channels. Aftermarket flashcarts imitated or repurposed cartridge interfaces without being Nintendo products. Homebrew developers published unsigned software for independent use. Commercial circumvention systems pursued capabilities that could include game-card emulation and signature-check bypasses. The fact that all four categories touched the same console did not make them legally or technically equivalent.
The legal record is clearest when describing Gateway’s commercial role rather than trying to turn every community argument into a court finding. A later U.S. federal indictment characterized Gateway, in the government’s allegations, as a circumvention device marketed and distributed from around 2013 and described its alleged relationship to Nintendo’s security measures. The indictment records the government’s characterization in a criminal case; it is not an independent audit of Gateway’s technical operation or proof of every alleged commercial use. The brick controversy likewise remains a matter of competing explanations and reverse-engineering attribution, not a judicially established account of every affected console.
For developers, the practical consequence was that homebrew became a discipline rather than a single exploit trick. Teams had to maintain payload variants, account for different processor arrangements, document supported firmware, test memory assumptions and provide a launcher that ordinary users could understand. Project credits reveal that work was distributed among exploit researchers, auditors, testers, library authors and application developers. Smealum’s public role in ninjhax and the Homebrew Launcher was substantial, while yellows8’s browserhax and menuhax work illustrates how the field depended on specialists who attacked different layers of the software stack. Plutoo and other contributors likewise appear in the documented credits rather than in an invented hierarchy of “first” discoverers.
By late 2015, the important historical shift was not that every 3DS had become equally open. It was that access had moved through several recognizable stages: a commercial cartridge environment, a game-hosted public exploit, browser and application entry points, and finally an automated Home Menu trigger. Each stage taught developers more about the boundary between ARM11 userland, ARM11 kernel execution, ARM9 kernel and Process9 privileges, and the still earlier boot-ROM trust decisions. The next generation of work would depend on crossing those boundaries, but the middle-era homebrew scene had already established the software practices, shared tools and technical vocabulary that made such research possible.
The Boot Chain Becomes the Platform
The early entry points established what the 3DS could do; the modern scene changed where unofficial code entered the machine. The decisive shift was from launching a payload inside Nintendo’s operating system to arranging for one to run during the boot process itself. That distinction made later tools more dependable, less tied to a particular game or application, and better suited to preservation than the older version-specific methods.
arm9loaderhax was the important transitional step. It exploited a weakness in Nintendo’s ARM9 loader and allowed custom code to run after part of the low-level boot process had already taken place. That was substantially earlier than ordinary application execution, but it remained dependent on the conditions surrounding that loader and on installation-era procedures that were awkward to reproduce across the entire 3DS family. It is therefore misleading to use “arm9loaderhax” as a synonym for all modern custom firmware. It was an exploit and an execution point, not the name of the complete environment users ultimately interacted with.
The later sighax discovery reached an earlier trust decision. Nintendo’s boot ROM checked whether a FIRM image carried an acceptable signature before allowing it to execute. Sighax was the boot-ROM signature-verification vulnerability: it exploited a flaw in that check so that modified firmware data could be accepted at an earlier stage than arm9loaderhax. Sighax was not itself a complete bootloader or custom-firmware environment. Its importance was the early execution position it made possible.
boot9strap turned that research result into a usable foundation. Its central job is narrow but powerful: it loads a file named boot.firm from the SD card or from CTRNAND during startup. That arrangement separated the durable bootloader from the software environment it launched. Luma3DS could be updated as a payload rather than requiring users to repeat the original exploit process, while recovery utilities and other boot-time software could occupy the same general framework. Sighax was the vulnerability, boot9strap the bootloader implementation, and Luma3DS the custom firmware environment. Treating those names as interchangeable erases the engineering progression that made the modern scene practical.
Luma3DS Makes Modification Ordinary
Luma3DS became the public face of this new phase because it retained broad compatibility with Nintendo’s software while patching or extending selected parts of the system. It is not normally an entirely separate operating system. Instead, it operates as a boot-launched firmware environment that modifies the behavior of Nintendo’s own software stack. That architecture explains why a user can encounter custom features while still launching ordinary installed titles, using the Home Menu and retaining much of the console’s familiar behavior.
Its modern feature set is less dramatic than the original exploit breakthroughs, but more consequential in daily use. Luma supports game and system-module patches, LayeredFS path redirection, locale overrides, payload chainloading and development features such as a GDB stub. LayeredFS, in particular, redirects selected files without replacing an entire title. Used legitimately, that can support translation projects, accessibility adjustments, debugging and fan-made enhancements. The same mechanism can also be used in ways that raise copyright concerns, so the technology should not be presented as inherently benign or inherently illicit. Its purpose depends on the material and project involved.
Rosalina illustrates how the scene matured from “can code run?” to “what can developers and players do with that code?” Integrated into Luma3DS, Rosalina provides an overlay and system-module feature set rather than serving as a separate exploit or operating system. It includes tools for screenshots, screen filters, input redirection, process control, cheat support, network time setting and developer-oriented diagnostics. The documented shortcut, L + Down + Select, is less historically important than the design philosophy behind it: unofficial code had become part of the console’s ordinary interaction model.
The 3DS therefore acquired a kind of software accessibility layer. A researcher could capture screens without external equipment, a developer could inspect a running process, and a player could adjust controls or display behavior without opening the hardware. Those uses sit beside more controversial capabilities, but they should not be reduced to them. Rosalina’s existence demonstrates that custom firmware became infrastructure for experimentation, preservation and accessibility, not merely a mechanism for bypassing title checks.
Version numbers require care in this period. Nintendo’s official North American system version remains 11.17.0-50U in the September 15, 2026 research snapshot, with Japan identified separately as 11.17.0-50J. Luma3DS has its own release cycle; the snapshot records version 13.4 on April 2, 2026. Neither number is a substitute for the other. A console can be on Nintendo’s final widely documented firmware while still receiving changes to its custom firmware environment.
ntrboot and the Recovery Cartridge
ntrboot added a hardware-assisted route that belonged to a different part of the 3DS story. A compatible DS-family flashcart could be prepared to participate in a boot-ROM recovery context before the ordinary operating system had fully started. This was not the same as a regular DS or 3DS game cartridge. Retail software entered through Nintendo’s normal cartridge and operating-system handling; an ntrboot-capable device was repurposed to trigger an earlier recovery sequence.
That distinction made ntrboot valuable even after boot9strap had become established. It could provide a route into systems that no longer had a convenient software entry point, and it became associated with recovery from certain software failures. The method’s requirements varied by cartridge model and firmware. Historically, many compatible devices also relied on a magnet to induce sleep mode while the recovery sequence was triggered; the original 2DS’s mechanical sleep switch made its physical behavior different. These details explain why ntrboot was a class of method rather than one universally compatible product.
Compatibility should not be frozen into a timeless shopping list. Flashcart firmware, availability and supported models have changed, and modern guides distinguish hardware families before selecting a route. The important historical development is that the community moved from hunting for a vulnerable retail application toward maintaining several kinds of access: ordinary software methods where available, ntrboot where hardware assistance was appropriate, and specialist repair methods for cases outside normal guidance. That is a more useful account than naming a supposedly permanent “best” cartridge.
A Preservation Toolkit Takes Shape
Once boot-time access was dependable, the most valuable projects were not necessarily the ones that made the loudest security claims. GodMode9 became a central preservation and maintenance environment because it can inspect and manage the 3DS’s different storage areas, including the SD card, internal system storage, FIRM data, emuNAND remnants and cartridge-related data. It is a full-access utility, not a conventional file browser, and its warnings about backups and write operations reflect that power.
For historians and owners, the important capability is inspection. GodMode9 can help create personal backups, examine file systems, work with save data and document how Nintendo’s software is arranged on aging hardware. It supports recovery and development work as well as archival study. A personally made backup of a cartridge or save is conceptually different from downloading or distributing someone else’s copyrighted game image, and the existence of a powerful dumping utility does not erase that distinction. The preservation value lies in giving owners and researchers control over data they already possess, not in supplying a library of commercial software.
The project’s release number is independent of both Nintendo’s firmware and Luma3DS. The September 15, 2026 snapshot records GodMode9 version 2.2.3, released March 31, 2026, as the current observed release. Such date-stamped wording matters because active homebrew projects can change after an article’s research cutoff, while Nintendo’s system software may remain unchanged. A reader who confuses those version families can easily mistake a utility update for a system update or assume that an old payload reflects the present state of the platform.
Checkpoint addresses a more personal form of preservation: the continuity of saved progress. It supports save management for 3DS cartridges and digital titles, extdata, DS cartridges, DSiWare and GBA Virtual Console titles. Backups can preserve years of play when a cartridge’s flash memory becomes unreliable, when a system is being replaced, or when a digital storefront’s future is uncertain. It also gives researchers a practical way to study save formats and build accessibility or translation projects without treating the game itself as disposable.
Checkpoint is not an exploit. It is a save-management framework that runs within the established homebrew environment. That distinction matters because its value survives independently of the original race to find a vulnerability. The project’s current maintained repository is associated with Bernardo Giordano, and the snapshot records version 5.2.0 on August 26, 2026. Earlier references to older releases or to the project’s previous repository history should be understood as stages in its development, not as evidence that every old guide remains suitable for current systems.
After Nintendo’s Network Era
The end of Nintendo’s commercial network services gave these tools a new historical setting, but it did not happen all at once. Purchases and free-content acquisition through the 3DS eShop ended on March 27, 2023. Nintendo later ended online play and most other functions requiring online communication on April 8, 2024. The company separately stated that previously purchased software and downloadable content could continue to be redownloaded for the foreseeable future, and that software updates remained available. Nintendo initially left Pokémon Bank and Pokémon Transporter available as exceptions after April 8, 2024, but later announced that Pokémon Bank service will end on February 25, 2027.
That chronology matters because “the eShop closed” and “3DS online shut down” describe different events. Local StreetPass communication was not identical to internet-dependent SpotPass. Redownloads were not the same as new purchases. Updates were not the same as online multiplayer. For preservation, these distinctions determine whether a console is merely disconnected from a service, unable to acquire new content, or still capable of retrieving software it previously obtained through Nintendo’s infrastructure.
Pretendo emerged in this environment as an open-source Nintendo Network replacement project for Wii U and 3DS. It is not a boot exploit, an authorized Nintendo peripheral or a generic internet proxy. Its console-side components rely on a homebrewed system running current Luma3DS, while its servers attempt to reproduce selected network functions. The project’s usefulness therefore depends on both local patches and the state of individual services.
Pretendo also demonstrates why compatibility claims must remain specific. Support can vary by game, account behavior, server feature and date. A replacement service may restore a particular online function without reproducing every Nintendo service, and a project status page can change independently of the console’s firmware. The historically sound claim is that Pretendo represents an organized effort to preserve selected network experiences after Nintendo’s shutdown, not that it universally restores the 3DS online era.
This is where modification becomes especially relevant to preservation. A save manager protects personal progress; a system utility documents data structures; a network replacement keeps selected social or competitive functions alive. None recreates the original commercial ecosystem perfectly. Preservation is often a negotiation with missing servers, aging flash storage, proprietary formats and incomplete documentation. The modified console becomes a research instrument as much as a player’s machine.
What the Modern 3DS Actually Preserved
The modern 3DS scene is sometimes described as a finished exploit race because Nintendo released no major system update after 11.17. That description misses the continuing work. Luma3DS, GodMode9, Checkpoint, Pretendo and the maintained guide have separate release cycles and separate responsibilities. A guide can change its recommended entry point without Nintendo changing the system version; a network project can alter its compatibility without a new bootloader; a save manager can improve while the console itself remains officially frozen.
Compatibility is consequently a matter of layers. Original and New 3DS systems differ in processor resources and software behavior. The 2DS changes physical sleep behavior. Regional system suffixes matter. A method suitable for one firmware and model cannot automatically be generalized to another, and a utility that reads one kind of data does not necessarily understand every title format. Modern documentation’s emphasis on identifying the model, region and version before selecting a method is not bureaucratic fussiness. It reflects the architecture inherited from the earlier exploit era.
The preservation tradeoff is equally layered. Greater access makes it possible to back up saves, inspect storage, run original homebrew and maintain replacement services. It also increases the consequences of careless changes to system data, and it can place unofficial software alongside copyrighted material or network services that are not authorized by Nintendo. The responsible historical account does not pretend those tensions disappeared when boot9strap simplified the technology. It shows instead how the same technical openness can support a translator, a restoration project, a disabled player seeking input remapping, a researcher documenting a file format or a person using unauthorized copies.
What changed most was the meaning of modification. In the early period, success meant getting past one locked door: a game, browser, application or Home Menu. In the modern period, the 3DS became a stack of maintainable layers. boot9strap provided a durable launch point; Luma3DS supplied compatibility and system extensions; Rosalina made those extensions usable; GodMode9 exposed the machine’s storage; Checkpoint protected personal history; and projects such as Pretendo addressed the disappearance of network infrastructure. They did not turn the 3DS into a generic computer, nor did they restore every lost commercial service. They made its boundaries visible and, in carefully chosen places, negotiable.
That is the lasting significance of the 3DS modification history. Its most important legacy is not a single exploit or a particular flashcart, but a body of technical and cultural work that keeps a closed handheld interpretable after its manufacturer has moved on. The console remains Nintendo hardware, with Nintendo’s software and its original constraints. Yet the modern tools give owners ways to study, preserve and adapt that hardware without confusing independent homebrew with authorized products, emulation with cartridge copying, or restoration with a promise that the past can be perfectly reconstructed.
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.
