GodMode9: a full access file browser for the Nintendo 3DS

What GodMode9 is for on a 3DS

The README describes GodMode9 as "a full access file browser for the 3DS console", giving access to the SD card, to the FAT partitions inside SysNAND and EmuNAND, and to "basically anything else". Copy, delete, rename and folder creation are the baseline operations. That framing matters: this is not a file manager bolted onto a homebrew menu. It is a payload that runs before or instead of the normal operating system and exposes storage that the OS does not normally present to you.

The intended user is someone doing maintenance on hardware they own. The README's own warning says it "provides you with the means to do basically any thinkable modification to any system data available on the 3DS console". That sentence is the whole audience definition. If you are not prepared to modify system data, most of GodMode9's surface area is irrelevant to you.

How the write permission levels and the boot chain work

GodMode9 splits access into permission levels, and the highest one is deliberately awkward. The README states that the write permissions system "protects you by providing warnings and forces you to enter an unlock sequence for enabling write permissions", and that it is not possible to overwrite or modify important data without such unlock sequences. It also claims it is not possible to accidentally unlock something. The top level is described as a completely red screen, and the README tells users to stay on the yellow permission level or below at all times.

That is a design choice worth naming: safety here comes from friction, not from a sandbox. There is no undo. The unlock sequence is the only thing between a stray button press and a modified NAND partition.

The boot chain is the other half of the mechanism. The README recommends fastboot3DS as the bootloader and notes known issues for some users with the standard boot9strap plus Luma3DS setup. GodMode9 can also be installed as the bootloader itself; in that configuration the R+LEFT combo enters the bootmenu, and a SALTMODE build uses the START button instead. A SafeMode9 flavor exists as "a bricksafe variant of GodMode9, with limited write permissions", which is the closest thing to a read-mostly build.

Installing GodMode9 and running a first file operation

The README does not ship an installer of its own. It points at OpenFirmInstaller and says to follow the quick setup instructions found there, then to copy the gm9 folder from the release archive to the SD card. Two support files are optional but recommended for full functionality: seeddb.bin and encTitleKeys.bin, both placed in sd:/gm9/support. The README explicitly declines to say where to obtain them.

Once the card is back in the console, the README says you can run GodMode9 by holding the X button at startup, or whichever button you chose. From the main file view, A opens a submenu for files and opens directories; R+A on a directory brings up a submenu that includes what the README calls the invaluable title search. Y copies and pastes files, and R+Y creates folders and dummy files. The README recommends setting the RTC clock on first run via HOME then More, and fixing the system OS clock afterwards. It also recommends leaving screen brightness at a fixed value from that same menu, and warns that manual touch screen calibration is not recommended, with automatic configuration to be tried first.

Where GodMode9 is the wrong tool

The permission system is not a substitute for a backup. The README says so plainly: "be smart, keep backups, just to be safe". Nothing in the documented workflow prevents a user who has unlocked the red level from writing bad data. The unlock sequence stops accidents, not intent.

There is also a hard size constraint on customization. Files placed in the data folder at build time show up in the V: drive, but the README states there is a hard 223.5KiB limit for everything inside, including overhead. That rules out bundling large payloads into the build.

ntrboot builds carry their own gap. The README notes that some features, specifically boot9 and boot11 access, are not currently available from the ntrboot environment. If your recovery scenario depends on those, the ntrboot route will not cover it.

Finally, the README itself redirects. For step by step instructions on common tasks it sends readers to 3ds.hacks.guide, and it singles out users coming from Decrypt9WIP or Hourglass9 as the ones who will need it most. The repository is not trying to be a tutorial.

GodMode9 against a general purpose 3DS file manager

The obvious comparison is a homebrew file manager that runs as an ordinary application on top of the running OS. The difference is what each one can see. An application-level manager reaches the SD card through the OS filesystem APIs. GodMode9 runs as a FIRM payload and reaches the FAT partitions inside SysNAND and EmuNAND directly, which is exactly the storage an application-level tool is not given.

That extra reach is why the permission levels exist in GodMode9 and not in a normal file manager. A tool that cannot write to NAND does not need a red unlock screen. The trade-off runs the other way too: an application-level manager starts faster, does not change your boot configuration, and cannot brick anything. GodMode9 asks you to change how the console boots and to hold a button combo at startup.

SafeMode9 is the middle option inside this project rather than outside it. Building with make FLAVOR=SafeMode9 produces the limited-write variant, which keeps the file browser surface while narrowing what can be modified.

Building GodMode9 from source

Building requires devkitARM, firmtool and Python 3.5 or newer, per the README. The Makefile fails immediately if DEVKITARM is not exported, with the message "Please set DEVKITARM in your environment. export DEVKITARM=<path to>devkitARM". The README gives make firm as the way to build GodMode9.firm, and make release to get a nice, release-ready package of all required files. Flavor and layout are build-time switches documented in the README:

make firm
make release
make FLAVOR=SafeMode9
make SWITCH_SCREENS=1
make FIXED_BRIGHTNESS=x
make NTRBOOT=1

FIXED_BRIGHTNESS takes a value between 0 and 15, written as x in the README. The version string is derived from git describe --tags --abbrev=8, so building from a shallow clone or a tarball without tags will not produce the same version string as a tagged checkout. A standalone script runner is compiled by placing autorun.lua or autorun.gm9 in the data folder and building with make SCRIPT_RUNNER=1. The README says further customization is possible and points at the Makefiles rather than documenting it exhaustively.

Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-08-01. Releases are infrequent and named rather than numbered on a schedule: v2.2.3 is labelled a Tenth Anniversary Hotfix and was published on 2026-03-31, v2.2.2 a Tenth Anniversary Release on 2026-03-29, and v2.2.1 a Ninth Anniversary Release on 2025-10-24. A user tracking releases should expect long gaps between them and should not read a quiet period as abandonment.

Upgrading is a file replacement, not a package manager operation. The README's setup is copying the gm9 folder from the release archive to the SD card, so an upgrade means repeating that copy. Anything you have added under sd:/gm9, including seeddb.bin and encTitleKeys.bin in sd:/gm9/support, sits outside the release archive and is not touched by that copy. Build-time customizations are a different matter: a data folder you filled, a hardcoded aeskeydb.bin, a chosen internal font, or a FIXED_BRIGHTNESS value all live in your own build and have to be reapplied.

The project is GPL-3.0. That matters if you redistribute a modified build, since the licence carries source availability obligations. It does not restrict running GodMode9 on your own console. This is a description of the licence identifier, not legal advice; read license.txt in the repository for the actual terms.

Editorial conclusion

Adopt GodMode9 if you are repairing, backing up or inspecting a 3DS and you accept that the tool can modify any system data it can reach. Do not adopt it if you want a general purpose file manager or a desktop tool for 3DS images; the README points at 3ds.hacks.guide for step by step tasks instead. Before you start, verify which bootloader you are on, because the README recommends fastboot3DS and notes known issues for some users of the boot9strap plus Luma3DS setup, and confirm that your seeddb.bin and encTitleKeys.bin are in sd:/gm9/support.

Frequently asked questions

Official sources

1. d0k3/GodMode9 on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases