To be honest, there isn’t much interesting things going on with the cart; the feature set is largely identical to the generic flashcarts, the closest to identical being the Ace3DS X. Aside from having built-in ntrboot functionality (the Ace3DS X requires flipping a hardware switch), it doesn’t have any special gaming functionality such as save states. The price isn’t all that ideal either; current distributor prices range somewhere near 25 USD as of this writing, which is kind of unfortunate as the Ace3DS X can be purchased for as low as 10 bucks on Aliexpress.

All things considered, it’s sort of a baseline flashcart, and there is nothing wrong with that.

The real problem is with its software stack, and it’s not because of the quality.

It’s always GPL

What is it with Chinese brands and failing to follow the simple logic behind the GNU General Public License? All that had to be done was to upload the source code somewhere, and nothing more than that. Creality’s printers have come under fire, Allwinner fails to provide Linux kernel sources, and, well, for the DS hacking scene, the Wood kernel’s license was violated multiple times as stated by the author, to the point they closed access to the source code from 1.26 onwards.

Unfortunately for EZ-Flash, the Parallel is no exception.

First, it also uses the Wood kernel source base. This was, in fact, explicitly advertised this way. The only way this would work is that EZ-Flash is building on top of the last open source version of Wood, which is 1.25 (there’s an archive of it here.) There’s nothing wrong with this, since version 1.25 was openly released with GPL-3.0-or-later.

The problem is that, after two months, EZ-Flash’s modifications are nowhere to be found. It’s not on their GitHub, nor is it on their website. EZ-Flash has since released 3 versions of their kernel with various minor fixes. If they did upload it somewhere, where? And not just some “UI only” or “IO routines” minimal release; the entire kernel source is GPL, including the akloader ROM loading module, akmenu4 menu, and every other library needed to compile both of these, as the GPL requires the full source to be released along with all the assets needed to compile it (none of those are released either…)

When asked about it by someone in EZ-Flash’s Chinese community chat, we were met with the response that the kernel wasn’t something they planned on releasing:

Of course, it is possible that EZ-Flash has somehow gotten ahold of the private source code for the last Wood version, 1.62. And maybe they asked Yellow Wood Goblin, the original author, for express permission on the matter. This is unlikely to be the case, as, if this were true, EZ-Flash’s changelogs (only provided in Chinese on their Chinese file sharing platform) would not show bug fixes for games that were fixed in original Wood ages ago, or users in Chinese forums such as oldmantvg complaining about such games not running where it should be on 1.62. Ruling this out.

I, of course, am annoyed about this, and you, the reader, should be annoyed too. If you are in possession of this cart, consider contacting EZ-Flash about this abusive behaviour.

On the other hand, it was less of a shock to me. This wouldn’t be the first time that Wood’s GPLv3 has been violated. Dozens of carts, notably the R4iTT 3DS and many of its direct descendants of other brands are also violating GPL (but the teams behind them are long gone), as well as the Ace3DS+ and X, all very common carts you may be able to find out there.

But wait, there’s more!

Homebrew Menu

In the homebrew scene, there is usually a compiler, and a code library usually written in the C language that has functions for interacting with the hardware. devkitPro and BlocksDS are two toolchains that allow building your own code to run on the Nintendo DS hardware.

Typically, when devkitPro supports a device, they also provide a reference menu application that serves as the de-facto application to load your custom code in all its glory. On the DS, this is the NDS Homebrew Menu.

For the DS, devkitPro also ships “bootstrap” binaries that allow replacing a flashcart’s (typically closed source) kernel with a flashcart-specific file that will launch the Homebrew Menu with full storage device access. This bootstrap, along with the bootloader module, is also code I use regularly in flashcard-bootstrap, which is my personal playground to expand the list of supported carts, often with some crazy hax. I would have upstreamed all of this, but I’m banned from devkitPro’s GitHub, so there’s that.

So what does EZ-Flash have to do with all this?

An owner of the Parallel in the DS⁽ⁱ⁾ Mode Hacking Discord server privately provided me a dump of the Parallel’s firmware, extracted using GodMode9. This dump would serve to show what is on the cartridge’s flash, which is what the console will run and boot into your usual kernel. I requested this dump primarily to see what may be needed to add support for the Parallel in flashcard-bootstrap (as I do not have the cart yet; it’s coming soon, though), but as I was digging through their binary for specific quirks that may exist, I found, well, this snippet of code:

The keen eye among you may already be cross-referencing with devkitPro’s Homebrew Menu, and will find that this is pretty much identical to the main() function found here!

Another snippet, this time runNdsFile() from nds_loader_arm9.c:

The snippets are kind of ugly; I blame Ghidra as it doesn’t handle legacy ARM binaries too well. However, it is enough to get an idea of just how similar everything is. Nearly all of the BootStrap output is here; nds_loader_arm9.c is unmodified, and the bootloader module appeared to be identical save for the fact that it seemed to lack DSi-specific code, implying it was built with the -DNO_SDMMC flag.

It should be noted that all code provided in Homebrew Menu is licensed GPL-2.0-or-later.

I didn’t bother to take apart any of the other code in the firmware after that. If you have an EZ-Flash Parallel, feel free to do the forensics work yourself too; the above snippets were based on whatever firmware was shipped in the last 3 months, if it ever gets updated at all.

Decent cart otherwise; morally, not a good buy

The EZ-Flash Parallel was a hype for all of us that saw the initial leaks in September in the Discord, and pre-release information in EZ-Flash’s Chinese group chat in early January that was cross-posted to GBAtemp. I was especially interested in it, since, as the administrator of flashcarts.net, this cart felt like a good, solid option to recommend to new users. It’s currently supported by the team behind it, compared to the flashcart red ocean on Aliexpress at the time of writing.

