In July 2018, Nintendo released Nintendo 3DS system software 11.8.0. This dealt a major blow to one method of piracy: direct downloads from the eShop. But how was it possible to pirate games directly from the storefront? Let’s find out!

How an eShop purchase works

Software on the 3DS needs a ticket installed to the console before it can be used. This ticket is typically signed with data tied to the specific unit it’s downloaded on, although there are exceptions for system software and pre-installed titles. When you purchase a title on the eShop (including free applications), the server generates this ticket, the console downloads and install it. This ticket also includes an encryption key (known as the “title key”) needed to decrypt the application contents, which is the same for all consoles.¹

The next step is to download the software itself. This is hosted on a CDN (content delivery network) separate from the eShop servers. This includes the TMD (title metadata), used to find out what files to download, and then the actual application contents. The contents are encrypted using the key in the ticket, and the console decrypts this layer during the download.

Where it went wrong

The biggest mistake here was not requiring any authorization to download game contents. This was not necessarily a catastrophic failure – since the contents are encrypted, if you don’t have the key, the data is effectively garbage.

But someone, I believe in 2016, realized that if you share the keys around, you can decrypt the contents. A common base ticket can be used, and the game’s Title ID and title key can be inserted. This is enough for a modded console to run software, but it turns out, the eShop kinda sorta treats these games as purchased. It doesn’t appear on the account’s re-downloadable software, but when going to the game page, the re-download button appeared.

The discovery of this oversight quickly led to tools to facilitate downloading games for free from the eShop. They would download and install tickets to the console, and then users could go download the games from the eShop. Soon after that, eShop so-called “replacements” appeared to further streamline piracy. The most famous of these applications was freeShop.

What Nintendo changed to block it

Nintendo’s fix to block eShop piracy was relatively simple: the CDN servers required the ticket be sent in the request to download application contents. The ticket has to be signed, so it would have to come directly from the eShop servers. Enforcement did not start immediately, but it was rolled out in the following month.

This completely cut off downloading unpaid eShop software², as tickets cannot be correctly signed by anyone but Nintendo, and due to personalized tickets containing console-unique data (which could lead to a possible ban), nobody wanted to share theirs. Thus freeShop and applications like it were discontinued, and everyone had to return to old-fashioned piracy.

Follow-up

This system of tickets has technically been in place since the Wii days. This means the same piracy could have happened with the Wii Shop Channel, DSi Shop, and even the Wii U eShop. Yet as far as I know, nobody did this until the 3DS. Why?

Well… I don’t actually know why in the case of Wii and DSi. But my speculation is that games from these digital storefronts were really small; the largest a WiiWare game could be was 40MB. It’s a lot easier to share the games themselves around. Meanwhile, 3DS games can be as large as 4GB, providing an incentive to share only title keys while eShop piracy was still possible.

Notes

Updated on January 26, 2025 to clarify pre-installed titles.

1. This is a bit of a simplification. The actual ticket as transmitted over the network has the title key encrypted using a per-console key. But this layer of encryption is removed when it is installed to the console’s ticket database. Most people have never had to deal with this part, and is not exactly relevant to how eShop piracy was enabled. But I’m putting it here for accuracy’s sake. ↩︎
2. There are very limited exceptions. Titles that came pre-installed in special bundles included a ticket that was signed for use on all systems, so these could be shared around and still downloaded from the eShop. ↩︎

I’ve sometimes made the point that I think using custom firmware on the Nintendo 3DS makes the console safer than one without. Since this point might seem confusing to those who deal with hacking/jailbreaking/rooting other consoles or devices, I want to outline why I think this is so.

Back up games, saves, and system storage

This is probably the most obvious one, it provides the ability to back up your games and saves (whether digital or game cards), plus the system storage (a.k.a. NAND). That protects you in cases like lost SD card, accidental deletion, or random corruption. Especially as SD cards are not perfectly reliable.

With a stock console, you’re able to copy the contents of the SD card to another device. This works as a very simple backup, but it comes with some caveats:

• The contents of the saves cannot be accessed. If the console itself is lost, damaged, or formatted, the saves are as good as gone.¹ Even with game cards, some games store “extra data” on the SD card, which is just as tied to the console as digital games. In a few cases such as Fantasy Life, the save isn’t on the game card at all.
• Some games implement anti-restore features, such as Pokémon and Animal Crossing. Trying to restore an old backup will cause these games to refuse to load without either the newest save being loaded, or the save being erased.

Protect your console and saves from bricks

There are a few ways that a console can stop turning on. Software-wise, the most common methods usually involve messing with system files.

But wait, isn’t that something you can only do with homebrew? Yes, that’s something that one couldn’t do without already having custom firmware. However, there are still ways for a console that has never ran any form of homebrew to break itself:

• System save problems: On occasion, a system save might get corrupted or for some other reason break in a way that prevents the console from booting. This happened to mine in early 2015. My then-completely-stock console would no longer boot to the HOME Menu. It would turn on to a black screen, while pressing POWER would show the power off screen. I eventually sent it in for Nintendo repairs. I later found out that this was due to some system save or extra data related to the HOME Menu got some kind of issue, since I saw it come up on other consoles.²
• Hardware failure: Various components of the console can fail at any point, seemingly at random. While some of these are not necessarily catastrophic failures (i.e. camera failure simply blocks camera features in games), some can render a console unusable. RAM failure is perhaps the most devastating, as it is something that requires an entire console replacement (or at least the motherboard), and can hardly be influenced by the user or software.

A console with access to tools like GodMode9 is able to fix software-related problems, while make backups in certain cases of hardware failure. But even when parts like RAM or displays are broken, there are specialized dumping tools like DannyAAM’s 3DS essential file dumper, that works on any modded console that is able to power on in any form. This would enable transferring data to another console.

Now a stock console is not completely without options. ntrboot can be used to boot into custom payloads on any 3DS with a working game card slot. While this is a solution to either fix a software-related brick, or to make backups from one with hardware failures, it requires the purchase of a compatible Nintendo DS flashcart.

There are literally no practical downsides

This is not like jailbreaking or hacking most other consoles – custom firmware on the Nintendo 3DS does not inherently break anything. All games work just as well as before. System updates are safe (though it seems unlikely Nintendo will ever release another one). When these services were fully available, Nintendo eShop and online play were fully functional, no spoofing or workarounds required.

(If it’s not clear enough, you should totally hack your 3DS. There’s a reason that “modding a 3DS is surprisingly easy” is a popular meme, it’s because it’s true.)

Notes

1. Technically, it is possible to recover saves using seedminer, if another 3DS had the console in question added as a friend. But this is not guaranteed – the other console needs to run homebrew, and even then, seedminer does not have a 100% success rate. ↩︎
2. Specifically, the f000000b system extdata. ↩︎

With the recent reveal of the Nintendo Switch 2, I’ve seen many people ask if it can be hacked, and how it will happen. I’ve already posted about this on social media, but I figured I would make this post that I can easily point to.

Please don’t expect there to be easy homebrew for the Nintendo Switch 2. There are several reasons for this.

• The console is not out yet! Until it’s released and in people’s hands, literally everything is pure speculation.
• The current Nintendo Switch has no software-only exploits. The last time there was one that didn’t require hardware modification was the RCM exploit for units produced before June 2018. Since then, a mod chip is required.
• The microkernel of the Switch is small and very secure. To quote SciresM, the lead developer of Atmosphère: “I genuinely believe the microkernel/EL3 secure monitor to have zero security bugs.”

Nintendo did security right with the Nintendo Switch, and this is unlikely to change for the successor. Especially if it’s going to run largely the same software.

May 2025 update

An update to the Nintendo Account EULA has people worried that Nintendo will brick their Switch 2 for modding it. The short answer is no they won’t. The longer answer is in its own post here: Nintendo is not going to brick your Switch just for modding it

June 2025 update

I have made a follow-up post going into more details: More details on why the Nintendo Switch 2 may not be hacked

In early 2024, I tried to resize the partitions on my New 3DS device, specifically to increase the space for TWLNAND, the space that hold DSiWare. I wanted to store more DSiWare than there was available space.

This isn’t a tutorial! This is only my experience trying to do so. You should not attempt this without ntrboot because this can actually brick your console if done improperly.

Also, I only finished this post many months after I had done it, so some of the details are a bit fuzzy, but it wasn’t a difficult process overall. At least the resizing part wasn’t…

What to resize and shift around

What defines the size of TWLNAND, and how can I increase the size of it? The Nintendo 3DS NAND is split up into 5 different partitions, with a custom NCSD header. In order they are:

• TWLNAND
• AGBSAVE (Game Boy Advance VC save data)
• FIRM0
• FIRM1
• CTRNAND

For compatibility reasons with the Nintendo DSi, TWLNAND is the first partition. So when I resize it, I have to shift forward everything else by the same amount.

TWLNAND is itself partitioned into “twln” (holding DSiWare games and data) and “twlp” (camera photos). It starts at the first block of the NAND, meaning it takes up space within the NCSD header. The last 0x42 bytes of the header are dedicated to the TWL MBR. And because “twln” is the first partition within TWLNAND, this also means “twlp” will have to be pushed forward.

Let’s make a custom NCSD header

If I want to increase the size of TWLNAND, I must create a custom NCSD header with my own partitioning. My own pyctr library makes this easy.

I took the partition data from the stock header and adjusted offsets and sizes by a fixed amount. I increased TWLNAND by about 350 MiB. That means I had to shift forward AGBSAVE, FIRM0, FIRM1, and CTRNAND by this amount, and shrink CTRNAND by it. I included here the script I made to create a new NCSD header that resizes TWLNAND and shifts forward every other partition by the same amount.

from pyctr.type.nand import NANDNCSDHeader, NCSDPartitionInfo, SIGHAX_SIGS

diff = 367001600  # 350 MiB

custom_partition_table = {
    0: NCSDPartitionInfo(fs_type=1, encryption_type=1, offset=0, size=185597952 + diff, base_file='twl'),
    1: NCSDPartitionInfo(fs_type=4, encryption_type=2, offset=185597952 + diff, size=196608, base_file='agb'),
    2: NCSDPartitionInfo(fs_type=3, encryption_type=2, offset=185794560 + diff, size=4194304, base_file='firm'),
    3: NCSDPartitionInfo(fs_type=3, encryption_type=2, offset=189988864 + diff, size=4194304, base_file='firm'),
    4: NCSDPartitionInfo(fs_type=1, encryption_type=3, offset=194183168 + diff, size=1106051072 - diff, base_file='ctr_new')
}

a = NANDNCSDHeader(
    # sighax has to be used here as the official signature will be invalidated
    signature=SIGHAX_SIGS['retail'],
    image_size=1342177280,
    actual_image_size=1300234240,
    partition_table=custom_partition_table,
    unknown=b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00',
    # this will be overwritten when twlnand is formatted
    twl_mbr_encrypted=b'\0' * 0x42
)

with open('nand_hdr-custom.bin', 'wb') as f:
    f.write(bytes(a))

Build the new NAND

Once this custom header is written, a NAND image needs to be built. My ninfs tool can mount an image, even one with blank partitions, so I can then format TWLNAND and CTRNAND. For this, one can use standard tools, and on macOS, I used diskutil.

I first attached the raw disk images. Then I used diskutil command to make twln use as much space within TWLNAND as it could, while twlp remained the same as before:¹

diskutil partitionDisk -noEFI disk# 3 MBR \
        free free 76288B \
        'MS-DOS' twln R \
        'MS-DOS' twlp 34301440B

Formatting CTRNAND is simple since it is a single partition.

diskutil partitionDisk -noEFI disk# 1 MBR 'MS-DOS' ctrn R

Now that TWLNAND and CTRNAND are formatted, they can be mounted and all the data from a previous NAND image can be copied like normal. The same applies to AGBSAVE, FIRM0, and FIRM1.

Now that hopefully the NAND image has all the same files as before, I can restore it to my console. There’s a slight catch, in that because partitions are not in the same places, GodMode9’s safe restore cannot be used. An explicitly unsafe restore must be performed by manually injecting the new NAND image into the system.²

An unexpected problem…

The NAND restore was a success! My console booted to the HOME Menu like normal, and GodMode9 could see the new space. “SYSNAND TWLN” is now 493.9 MB instead of the stock 143.6 MB.

There was however one problem, the system software did not recognize the additional space. It still read about 1,000 open blocks.

This was a real problem… How would I use this free space if the system doesn’t think there’s more of it? Oh I know, I’ll dump all my eShop titles to CIA and use FBI to install them!

Installing all my DSiWare manually

I used cleaninty to download all my purchases. Once I had all of them, I stuck them in a folder and let FBI do the rest. Only, it turns out it couldn’t do it either; after a few installed, it started failing. I forgot the exact error code, but the AM service (which actually does the installing) was rejecting it because it also thought TWLNAND was full.

There is actually a third option here, and that is GodMode9. It can also install CIAs, and since it directly interacts with twln, it doesn’t have to deal with AM being upset. But I ran into two issues here.

The first was that CIAs created with cleaninty can only be installed within the 3DS “operating system”. This is because the encrypted title key in the ticket is itself encrypted with a per-console key.³ This leaves GodMode9 unable to decrypt the titles.

Okay, so I decided I’d take the easy but mildly tedious approach of:

1. install as much as I can with FBI
2. dump the installed DSiWare to CIA again with GodMode9
3. delete all the installed titles
4. repeat from step 1 until all software has been processed

There, now I’ve got all my DSiWare ready. So I’ll just install of it, right? No, because the second issue GodMode9 for some reason starts to fail once I’ve installed around 5 titles or so. Thankfully, this one wasn’t that tough to deal with, as the error went away on a reboot. So the loop here was:

1. install 5 titles
2. reboot GodMode9
3. repeat until all software was installed

Finally after all that, I had finally gotten all my DSiWare installed, which was exactly 40 titles and added up to 231.6 MB in CIA files.

Considering that AM didn’t like it when I tried to force through more data than it wanted, I wondered what it would think about me subverting its space enforcement…

I think this counts as a pretty cursed image if you ask me.

This has been my setup since March 1, 2024, and my console has worked pretty well ever since. I just realized while writing this though that having exactly 40 DSiWare from the eShop means that I can’t use it with other homebrew DSiWare like TWiLight Menu++ or GodMode9i. So I might have to figure out some stuff to delete after all…

Notes

1. Something to keep in mind for specifically New 3DS is the secret key sector (sector0x96). twln needs to be put after it so it doesn’t overwrite it. In this command, the free space is 0x95 (76288 // 512) sectors – this doesn’t include the sector containing the MBR, so this means there would be 0x96 sectors until twln starts at sector 0x97, preserving the secret key sector. ↩︎
2. Those who are very paranoid could try out their NAND alterations with EmuNAND. Though this would not be an excuse to restore this to SysNAND without ntrboot as it’s still a big risky change to make to one’s console. ↩︎
3. This is why any “legit CIAs” made by GodMode9 of eShop-downloaded software cannot be installed with FBI or any other 3DS-mode software installer. ↩︎