The pricing, unfortunately, isn’t ideal; had it been sold for 99 CNY, which is the China domestic pricing at the time of writing, I would have pushed users to this cartridge instead of the Ace3DS X, even if it was slightly more on the expensive side, just because EZ-Flash has usually delivered good products. Call it brand loyalty. But with a feature set that doesn’t surpass the Ace3DS X, and for double the price, I’m not sure if it’s worth it.

Even with pricing aside, with not one, but two GPL violations, is it right to support them? The DS flashcart scene is already tainted with so many redistribution licenses violated (YSMenu’s distribution clause, Wood’s GPLv3), do we need another one to add to that list, in 2024?

The funny thing is, EZ-Flash typically had a history of open-sourcing what should be. EZ-Flash V and Vi used Moonshell code, which was GPL and released by EZ-Flash (though some are lost to the Internet; can’t blame EZ-Flash for that). Understandably the ROM loading portion wasn’t open source then, but it was external to Moonshell and did not really apply. But with Wood, the entire kernel, menu and loader, was (and is for 1.25) all GPL, so this is quite a disappointment.

Perhaps these issues may be rectified by EZ-Flash some time in the future, but as it is right now, pricing-wise and licensing-wise, I cannot recommend it to users looking to buy a new flashcart. In general, they aren’t needed; you can install custom firmware on your 3DS or DSi. Should you still be looking for options, however, myself and the flashcarts.net contributors has a quick start guide for you.

flashcard-bootstrap: what is it?

A major portion of my research, development and documentation has been a tool called flashcard-bootstrap.

What does it do? Simple, it is designed to replace these flash cartridges’ typically proprietary menu. It will load a /boot.nds on the SD card and install the necessary cartridge drivers (known as DLDI, dynamically linked device interface), allowing the end user to comfortably load any homebrew application of their choice.

The current state of things

Of course, simply compiling flashcard-bootstrap and bundling the driver is not enough. Many flashcarts are designed differently, and have a few “limitations”, so to speak. These limitations, in a non-exhaustive list, range from:

• Poor implementation of the bootloader stored in the cartridge flash.
  • For easier software updates, often the cartridge flash contains just enough to load the menu from the SD card, which has different file names depending on the cartridge. (hereon “boot file”)
  • A proper implementation would check the target application’s header, to see where the executable binaries are to be loaded in memory.
  • Some implementations, unfortunately, hardcode these addresses, leaving it to the developer of the target application to fix it themselves…
• The boot file may be a custom file format.
  • The M3 DS Real, and its descendant “clones”, use the “DSBooter” file format, which differs from a usual NDS ROM format.
  • Some older original R4-based clones would store patches to the original R4’s kernel to add functionality.
• The bootloader may contain integrity checks on the boot file.
  • This may be live integrity checks, encryption, etc.
• A combination of the above…

Freedom of choice

Today, we are leaning towards free-and-open-source solutions more than ever in our community, and these flashcarts are everything but.

For some people, the manufacturer-provided software (hereon “kernel”) is more than enough; it can load their games, homebrew applications, and more or less doesn’t break functionality.

But the idea of free software is the freedom to use, study, share and modify; some users may simply not like how the provided kernel looks and performs, some may have a bias against piracy (which these carts were created specifically for), and some just want a new coat of paint.

Where flashcard-bootstrap falls in this

Enter flashcard-bootstrap. The project was inspired by devkitPro’s NDS Homebrew Menu and TWiLight Menu++, and heavily based on the former’s source code. devkitPro does support a handful of flashcarts via their own research, but that wasn’t enough for me. I wanted to expand on it, document more cartridges, make it accessible for more people who may have, ah, obscure carts.

flashcard-bootstrap loads a homebrew on the SD card named /boot.nds and sets up all the hardware abstractions needed for it to work, allowing users to simply download any homebrew application from the Internet (or making one themselves), renaming it, and Bob’s your uncle.

It provides, to an end user the freedom to use whichever software they want without dealing with a proprietary loader interface, and, to a homebrew developer, a unified experience across as many different cartridges out there, making it “just work” on as much hardware as possible.

Taking Homebrew Menu’s BootStrap code, I decided to tweak a few configurations to adapt to the “limitations” of various flash cartridges as shown in the above list. Many of these were a simple task of adjusting the memory addresses to what the bootloaders expect, and it worked, just like that.

Some were not as simple, however.

Hacky solutions: if it works it works

Example 1: GMP-Z003

Take, for instance, the M3i Zero (GMP-Z003) flashcart.

The boot file is SYSTEM/_M3_MENU.DAT. Unfortunately, it matched no file formats, and was heavily encrypted.

However, upon diff-ing behaviours of every kernel version released by the M3 Adapter team, I found a debug string printed to the screen when there was no other files, which showed… yet another file path?

From there it was a matter of repacking flashcard-bootstrap into the DSBooter file format and utilizing the kernel’s boot file as a Stage 1 launcher, which would launch flashcard-bootstrap, giving me the freedom once again.

Example 2: The bomb that doesn’t really do much, but annoys you to no end

Another example are “timebomb” carts.

These are known for having a date checker in the kernel, and, if the current date was later than the one hardcoded, the kernel would abort.

The boot file, unfortunately, has integrity checks all over the place, but a famed developer from the heyday of DS homebrew, Xenon++, came in clutch with a script to bypass it, which, with some help, I then rewrote it to Python. And off we are to the races again.

This post is just a snippet of the supported flashcarts, in simplified detail. You can always refer to the developer notes to see more in-depth detail on what I have uncovered thus far.

We’re still a long ways from having a fully-free flashcart (or maybe we aren’t?), but my hopes for this project is that it helps someone get started with it.

Stay tuned, I guess?