Start here

ns2jb is a softmod for the Nintendo Switch 2 that starts from a program you type into the game SmileBASIC 4. A computer on your network then walks the console through four stages, until it runs code as a system module and as the filesystem service. It's tethered and research-grade: a reboot puts the console back to stock, many runs fail, and there are no ready-made mods yet.

Is this for you?#

It is if you want to research or learn, you own the hardware and the full game, and you don't mind many failed tries.

You'll need:

• A Switch 2 on firmware 23.0.1 exactly.
• SmileBASIC 4 version 4.4.9, the full game, already bought on your account and installed in system memory. It's delisted from the eShop, and the free demo doesn't work.
• A macOS or Linux computer with Node.js 22+, on the same network as the console. A Windows PC can use WSL with extra network setup; see Run it › Windows and WSL.
• A way to type about 7,800 characters once: by hand, or with a device that acts as a USB keyboard.
• Patience. One user's first 4/4 took about 8 tries; another was about 350 in and still going.

It isn't for you yet if you want custom firmware, mods that survive a reboot, or emulators. None of those exist, and staff say emulation is far off. The full requirements are in Get it running.

Stuck on a message on screen? Go to Troubleshooting. Following the research? Start at Where the project stands.

Pick your path#

The host runs on macOS or Linux, or on WSL with extra setup; what you own decides how you type the bootstrap.

A Windows PC can't act as a USB keyboard without extra hardware, and the ns2jb README supports only macOS and Linux hosts. Each method's setup is in Type the bootstrap, and each host's in Run it.

Want homebrew rather than the filesystem demo? HBLauncher skips the filesystem stage. It starts far more reliably but can't reach the console's wider filesystem. Verified; see Run it › After 4/4.

Risks in brief#

The real risks are firmware lock-in, a brick from writes or tinkering, and unvetted files; no ban has been reported as of 10-26.

• Bans. A ban would generally hit the console, not your account, unless you cheat online or tamper with the account. None was reported as of 10-25, though the same reply says a run is detectable, and whether it would be caught is unknown. So the risk is unknown, not zero. The cautious norm is to block Nintendo's servers with DNS.
• Firmware lock-in. ns2jb needs 23.0.1 exactly, and updates only ever install the newest version, with no downgrade. A console's first microSD card also installs the newest firmware, which was still 23.0.1 at about 11:55 UTC on 10-26. kurumuz now urges taking that update while this holds; see Prepare your console › If you want to use a card.
• Bricks. Two consoles are confirmed bricked: one owner restored a save after a failed run, before rebooting, and the other let an AI tool edit the console's storage. A third recovered from a softbrick with a factory reset, and a frozen console recovers with a forced power-off. So reboot after a failed run before touching saves or files, never write to the console's storage, and keep AI tools and unattended rigs off the console.
• Writes and edits. The code can write to the filesystem unchecked, and writes alone can brick a console. daada relays a researcher's finding that the filesystem stage overwrites more than intended, and saw it overwrite their own SmileBASIC save once (Unverified). Parts are AI-assisted and not fully understood, so don't edit it or let an AI "fix" it.
• Online access. 90DNS blocks the eShop and online play, and the community guide's FAQ warns that turning it off later risks losing online access for good. Do anything online first. The supernag on offline consoles doesn't affect the SmileBASIC route; see Prepare your console › The supernag.
• Fake and unvetted files. The "NX2 CFW ACTIVATOR" is fake and likely malware, and one modified ns2jb tarball hung kurumuz's system. Use official releases from Links and tools, and check its Links and tools › Known fakes and untested files.
• Your computer. mac2jb's unsigned driver needs the Mac's SIP and startup security lowered, which weakens macOS security. Fully re-enabling SIP afterwards isn't verified and may stop the driver working; see Type the bootstrap › The SIP trade-off.
• Private data. Keep the host's pairing values out of screenshots, and keep HBLauncher's settings.toml to yourself: it stores your Wi-Fi credentials.

Remote bricking by Nintendo has no evidence behind it.

What's verified, what's claimed, what's refuted#

Verified means documented or independently reported by two or more people; Unverified means one report with nothing against it; Refuted means the evidence shows it's false.

Verified#

• Only firmware 23.0.1 is supported; older versions don't work.
• The first microSD card in a console installs the newest firmware, once per console.
• A wired console is the best-supported way past 2/4, though not a guarantee. One tester measured 0 of 29 runs on Wi-Fi and 5 of 29 wired, and the PC can stay on Wi-Fi.
• Any region's SmileBASIC 4.4.9 works.
• Nothing survives a reboot, and it isn't custom firmware: there's no kernel exploit.
• kurumuz's fork runs on consoles before and after the microSD update. Its START line changed, but an NS2 typed from the original still works with the fork's own host, not with mac2jb; see Type the bootstrap.
• HBLauncher skips the filesystem stage, so it starts far more reliably. It has no access to the console's wider filesystem; its ftpd-sb app reaches only SmileBASIC's own storage.
• WSL reached 4/4 for several users with mirrored networking and Hyper-V firewall rules, though some still get errors; see Run it › Windows and WSL.

Unverified#

• crueter reports 80%+ success after their own host changes, and kurumuz reports about 30% with their fork. Both are self-reports.
• Shinko reports moving control to a process outside SmileBASIC, until reboot. Metr1k claims the same; neither is released.
• kurumuz says they made it "untethered", meaning it survives leaving the app, not a reboot. Nothing is shown; see Where the project stands › Persistence.
• The release blog claims save backup, but no one has confirmed it.
• Metr1k claims full filesystem read and write with private tools.
• Gezine's cartridge-based route is announced but unreleased, and GreenSwede relays that pepsipu's browser (WebKit) route is in testing. See Where the project stands › Other entry points.

Refuted#

• "The NX2 CFW ACTIVATOR installs custom firmware": it's fake and likely malware.
• "The demo works" or "reached 4/4": an adapted bootstrap got only to 2/4, and staff say it doesn't work. Reaching RPC on it isn't success.
• "There's no ban risk": the hack-support FAQ warns of a possible ban. The risk is unknown, not zero.
• "You need a microSD card": you don't.
• "90DNS causes 2/4 stalls": helpers say it doesn't interfere.
• "Copied photos mean you have the microSD update": they prove nothing. Check your layout in Prepare your console.

Short answers on each are in the FAQ.

What this community stands for#

This is a research and education project, run on your own hardware with games you bought.

• Research and education. ns2jb is for security research and learning, and the support lead's notice says it isn't ready to be used freely.
• Your own hardware and legally bought games. Run it on your own console with a copy of SmileBASIC 4 you bought. Back up only games you own; see Backing up your own games.
• No piracy, and dumps stay private. Staff ask that full dumps are never shared in the community, and the same goes for extracted assets; see Datamining › Ground rules.
• Official releases, vetted before you run them. Download from the maintainers' own repos in Links and tools. Treat files posted anywhere else as untested until someone vets them.
• Findings shared, with credit. Post results in the research threads, such as Improving ns2jb reliability, and credit the work you build on.

Get it running

Three steps get ns2jb running: prepare your console, type the bootstrap, then run it. You do the first two once; the run itself often takes many tries.

Typing takes minutes with a typing device, or a few hours by hand. Success shows only in your computer's terminal, as "FS execution verified", and restarting the console undoes it. Before you start, read Start here › Risks in brief.

The whole run at a glance#

From a stock console to a verified run.

The dashed path is Verified: HBLauncher skips the FS stages, so it starts far more reliably, but without file access (Run it › After 4/4).

Runs often stall at 2/4 or 3/4. A stall means a full restart and another try, as Run it › Retry routine describes.

Requirements#

SmileBASIC 4 is no longer sold in any region. It was delisted, not patched. A copy you already bought can still be re-downloaded as of 25 Oct. That means going online, so do it only while 23.0.1 is the newest firmware. It needs no DLC.

The three steps#

1. Prepare your console, once: check your versions, block updates with 90DNS, check your console's layout and pick a build.
2. Type the bootstrap, once: type the program into SmileBASIC and save it. Compare the options in Type the bootstrap › Choose a method.
3. Run it, every session: start the host, enter four short lines, and retry until 4/4.

If a run fails, Troubleshooting › Symptom index lists fixes by symptom.

Get it running ›

Prepare your console

Do this once, before anything else. It keeps your console on the versions ns2jb needs and tells you which build to run.

Check your versions#

Your console needs firmware 23.0.1 and SmileBASIC 4 4.4.9, the full game. Get it running › Requirements lists the rest. ns2jb has only been verified on 23.0.1.

• On 23.0.1: you're set. Keep it there with the steps below.
• Below 23.0.1: ns2jb won't run. An update installs only the newest version, which was still 23.0.1 as of 26 Oct, about 11:55 UTC. limon notes one exception: a game card can carry a specific firmware.
• Should you update? Without SmileBASIC 4, the stronger side says no: the community guide's FAQ and a moderator's warning say wait. With it, this is Disputed, and neither side is stronger. pazoshama advises waiting; kurumuz sees no reason to stay behind, since Gezine's separate route is no better.
• Above 23.0.1: no newer firmware existed as of 26 Oct, about 11:55 UTC. If it ships, it isn't supported, and there's no downgrade.
• SmileBASIC updates: decline any app-update prompt for SmileBASIC. kurumuz reports you can still start 4.4.9 without updating.

Staying on 23.0.1 has a cost. Game cards carry firmware updates, and one that needs newer firmware won't play until you update.

Controller and dock updates are different. They install from the console itself, and one user took a controller update with 90DNS on. Of the updates people mention, only the microSD-slot update needs internet.

Stop updates with 90DNS#

90DNS blocks Nintendo's update and eShop servers, so nothing moves you off 23.0.1. It doesn't interfere with the run, and the run doesn't need it to work. It protects your versions, so keep it on during runs too.

1. Do anything that needs Nintendo's servers first. One user couldn't delete a Nintendo-linked user account with 90DNS on. To activate the microSD slot, see If you want to use a card first.
2. Turn off automatic software updates in System Settings.
3. Set DNS on the console itself, not on the router: System Settings → Internet → Internet Settings, pick the network, then DNS Settings → Manual.
4. Enter both 90DNS servers. In the Americas, use primary 207.246.121.77 and secondary 163.172.141.219; elsewhere, swap them. Don't use a public DNS such as 1.1.1.1 as the secondary.
5. Set both IPv6 DNS fields to ::, as the mac2jb README and these manual DNS steps describe. Then save.
6. Repeat on every saved network, Ethernet included, because DNS is set per network.
7. Fully restart the console. DNS changes apply only after a restart.

Good to know:

• If the console rejects 207.246.121.77, one user suggests padding the last group to 077.
• SmileBASIC shows a network warning at startup while 90DNS is on. That's expected.
• 90DNS's Switch 2 support is "still early" (90DNS README). If your ISP hijacks DNS, self-host it.
• Some helpers say auto-update off is enough on its own. This is Disputed; the guide's side, which adds 90DNS, is stronger.
• The guide's FAQ warns that turning 90DNS off later can lose online access for good. No user has reported this happening (Unverified).
• If the connection you run over gives the console internet access, kurumuz says to block Nintendo there the same way (advice, untested). Set 90DNS on that connection too.
• Disputed: "Going online is safe if you don't start an update." The stronger side says it's safe only while 23.0.1 is the newest firmware, as limon puts it: online is fine until newer firmware ships. After that, one user's online console learned of the newer firmware, and acron says its browser then stays locked until you update (The supernag).

Confirm the block#

After the restart, connect with airplane mode off and open the eShop. Error 2811-1007 ("Unable to display page.") is the only result that confirms the block. "This feature is not available" isn't a block; it means The supernag.

If the eShop still opens, check your router. An ISP router pushing its own DNS overrode 90DNS for one user, and another got the expected error over a phone hotspot. Restart after every DNS change before you test again, and see Troubleshooting › Console prep.

The supernag#

The supernag locks the console's web applets once it has gone without reaching Nintendo for a while. The browser, eShop and captive-portal pages then show "This feature is not available". It isn't tied to ns2jb: it happens on any firmware, and a never-modded console got it too. 90DNS doesn't prevent it.

• What it blocks: the browser and eShop applets, which a browser (WebKit) route would need (Where the project stands › Other entry points). It doesn't force an update. It doesn't touch the SmileBASIC route; with the full game, you can ignore it.
• How to check: open the eShop as in Confirm the block. Error 2811-1007 means you're fine; "This feature is not available" means you're nagged.
• Clearing it means going online, with the update risk that brings. On 23.0.1, check Nintendo's system update page, turn 90DNS off and restart. Then open the eShop until it loads, turn 90DNS back on, and restart.
• It comes back, so keep checking. Reports range from right after a reboot to about a day. On 90DNS, one user gets it every 2–3 hours, even after airplane mode, sleep or shutdown.
• When to stop: Hexa says stop clearing it once newer firmware ships. Connecting then makes the console learn of the update, and its browser stays locked until you install it. A browser-only route would stop working at that point. On older firmware, clearing it doesn't work: the console sees the newer version and keeps nagging.
• Factory reset: it doesn't clear the nag. One user's reset from the recovery menu erased the inserted microSD card during setup.
• System saves: don't delete them to clear it. That's untested, and it writes to the console's storage, the kind of action behind a confirmed brick.

What triggers it is Disputed, and neither side is stronger. One user points to 90DNS itself, another to any disconnection, such as airplane mode. Whether reboots speed it up is unclear too.

Can you prevent it?

• Refuted: "Cutting the console's internet at the router, or using a no-internet captive-portal network, prevents it." Without internet, one console was nagged twice in airplane mode. Another had never been online, and its captive-portal browser worked on a no-internet network; it was nagged as soon as it joined a real network with 90DNS.
• Disputed: "Block Nintendo before the console ever goes online, and it will never be nagged." Its proponent hasn't tested it, and the never-online console above was nagged on its first 90DNS connection. The "inevitable" side is stronger: Dank calls the nag an inevitability on 90DNS.

microSD and your layout#

If you've used a microSD card in this console, it has probably taken the update; use kurumuz's fork. ns2jb itself doesn't need a card.

• The update. The first time a console uses a microSD card, it installs a one-time update to the newest firmware, even if it's already current. It can't be removed.
• Express cards. If you plan to use a microSD Express card, insert it while 23.0.1 is still the newest firmware, so a second update prompt couldn't move the console past 23.0.1. Whether the regular-card update also covers Express is Unverified: helpers say it adds Express support, and a moderator has heard of Express cards prompting a second update.
• What it changes. With 23.0.1 the newest, consoles that took it stayed on 23.0.1. It does change the memory layout from (A) to (B), which upstream ns2jb can't handle; kurumuz's fork handles both.
• Your odds. It doesn't change them: kurumuz says it doesn't really help runs, and the fork works with or without it. "You need the update to reach 4/4" is Refuted.
• If newer firmware ships, a console's first card use would install that version instead, moving it past 23.0.1.

Check your layout#

Open System Settings → Support/Health & Safety and look at item 3. (B) means the update is installed, and (A) means it isn't. The check comes from the fork README, and kurumuz confirms (B) means installed. Switchbrew's page reads the other way, but it describes Switch 1.

Copying photos from a card works without the update, so it proves nothing. Item 3 is the reliable check.

If you want to use a card#

Whether to take the update now is Disputed; for a 23.0.1 console, the take-it side is now stronger. On 25 Oct kurumuz reversed their earlier "skip it if you won't use a card" and now urges taking it, since homebrew will need a card. Hexa agrees. Either way, a (B) console needs kurumuz's fork.

The condition: the update installs whatever firmware is newest. Take it only while that's 23.0.1; once newer firmware ships, it would move the console past 23.0.1, which ns2jb doesn't support. Taking it also means turning 90DNS off, which SD.md requires, so do it before modding.

1. Check Nintendo's system update page shows nothing newer than 23.0.1. Then turn 90DNS off and restart. The update comes from Nintendo's servers.
2. Format a regular microSD card as exFAT on a computer. FAT32 never offers the update, and a Switch 1 formats cards of 32 GB or less as FAT32. You don't need an Express card.
3. Go to System Settings → Data Management → Manage Screenshots and Videos → Import from a Nintendo Switch microSD card.
4. Insert the card only when asked, then accept the update.
5. Set 90DNS again, restart, and Confirm the block.
6. Check item 3 again; it should show (B). If you have an Express card you'll use later, insert it now too, while 23.0.1 is the newest (see Express cards above).

The update runs only once per console. If item 3 already shows (B), no prompt appears, because it's installed. Card errors are in Troubleshooting › Console prep.

Choose your build#

Use kurumuz's fork if item 3 shows (B); it also works on (A). The community guide recommends it either way, and kurumuz confirms it's still the one to use. Upstream pepsipu/ns2jb expects the (A) layout only.

The fork isn't a cure. It can still fail at 3/4, and kurumuz says it may not help if you never reached 3/4. It doesn't fix Wi-Fi either (Run it › Best odds).

Whether it helps at 2/4 is Disputed, and the it-helps side is stronger. One user went from about 100 failures to 4/4 almost every time, while another found it worse than upstream.

• kurumuz reports 4/4 about 40% and later about 30% of the time on their fork (Unverified: one user's figures).
• One user went from about 1 success in 150 tries on upstream to working runs on the fork.
• Get either build from GitLab, and use the fork's latest commit. Modified ns2jb archives posted on Discord are untested files; one hung kurumuz's system. See Links and tools › Known fakes and untested files.

Get it running ›

Type the bootstrap

You type it once; the full game saves it. Later runs load the saved program and need only four short lines (Run it › Step by step). The free demo can't save it, and it can't complete a run anyway.

What you're typing#

You type the contents of bootstrap.bas from your build's repo, kurumuz's fork or upstream: about 224–229 lines and 7,800 characters, starting at the first VAR line. Typing the file name does nothing, and SmileBASIC has no way to download it. HBLauncher uses the usual bootstrap, not one of its own.

1. Open SmileBASIC, choose Make a Program, and press X for the editor. Don't type it in Direct mode.
2. Type the program, or let your device type it.
3. Save it as NS2 in slot 0: press Ctrl+S on a keyboard, or press minus and choose Simple Save. If the menu says Load instead, CapsLock is on.
4. Go through Check your typing before your first run.

The fork's bootstrap differs. kurumuz removed the pairing code, so the fork's START takes only the port and the computer's IP. If you're typing it now, take it from the same build as your host.

• Typed the original? On the fork's own host, you don't need to retype. That host also prints a START line ending ,0,0,0,0, which works with an original NS2 (fork README). If SmileBASIC says "Wrong number of arguments", use that line (Run it › Step by step).
• On upstream, type its full line: passing zeros is an option on kurumuz's fork, which removed the pairing code.
• On mac2jb, the zeros don't apply. It can't run an original NS2, so retype as Mac (mac2jb) describes.

Settings every method needs#

Set these before you type, whatever the method.

• Keyboard layout: set HOME → System Settings → Controllers & Accessories → USB Keyboard to English (US), then restart SmileBASIC. Typing devices send US keycodes, so any other setting garbles symbols, such as £ for #. A console reset clears this setting. If you hand-type on a non-US keyboard, choose your keyboard's language instead.
• CapsLock: turn off SmileBASIC's Settings → "CapsLock on USB Keyboard". A typing device can't know the CapsLock state, so this setting causes wrong case throughout.
• Speed: one user used 50 ms per character and 100 ms per line, and another 100 ms per key. Typing too fast drops characters, so slow down most at newlines.
• Keyboard-only device: the console ignores devices that also report a mouse or trackpad. Use one that reports only as a keyboard.
• Empty editor: start each typing pass in an empty editor. Don't resume a half-typed transfer (mac2jb docs).

Choose a method#

An ordinary Windows or desktop PC can't act as a USB keyboard, so you either type by hand or use a device that can. Only this first typing needs a device; later runs need four short lines you can type yourself. Every method below ends with the same saved program, so pick one you already own.

Hand typing#

Needs: a wired USB keyboard, in the dock's USB-A port when docked. One user found Bluetooth keyboards aren't supported. The on-screen keyboard opens with minus.

Setup: apply Settings every method needs, type from the first VAR line to the end, and save.

Known issues:

• It takes about 2.5 hours to 5 hours.
• Typos are the usual cause of BOOT FAILED codes; one user cleared error 11 by retyping.
• Whether it's practical is Disputed. It works, but helpers prefer a typing device.

Evidence: Verified. Several users typed it by hand, and one who took 2.5 hours later reached 4/4.

Raspberry Pi Pico (RP2040)#

Needs: a Raspberry Pi Pico (RP2040), a USB cable, and any computer for setup. A Pico is cheap. A Pico W and a Waveshare RP2350 also work. HBLauncher's official setup uses a Pico 2 W that also types the bootstrap (Run it › After 4/4).

Setup (pico-smilebasic-autotyper):

1. Hold BOOTSEL while plugging the Pico into your computer, then copy the bundled CircuitPython UF2 to it.
2. Copy boot.py, code.py, bootstrap.bas and lib/ to the CIRCUITPY drive.
3. Open the SmileBASIC editor, then plug the Pico into the console. It types the program.

The CIRCUITPY drive then disappears on purpose, so the Pico shows up only as a keyboard; the README explains how to get it back.

Known issues:

• Its maintainer reports it works at 50 ms for key press and release.
• Other CircuitPython typers must show up as a keyboard only. Make boot.py enable just the keyboard device; that got a Waveshare RP2350 typing.
• One user saw wrong case, dropped Enters and extra indents with a Pico typer. CapsLock explains the case; sending Enter twice fixed the rest, and the extra blank lines did no harm.
• A Pico typer announced without a link, PicoUSB_Switch2, and a "Payload Writer" zip shared only on Discord are untested files (Links and tools › Known fakes and untested files).

Evidence: Verified. Two users report Pico typers working, one on a Pico and one on a Pico W. Another says they've been using pico-smilebasic-autotyper on an RP2040.

ESP32-S2/S3#

Needs: an ESP32-S2 or ESP32-S3 board, the variants with native USB.

Setup: no vetted ESP32 typer has been published, so you write your own. The nxcontroller firmware for the ESP32-S3 is an untested file (Links and tools › Known fakes and untested files). One user's board takes text from a web server and types it. On a board with two USB-C ports, one user types through the native USB one.

Known issues: typing too fast made one user's run go wrong twice. Slow it down as Settings every method needs describes.

Evidence: Verified. Three users report typers working, on an S2 and on S3 boards. Using other ESP32 boards is Refuted: they can't act as a keyboard.

Modded Switch 1#

Needs: a homebrew-enabled Switch 1, a USB-C cable and an OTG adapter, plus one of these:

• plume-usb v0.1.6, which types a text file over USB.
• jgallardst's nxhid v0.3.1, which a computer drives over Wi-Fi with Python 3.8+.

Setup:

1. Install the homebrew on the Switch 1 and put the bootstrap text on it.
2. Plug into the Switch 2's bottom USB-C port, not the top, with the OTG adapter on the Switch 2 side.
3. Open the SmileBASIC editor and send the file.

nxhid can also send the Direct-mode lines on later runs.

Known issues:

• In plume-usb, press Y to toggle QWERTY and AZERTY. It has separate per-character and Enter timings; its defaults worked for one user.
• plume-usb 0.1.7, known only from a news article, and ezBasic, described as an updated plume-usb, are untested files.
• The original hyln9/nxhid drops its connection to a Switch 2 on a USB reset. jgallardst's fork fixes this, its author reports; a helper couldn't confirm it.

Evidence: Verified for the Switch 1 route and plume-usb: several users typed it this way, including one who got it working after changing ports. jgallardst's nxhid fork is Unverified; only its author reports it working.

Rooted Android#

Needs: a rooted Android 9+ phone or handheld whose kernel supports USB HID gadgets (configfs), and pecrow's switch-script-keyboard v1.2. Root is required.

Setup:

1. Install the APK from the v1.2 GitLab release, and check it against its SHA256SUMS.
2. Connect to the Switch 2 through the dock or directly over USB-C.
3. Open the SmileBASIC editor, then send the bootstrap text from the app.

Known issues:

• Rooting a daily phone carries warranty and security costs; a Pico is cheaper.
• Apps that act as keyboard and mouse at once, such as android-hid-client, type on a PC but not on Switch 2.
• The kernel support matters: a rooted Quest 2 couldn't type because its kernel lacked configfs HID.
• One user let an AI assistant drive their rooted phone as the keyboard. In their write-up, it paced the typing and corrected a reversed CapsLock state (Unverified: one user's report).

Evidence: Verified. kurumuz types with an Odin 2. Other users report rooted handhelds and phones working.

Mac (mac2jb)#

Needs:

• An Apple Silicon Mac on macOS 14 or newer. The author first tested a MacBook Pro M4 (Mac16,1) on macOS 26.4.1.
• A data-capable USB-C cable, and more than 20 MiB free in SmileBASIC's save.
• Ethernet for the Switch 2. The README says it's likely required, since Wi-Fi isn't verified yet.
• mac2jb v0.4.3, released 26 Oct. It bundles Node, kurumuz's fork as its host and that fork's bootstrap.
• SIP and startup security that permit an unsigned driver, as The SIP trade-off explains.

Setup:

1. Download mac2jb only from its GitHub Releases. The app is ad-hoc signed and not notarized, so approve it under System Settings → Privacy & Security → Open Anyway (GUI guide).
2. Lower the Mac's security as described below, then choose Install & load driver… (CLI: mac2jb.command --install-driver) and restart when asked. Continue once the app reports the driver loaded.
3. Connect the cable. Don't let the Mac charge the Switch; if it does, unplug and reconnect.
4. The first time, choose Type bootstrap only: open an empty SmileBASIC editor and let mac2jb type, about 7–10 minutes at 50 ms per key. Check the program, then press X and save with SAVE "NS2"; mac2jb doesn't save it for you.
5. Typed NS2 from the original bootstrap? Retype it with step 4. mac2jb needs its bundled kurumuz bootstrap, and an original NS2 won't work with it.
6. On later runs, restart the console, open Direct mode, then choose a mode. mac2jb starts its host and sends the Direct-mode lines for you:
   • Held RPC, the default, keeps the connection open for homebrew and OunceCake.
   • System-code dump saves accessible system-program code, then finishes.
   • NS2JB exploit only checks the exploit and finishes. It can't launch homebrew.
7. After a Held RPC run reaches 4/4, mac2jb can launch one homebrew tool or OunceCake per session, with no Pico needed.

Known issues:

• mac2jb sends US-QWERTY keycodes, whatever your Mac's layout. Set the Switch's USB keyboard to English (US); changing the Mac's layout doesn't help.
• The app tries USB controllers usb-drd0, usb-drd1 and usb-drd3. That mapping was seen on Mac16,1 only, and you can pick any from 0 to 15.
• A loaded driver doesn't prove it works; characters appearing in SmileBASIC do. "Keyboard transfer completed" means only that the keys went out.
• Older tutorials describe building the driver yourself. v0.4.3 bundles it.
• Its "demo" option doesn't make the free demo reach 4/4. It only gets the bootstrap running; the run itself can't work there, since the demo lacks the temporary storage it needs.
• An early v0.4.x report describes a "driver couldn't load" loop after restarting (Unverified).
• Mac users' runs stall at the same stages as everyone's, so a Mac isn't reliably better than Linux. The author's successful tests were all over Ethernet.

Evidence: Official tool. Typing is Verified on earlier builds: two users typed with a Mac and reached 2/4 with mac2jb. v0.4.3 is Unverified beyond the author's own tests.

The SIP trade-off#

mac2jb loads an unsigned kernel extension, which your Mac's SIP and startup security must permit. It's a real security cost, and the choice is yours.

What you change (mac2jb README, Official)

• Reduced Security: in macOS Recovery's Startup Security Utility, choose Reduced Security. Tick "Allow user management of kernel extensions from identified developers".
• SIP off: in Recovery's Terminal, run csrutil disable, then restart. Back in macOS, csrutil status should report SIP disabled.
• A partial or custom SIP setup: if the driver already loads with one, keep it. v0.4.1 removed the check that wanted SIP fully disabled.
• AMFI: not needed. The README doesn't ask for it, and mac2jb doesn't change it. One user had it off, an untested extra.

What it costs (general macOS behaviour)

• SIP stops even an administrator from changing protected parts of macOS, and Reduced Security lets unsigned code run with kernel privileges.
• Together they make the Mac easier to compromise, and the driver is experimental third-party code.
• mac2jb's README says disabling SIP reduces macOS protection, and mac2jb doesn't change it for you.

Turning it back on (your decision; general macOS procedure)

mac2jb's README says fully re-enabling SIP after installing the driver hasn't been verified. It may stop the driver working after a later kernel-collection rebuild. If you still want protections back:

1. Restart into Recovery: hold the power button until startup options appear, then choose Options.
2. Open Terminal from the Utilities menu, run csrutil enable, and restart.
3. To undo Reduced Security, set Full Security in the same Startup Security Utility.
4. If you turned AMFI off, turn it back on too.

If the driver then stops loading, using mac2jb again means lowering security and installing the driver again.

Keeping the SIP-off time short. You type the bootstrap once, and later runs need just four short lines. Typed by hand with kurumuz's fork as the host, they need no driver, so one mac2jb session can be enough. mac2jb's own runs, Held RPC included, type those lines over the cable, so they do need it. That's a suggestion, not a mac2jb instruction.

If you'd rather not lower security at all, use another method. The Mac still works as the host (Run it › macOS).

Flipper Zero#

Needs: a Flipper Zero with BadUSB, and a BadUSB script for the bootstrap, such as the one in this r/switch2hacks post. Set the console's USB keyboard to English (US).

Setup:

1. Copy the script to the Flipper.
2. Open the SmileBASIC editor, connect the Flipper, and run the script from BadUSB.

Known issues:

• It's slow: one user's Flipper was 70% done after 29 minutes.
• The Reddit script didn't work for one user, who then wrote their own.
• flipper2jb, posted by its author to automate the typing, is an untested file with no user reports yet.
• Typos are common. Raising the delays from 200 to 350 ms didn't fix them in the one test, while Unleashed firmware at 200 ms worked for another user. This is Disputed, and neither side is stronger.

Evidence: Verified. Two users report typing it with a Flipper, one on Unleashed firmware. The Reddit script itself is Unverified.

Other devices#

These work in principle, but most have fewer reports.

Check your typing#

Check the program before your first run; most early failures are typos.

• Right mode: if each line gives "Syntax error" and then OK, you're typing in Direct mode. Press X and type in the editor instead.
• Characters and case must match the file exactly. Don't type it all in caps: helpers say case matters (advice, untested).
• What doesn't matter: indentation is harmless, since one typer added hundreds of extra spaces and still worked. Extra blank lines did no harm, and the leading comment lines can be skipped.
• Letter O versus zero: lines 53 and 54 use the letter O. A zero in its place gave one user BOOT FAILED 10.
• The | character: it's on the broken-bar key.
• Spaces: a missing space gave one user NEXT without FOR.
• Pasted text: one user's pasted copy turned && into ^^ (Unverified). Check for it if a phone app sent your text.
• Error lines: an error ending "in 0:11" points to line 11 of the program in slot 0.

Then run it. After V=START(...), a correct program shows BOOT OK, while BOOT FAILED with a number means a typo. Troubleshooting › Typing explains the codes.

Get it running ›

Run it

A wired console plus kurumuz's fork is the best-supported setup. Both are Verified improvements, but neither guarantees a run: some wired users on the fork still stall at 2/4, so expect several tries.

Best odds#

The console needs a local network path to the computer, not internet, and the cable needn't go to the PC.

• Console to the router: works even with the PC on Wi-Fi. A SteamOS 4/4 came this way.
• Direct cable: also works, with connection sharing or addresses on one subnet. No side-by-side test shows which is better.
• Adapters: the dock has an Ethernet port, and any plug-and-play USB adapter works.

crueter has offered reliability changes to the fork, and kurumuz merged an update on 25 Oct, so use its latest commit. Their earlier host-side patches, posted only in a Discord research thread, are meant to go with the fork.

One tester found those patches more reliable; crueter's own 80%+ figure is Unverified. Treat them, like any Discord-only file, as untested (Links and tools › Reliability patches).

One user's first verified setup (Unverified: one user's report). In an AI-assisted write-up, they list the setup that first got them to 4/4. The same settings had failed the attempt just before, so they don't claim any single setting made the difference.

• kurumuz's fork at commit 7867de3, with the fork's original timings. They added a logging patch of their own, which they say changed only error reporting.
• The Switch wired directly to a Mac, using macOS Internet Sharing.
• A full restart, then 15 seconds idle in Direct mode.
• 120 ms per keystroke.
• 3-second waits after LOAD, the confirmation and RUN, and 6 seconds after REMOVE.
• About 176 MiB free in SmileBASIC's save.

A second AI-assisted setup (Unverified: one user's report). Another user with repeat 4/4s runs pepsipu's code inside a heavily modified harness, with verbose logging and tools that let the AI model inspect the run. Nobody else has reproduced it. Keep any AI tool off the console itself (Retry routine).

Start the host#

The host is ns2jb's run.cjs, and the common steps are the same everywhere:

1. Install Node.js 22 or newer.
2. In the extracted ns2jb folder, run node run.cjs.
3. When asked, pick the computer's LAN IP on the console's network. Picking another of its addresses gave one user BOOT FAILED 58.
4. Allow TCP 39380 through any firewall.

The README supports macOS and Linux only. Each OS below uses the same template and lists only what differs.

macOS#

Support: official in the ns2jb README.

Setup: the mac2jb app bundles its own Node and host. If macOS asks, allow incoming connections (mac2jb GUI guide); if you dismissed the prompt, check System Settings → Network → Firewall. A direct cable also works: one user wired the Switch straight to a Mac using macOS Internet Sharing (Best odds).

Known issues: a Mac isn't reliably better. One user failed 30+ times on two Macs, then succeeded on Linux. An M3 and an M4 Pro MacBook on Ethernet still stalled.

Evidence: Verified. Users report 4/4 on an M4 Mac mini and on a wired Mac with the fork.

Linux#

Support: official in the ns2jb README.

Setup: nothing beyond the common steps. For a direct cable to the dock, use NetworkManager's internet sharing.

Known issues: none specific to Linux.

Evidence: Verified. Several users report 4/4 on Linux, including one who failed 30+ times on Macs first and one on a direct-cable laptop.

Windows and WSL#

Support: not supported by the README. WSL works once its networking is set up; native Windows doesn't yet. A Linux Live USB is the fallback.

Setup for WSL:

1. Turn on WSL's mirrored networking mode, so the host uses your PC's own IP. Binding to the WSL address also works.
2. Add Hyper-V firewall rules that let the console reach the host on TCP 39380.
3. Set the Windows network to Private, then run the host inside WSL as on Linux.

Known issues:

• WSL errors: one WSL user still stalls at 2/4, and another says WSL doesn't work at all. Intermittent "connection is not ready" errors cleared after several console restarts for one user.
• Native Windows: run.cjs uses a fixed, Linux-style temp path, so creating its folder fails on Windows, and kurumuz says it isn't working there. Switching to Windows' own temp folder gave a different error.
• Private Windows builds: some users report 4/4 with their own patched builds, which aren't public. A Windows GUI wrapper, NS2-Desktop, is an untested file (Links and tools › Known fakes and untested files).
• Firewall: a Public network setting or the firewall caused BOOT FAILED 58 in two reports (Troubleshooting › The host).
• VM: one helper says an Ubuntu VM on Windows works; another user failed about 70 times in WSL and VMs. This is Disputed, and the failure side is stronger.

Evidence: WSL is Verified: several users reached 4/4 with mirrored networking and firewall rules, including one on the first try and one tester's 29-run log. Some still fail, so it's less proven than native Linux. Native Windows is Disputed, and the failure side is stronger: the public fork fails as above.

SteamOS#

Support: not listed in the README, but SteamOS is Linux.

Setup: SteamOS runs firewalld by default. One helper suggests stopping it temporarily to test, with sudo systemctl stop firewalld, then starting it again afterwards (advice, untested). With a direct cable to the Deck, a helper says you might need connection sharing (advice, untested; Bek's SteamOS 4/4 used the router). Pick the Deck's address on that link.

Known issues: one user's SteamOS host never connected. Picking the Deck's Wi-Fi address for a cabled console gave another user BOOT FAILED 58.

Evidence: Unverified. Bek reports a SteamOS 4/4, with the console wired to the router and the Deck on Wi-Fi.

Live USB#

Support: a live USB runs Linux, so Linux's support applies. Helpers suggest it as the fallback for Windows users.

Setup:

1. Put a Linux image on a USB stick, for example with Ventoy, and boot its "try" mode.
2. Install Node.js in the live session, then follow the common steps.
3. Reboot into your usual system afterwards; nothing on it changes.

Known issues: none beyond Linux's.

Evidence: Unverified as its own route, though Linux is Verified. One user went from WSL failures to 4/4 on a live USB.

Step by step#

Do this every session, and again after every failure.

1. Fully power off the console, then start it (Retry routine).
2. Open SmileBASIC and enter Direct mode: hold minus or press F8.
3. On the computer, start the host (Start the host). Choose the computer's LAN IP, not an address set on the console.
4. In Direct mode, enter each line on its own, and confirm the load:

   LOAD "TXT:NS2"
   RUN
   REMOVE NSR,&H60000000,&H3FFFFFFF

   "Out of memory" after REMOVE is expected. The README uses LOAD "TXT:NS2". LOAD "NS2" is said to load the same way, and one user's run with it connected and reached 2/4 (Unverified: one run).

5. Type the V=START(...) line the host prints. With kurumuz's fork it holds only the port and the computer's IP, so it stays the same between runs; upstream's numbers change every run. Typing speed doesn't matter, though the host times out eventually (fork README).
   • "Wrong number of arguments" means your NS2 is the original bootstrap. Type the fork host's second START line, ending ,0,0,0,0, without repeating RUN or REMOVE (fork README; Type the bootstrap › What you're typing). On mac2jb, retype the bootstrap instead.
6. Keep both running until the host prints FS execution verified, or stops.
7. Restart the console when you're done. ns2jb is tethered, so a restart undoes everything. Starting the fork's host as node run.cjs --rpc keeps the connection open after 4/4 instead, for tools such as OunceCake (Backing up your own games › Running OunceCake).

Reading the stages#

The host prints four stages, and only the host shows success: nothing changes on the console.

"RPC working" isn't success; only 4/4 is. A run's length doesn't show it either: successful runs take 5–6 minutes, but failures can last minutes too.

If the console freezes at 2/4 or 3/4, hold the power button until the screen is fully off; it doesn't brick. Troubleshooting › The run's stages covers the messages at each stage.

If your goal is HBLauncher, it skips the FS stages entirely (After 4/4).

Retry routine#

Every attempt needs a clean start.

1. Fully power off the console: hold the power button and use the power options. Closing SmileBASIC isn't enough.
2. Keep the runs folder, and enter REMOVE only once per boot.
3. Start over from Step by step, with the new V=START(...) line.
4. Don't touch files first. After a failure, reboot before you restore, delete or manage the save. The first confirmed brick followed a save restore with no reboot.
5. Don't edit the exploit. Don't change the host code or its expected values, or let an AI "fix" it. A helper warns against changing it in any way.
6. Keep AI tools and unattended rigs off the console. An AI tool working the console on its own is how one of the two confirmed bricks happened. Nothing should write to the console's storage; see Start here › Risks in brief.

One user's checklist (Unverified: one user's report). The same write-up adds these points:

• Match the complete build: take the bootstrap and host files from one fork, not a mix.
• Keep over 20 MiB free inside SmileBASIC's save; console and microSD space don't count.
• After a failure, restart fully and use a fresh V=START(...) line. Never enter REMOVE twice in one session.
• Run only one host, and keep the computer awake.
• Record the first specific error before changing timing, because a later timeout can hide it.
• Leave the run's validation checks on; they tell an unreliable state from real success.

They add that no single change was a universal fix, so change one thing at a time.

Restarting between attempts is Disputed. kurumuz says to restart only if the console hangs, and otherwise just restart SmileBASIC. The README and the fork's own error text, "restart the console before another launch", say restart every time, and that side is stronger.

Expect many attempts: reported tries range from about 8 for a first 4/4 to about 350 and counting. The clearest measurement is 5 of 29 wired runs, about 17%; kurumuz puts their own odds at about 30%.

Other per-try claims range from 0% to 85%, but they're self-reports from different setups and aren't comparable. ns2jb's issue #1 documents odds of about 20%, and luck varies by day.

After 4/4#

Nothing is installed, and a restart returns the console to stock. These optional apps all run as GPU-shader programs inside SmileBASIC, not native code, and use the same bootstrap.

If your goal is HBLauncher, you don't need 4/4 (Verified). HBLauncher skips the FS stage, so it starts almost every time, even where full runs stall. In exchange, it gets no file access.

• That's why a Windows HBLauncher package works even on Wi-Fi: it never tries the FS stages, so its success says nothing about 2/4.
• mac2jb v0.4.3 loads homebrew and OunceCake with no Pico, but only after a Held RPC run reaches 4/4 (Type the bootstrap › Mac (mac2jb)).

Whether HBLauncher counts as real homebrew is Disputed. The stronger side: it's a real launcher for shader apps, with no privileged access and no native code. Its author says real homebrew is "a ways off".

A no-Pico HBLauncher package shared only on Discord failed on one Mac. Treat it, and any Discord-only package, patch or tarball, as an untested file; prefer GitHub or GitLab releases. That includes input-noop.patch, which removes the Pico, and an HBLauncher video player (Links and tools › Known fakes and untested files).

App errors are in Troubleshooting › After 4/4, and every app's link is in Links and tools › After 4/4: homebrew and research tools. For what research may unlock next, see Where the project stands.

Troubleshooting

Find what's on your screen in the index, then use the fix in its section. Most failures are a typo, a blocked connection, or a stall at 2/4, the step where most runs fail.

Each section is a table: You see · Why · Fix · Evidence. Verified means documented, or two or more independent reports. Unverified means one report, Disputed means credible evidence on both sides, Unknown means no answer yet, and Refuted means shown false.

Symptom index#

• Console prep: the eShop still loads with 90DNS set; "This feature is not available" in the eShop or browser; "Content not available" after removing 90DNS; "No importable data" or "not compatible" from a card; photos copy but no update prompt.
• The app: BOOT FAILED 14; a network warning when SmileBASIC starts; SmileBASIC hangs, won't open, or sticks on "preparing software".
• Typing: BOOT FAILED with any other number; Syntax error, NEXT without FOR or an error ending in 0:NN; Syntax error then OK after each line; wrong symbols, such as £ for #; wrong case, or a save menu that says Load; a typer that drops characters, or one the Switch 2 ignores.
• The host: BOOT FAILED 58; a host stuck on "Waiting"; runs that fail on Windows or WSL; EADDRINUSE.
• The run's stages: Out of memory or Type mismatch after REMOVE; Wrong number of arguments; RPC STOP 0 or RPC STOP 32768; a stall at 2/4 or 3/4; 2/4 failing within seconds; "Pinning allocation cost changed"; EEXIST or "Save mount was not inspected"; "Insufficient tmp space" or "Insufficient save space"; a frozen console.
• After 4/4: nothing happens on the console; everything is gone after a reboot; "No apps in launcher catalog" or spawn python3 ENOENT; "Required input import unresolved"; "Native function mapping or instructions differ"; FTP shows only a few folders, or NS2 changed.

Console prep#

Prep problems come from 90DNS not taking effect, or from a microSD card that won't trigger the update. The full steps are in Prepare your console.

Copied photos don't prove you have the update. To check, see Prepare your console › microSD and your layout.

The app#

App problems mean the wrong version, or SmileBASIC data damaged by a failed run.

Typing#

Errors in this phase are almost always typos, and a correct script prints BOOT OK.

The host#

Host problems are almost always the network: the console can't reach your computer.

Setup for each OS, WSL included, is in Run it › Start the host.

The run's stages#

Stage 2 is where most runs fail. Before the next try, fully restart the console, as the README and the fork's error text advise; Run it › Retry routine covers the dispute. What each stage means is in Run it › Reading the stages.

Your console's layout and which build to use are in Prepare your console › microSD and your layout and Prepare your console › Choose your build.

After 4/4#

A finished run shows only on the computer, and it lasts until you reboot.

More on what to do next is in Run it › After 4/4. Problems while backing up your own games, such as short files or a frozen console, are in Backing up your own games › Fixing common problems.

Things that make it worse#

These moves are tempting after a failure, but each one adds risk without fixing the cause.

• Restoring a save or files before you reboot. One of the two confirmed bricks came from restoring a SmileBASIC save after a failed run, without rebooting first. Run it › Retry routine explains the safe order.
• Writing to the console's storage, or letting an AI tool or unattended rig do it. The other confirmed brick came after an AI model edited system storage. kurumuz's rule is simple: don't write to your NAND.
• Taking the microSD update to fix 3/4. kurumuz says it doesn't really help runs, and the fork works without it. Once newer firmware exists, the update also installs that version. Taking it for future homebrew is a separate choice: see Prepare your console › If you want to use a card.
• Turning 90DNS off to fix stalls. 90DNS doesn't interfere with the run. The guide's FAQ warns that turning it off risks your online access.
• Factory-resetting to clear "This feature is not available". A reset doesn't clear the supernag, and one reset from recovery erased the inserted microSD card.
• Deleting system saves to clear the supernag. It's untested, and it writes to the console's storage, the kind of action behind a confirmed brick.
• Running unvetted tarballs, zips and repos. One modified tarball hung kurumuz's system. See Links and tools › Known fakes and untested files.
• Editing the script to get past the demo's check. It's untested and not public, and a demo researcher says the check exists for a reason.
• Erasing save data as a first step. It deletes NS2. Reboot first after a failed run, and raise the save size first for save-space errors.

Still stuck?#

Ask in the community's support channel, and include the details below. Most answers depend on them.

First, find which stage fails before you change any timing settings. JMY's write-up calls this the most useful rule (Unverified, one user's report).

• Your firmware version and SmileBASIC version, and whether SmileBASIC is in system memory.
• Your build: the original release or kurumuz's fork.
• Your microSD state: item 3 in Support/Health & Safety shows (A) or (B).
• Your host OS, and how each device connects: Ethernet or Wi-Fi.
• Your typing method.
• The exact message and the stage it stopped at, with a photo of the console and the host's output.
• What the run's acquisition.log says; it's in the run's switch2 folder.
• How many attempts you've made, and whether you fully restarted between them.

Redact your pairing values before you post. If you use HBLauncher's Pico, never share its pairing key or settings.toml, which holds your Wi-Fi password. On the original release, blur the random numbers in your V=START(...) line too.

FAQ

Short answers to the questions people ask most, each with its evidence label and a link to the full story. Seeing an error message? Go straight to Troubleshooting.

Labels: Verified (documented, or two or more independent reports), Unverified (one report), Disputed (credible evidence on both sides), Refuted (shown false) and Unknown (no answer yet).

Most asked#

1. Is it worth doing now, and can I mod games?
2. Do I need a microSD card?
3. Does the free demo work?
4. Which firmware works, and is there anything newer?
5. What can type the bootstrap for me?
6. Can I use Windows, WSL or a VM as the host?
7. Does Ethernet help?
8. Will running it get me banned?

Topics#

• Getting started
• The app
• Firmware and updates
• The microSD card
• Typing the bootstrap
• The host computer
• Odds and retries
• After 4/4
• Risk and bans
• Where the project is going
• Backing up your games
• The community
• Myths and facts

Getting started#

What is ns2jb?#

Verified. It's pepsipu's tethered softmod for the Switch 2, public since 22 Oct.

• You type a BASIC program into SmileBASIC 4, and a host program on your computer runs four stages.
• It runs native code as a system module and as the filesystem service.
• It isn't CFW, and nothing survives a reboot.

More: Start here

What do I need?#

Verified. The full SmileBASIC 4 (4.4.9), firmware 23.0.1, a computer, and a keyboard or a device that types for you.

• SmileBASIC installed in system memory, with more than 20 MiB free in its save.
• A computer with Node.js 22+ on the same network: macOS or Linux per the README, or WSL.
• Ethernet for the console: one tester's Wi-Fi runs all stopped at 2/4.
• No DLC, no microSD card, no second game and no AI.

More: Get it running › Requirements

Is it worth doing now, and can I mod games?#

Verified. Mostly for research: staff and helpers say it's too early for casual users.

• ns2jb's payload runs two functions, then restores the original state.
• You can now back up your own games' files for study, and HBLauncher runs a few shader apps.
• You can't mod games yet: the Mario Kart World mods were hardloaded, not a mod loader, and weren't released.

More: Start here › Is this for you?

Does it work on a Japan-only console?#

Verified. Not so far: two users failed on Japan-only consoles, even with the full SmileBASIC 4.

• kurumuz hasn't tested one and thinks its firmware may differ.
• The cause is Unknown, and no fix exists yet.

More: Where the project stands › Other entry points

The app#

Which SmileBASIC do I need, and can I still get it?#

Verified. The full SmileBASIC 4, version 4.4.9, and any region's copy works.

• No region sells it any more; it was delisted in all regions by 23 Oct.
• If you bought it on your own account, you can re-download it, even after uninstalling. That needs 90DNS off, so first check that 23.0.1 is still the newest firmware.
• Staff still advise not uninstalling it.

More: Get it running › Requirements

Does the free demo work?#

Refuted. fuyuka, who maintains the setup guide, says it doesn't work on the demo.

• The unmodified script stops with BOOT FAILED 14, and logs show runs stopping at stage 2. A 10-26 mac2jb retry still failed.
• "Works" reports mean only that the bootstrap starts and reaches RPC. The run never reaches the filesystem stage, which needs storage the demo lacks.
• A 25 Oct "4/4 on the demo" report was the full game.
• The demo is no longer offered.

More: Where the project stands › The demo (4.4.6)

SmileBASIC wants to update. Can I keep 4.4.9?#

Unverified. Probably: kurumuz believes you can start the game without updating.

• Decline the prompt, because ns2jb needs 4.4.9.

More: Prepare your console › Check your versions

Firmware and updates#

Which firmware works, and is there anything newer?#

Verified. Exactly 23.0.1, the only verified version.

• As of about 11:55 UTC on 26 Oct, nothing newer existed, and nothing had been patched.
• A patch is expected eventually, so check Nintendo's update page before you go online.

More: Prepare your console › Check your versions

I'm on older firmware. Should I update?#

Disputed. ns2jb needs 23.0.1, but an update can't be undone.

• Without SmileBASIC 4, staying is the stronger side: the announcement says don't update.
• With it, neither side is stronger. kurumuz sees no reason to stay behind; pazoshama says staying lower keeps future routes open.
• Updates only ever install the newest version.

More: Prepare your console › Check your versions

How do I stop updates?#

Verified. Turn off automatic updates, then set 90DNS in the console's own Internet settings.

• Set it on every saved network, wired included, then restart: DNS changes apply only after a reboot.
• Only error 2811-1007 in the eShop confirms it works. If the eShop loads, your router's automatic DNS may override it.
• Make account changes first: one user couldn't delete a linked user with 90DNS on.

More: Prepare your console › Stop updates with 90DNS

Is turning off auto-update enough?#

Disputed; 90DNS is the safer side. Some say auto-update off is enough, but one accidental tap on an update prompt is permanent.

• An online console learns of newer firmware even if you never start an update.
• A console with no connection can't update, so delete saved networks or unplug the dock's Ethernet.
• DNS blocking is the suggested extra layer.

More: Prepare your console › Stop updates with 90DNS

Will a game or cartridge force an update?#

Unverified. Per one helper, a game that needs newer firmware won't run until you update.

• Hexa notes that no Switch 2 cartridge has forced a firmware update yet.
• Some cartridge updates are optional.
• Controller and dock updates install from the console itself and work with 90DNS on; only the microSD-slot update needs internet.

More: Prepare your console › Check your versions

What is the supernag, and should I clear it?#

Verified. The eShop and browser show "This feature is not available" once a console hasn't reached Nintendo lately.

• It doesn't affect the full SmileBASIC or force an update, so you can ignore it.
• Clearing it means going online without 90DNS. One 90DNS user gets it every 2–3 hours, even in airplane mode.
• Once newer firmware ships, it can't be cleared without updating; Hexa says stop clearing it then.
• The trigger is Disputed: 90DNS or, the stronger side, any disconnection.

More: Prepare your console › The supernag

The microSD card#

Do I need a microSD card?#

Verified. No: ns2jb doesn't use one.

• You type the bootstrap in, so nothing loads from a card.
• A card matters because of the one-time update it triggers, which kurumuz says future homebrew will need.

More: Prepare your console › microSD and your layout

What is the "microSD update"?#

Verified. It's a one-time download the console needs before the card slot works at all.

• It also installs the newest firmware, even if you're already on it.
• It happens once per console and can't be undone, per the setup guide.
• While 23.0.1 is the newest version, you stay on it.
• If you'll use a microSD Express card, insert it while 23.0.1 is the newest firmware. Whether this update covers Express is Unverified.

More: Prepare your console › microSD and your layout

I've used a microSD card in this console. What now?#

Verified. It has probably taken the update, which the original release can't handle, so use kurumuz's fork.

• The fork works with or without the update. Your saved NS2 still works: if START says Wrong number of arguments, use the second START line the host prints.
• To check, open Support/Health & Safety and look at item 3: (B) means installed, and (A) means not.
• Copied photos prove nothing, because import works without the update.

More: Prepare your console › microSD and your layout

Should I take the microSD update now?#

Disputed; taking it is now the stronger side on 23.0.1. On 25 Oct kurumuz urged taking it, or you won't have homebrew when it arrives.

• That reverses kurumuz's 23 Oct advice to skip it without a card. Hexa also says take it now if you want a card.
• It needs 90DNS off, commits you to the fork, and doesn't help runs.
• The condition: once newer firmware exists, the update would install it, ending the softmod.

More: Prepare your console › If you want to use a card

How do I trigger the update with a regular card?#

Verified. Format the card as exFAT, then start the import before you insert it.

• FAT32 cards don't trigger it, and a Switch 1 formats cards of 32 GB or less as FAT32.
• Turn 90DNS off first, because the update needs internet.
• Open Data Management → Manage Screenshots and Videos → Import, and insert the card when asked.
• It works without a Switch 1 or an Express card, but a regular card can only import.

More: Troubleshooting › Console prep

Typing the bootstrap#

Error while typing? See Troubleshooting › Typing.

What do I type, and where?#

Verified. The contents of bootstrap.bas, from the first VAR line; the file name alone does nothing.

• Type it in Make a Program's editor, not Direct mode. X switches between them, or F7 and F8 on a keyboard.
• With Joy-Cons, minus opens the on-screen keyboard.
• You can't load it over HTTP.

More: Type the bootstrap › What you're typing

How do I save it and run it again later?#

Verified. Save it as NS2 in slot 0 with Ctrl+S or Simple Save, and the full game keeps it.

• After each restart, start node run.cjs on your computer.
• In Direct mode, enter LOAD "TXT:NS2", RUN, the REMOVE line, then the V=START(...) line the host prints. On the fork, it holds just the port and your computer's IP.
• If the save menu says Load, CapsLock is on.

More: Run it › Step by step

How long does hand typing take?#

Verified. The bootstrap is about 225 to 229 lines, roughly 7,800 characters.

• The times are self-reports: one user took 2.5 hours, and another heard of about 4.
• You type it once, because the full game saves it.

More: Type the bootstrap › Hand typing

What can type the bootstrap for me?#

Verified. Anything that acts as a wired USB keyboard. A helper says it must report only as a keyboard; that fixed one board (Unverified). You need it only for the first typing.

• Best documented: a Pico with pico-smilebasic-autotyper, an ESP32-S2 or S3, or a modded Switch 1 with plume-usb.
• Rooted Android phones and Apple Silicon Macs also work.
• Fewer reports: a Flipper Zero, a Steam Deck, a Pi 4B and a Pi Zero W. Bluetooth keyboards don't work.

More: Type the bootstrap › Choose a method

Can my phone or computer type it?#

Verified. A rooted Android phone or an Apple Silicon Mac can, but Windows can't do it in software.

• Android: switch-script-keyboard needs Android 9 or newer, root and kernel HID support.
• Mac: mac2jb is at v0.4.3. Its unsigned driver needs SIP and startup security lowered, a real security cost. Fully re-enabling SIP afterwards isn't verified and may stop the driver working. One early user couldn't load it.
• Linux devices need a dual-role USB port, such as a Steam Deck's.

More: Type the bootstrap › Choose a method

The host computer#

Host error such as BOOT FAILED 58? See Troubleshooting › The host.

Can I use Windows, WSL or a VM as the host?#

Disputed; WSL works once set up, and native Windows mostly fails. The README supports only macOS and Linux.

• WSL reached 4/4 for several users. Set up mirrored networking and Hyper-V firewall rules first. Some still get errors.
• Native Windows: one run failed on a Linux temp-folder path, and kurumuz says it doesn't work on Windows.
• A Linux live USB got one user to 4/4, and one helper says an Ubuntu VM works.

More: Run it › Windows and WSL

Does the run need internet, 90DNS or a USB link to the computer?#

Verified. No: it needs only a shared local network, even a router with the modem unplugged.

• The console can be wired to the router with the computer on Wi-Fi, or cabled straight to the computer.
• 90DNS doesn't interfere with the run, so keep it set on that connection too.
• No USB link to the computer is needed.

More: Run it › Start the host

Odds and retries#

Why does it keep stopping at 2/4?#

Verified. Stage 2 is the filesystem step: it's timing-sensitive, and it's where most runs fail.

• The game stage before it is "100% reliable", per kurumuz.
• Use Ethernet, and keep SmileBASIC in system memory. Failures within seconds can mean a full save.
• Restart fully and try again.
• Only want HBLauncher? See Do I need a 4/4 run to use HBLauncher?

More: Run it › Reading the stages

What's the success rate?#

Disputed; low either way. Every figure is a self-report, and issue #1 documents about 20%.

• On the original release, fuyuka estimates about 6%; another helper says 5 to 10%, and 20% at best with fixes.
• kurumuz puts their own rate at about 30%, and one wired tester logged 5 of 29.
• Luck varies by day.

More: Run it › Best odds

Does Ethernet help?#

Verified. Yes, and it's now measured: one tester logged 0 of 29 runs on Wi-Fi and 5 of 29 wired.

• The console's cable can go to the router, with the computer on Wi-Fi.
• Wired isn't a guarantee: one user failed 15 times.
• kurumuz says it won't succeed on Wi-Fi, because the timings matter too much.

More: Run it › Best odds

Do user profiles or internal storage matter?#

Verified. Profiles don't, but where SmileBASIC is installed does.

• Neither which account launches it nor the profile count makes a difference.
• SmileBASIC must be in system memory: moving it off the microSD card cleared repeated failures, and another user found the same cause.

More: Run it › Best odds

Do I restart between attempts?#

Disputed; the README side is stronger. Yes: keep the runs folder, fully restart, and enter REMOVE once per launch.

• The fork's own error text also says restart the console before another launch. kurumuz says restart only if it hangs.
• Either way, reboot before touching saves or files: one brick followed a save restore without a reboot.
• A freeze is safe: hold power until the screen goes off; that doesn't brick it.

More: Run it › Retry routine

Which build or patches should I use?#

Verified. Use kurumuz's fork, which the setup guide recommends and kurumuz still backs.

• It supports the microSD update and waits longer and cleans up better. Its START line is shorter, but an old NS2 still works.
• It got some people to 4/4 but not others.
• crueter's timeout patches are Unverified: fuyuka found them "more reliable", and 80%+ is crueter's own figure.

More: Prepare your console › Choose your build

What does success look like?#

Verified. Nothing shows on the console; the host prints "FS execution verified".

• It's a proof of concept.
• A reboot undoes everything.

More: Run it › After 4/4

After 4/4#

How do I browse the console's files?#

Verified. Install ftpd-sb in HBLauncher, then connect with any FTP client over Wi-Fi.

• It reaches only SmileBASIC's RomFS, save and temp folders, and its writes change real files, NS2 included.
• No full-filesystem FTP app is public; FP's file explorer is claimed but unreleased.
• To copy your own games' files, see Backing up your own games › Running OunceCake.

More: Run it › After 4/4

Is HBLauncher real homebrew?#

Disputed; "real but very limited" is the stronger side. It runs real apps, but they're GPU shaders inside SmileBASIC, not native code.

• Its author calls it a vibe-coded proof of concept, not an hbmenu.
• kurumuz calls it userland-only and "pretty much fake", while jan says it plainly works.
• Apps include ftpd-sb and a Celeste port. Nothing persists after the session.

More: Run it › After 4/4

Does HBLauncher need a Pico 2 W?#

Verified. The official setup uses one, plus a Linux host.

• The Pico stores your Wi-Fi credentials and a pairing key, so keep those private.
• mac2jb v0.4.3 can load homebrew after a Held RPC run reaches 4/4, with no Pico.
• FP's no-Pico zip, which failed on one Mac, and an input-noop.patch are unvetted. On Windows, see Troubleshooting › After 4/4.

More: Run it › After 4/4

Do I need a 4/4 run to use HBLauncher?#

Verified. No: HBLauncher skips the filesystem stage, so it starts almost every time.

• The trade-off: it gets no file access beyond SmileBASIC's own.
• It still needs the full SmileBASIC 4, the same bootstrap and a working connection to the host.

More: Run it › After 4/4

Can it run emulators or real apps?#

Unknown. Native code is possible, but no app or toolchain uses it yet.

• Shown but unreleased: a Moonlight streaming client. Claimed but unshown: FP's file explorer and kurumuz's private NRO loader. IZLauncher is reportedly nearly done.
• The viral Half-Life clip was streamed, and fuyuka's Linux demo is a GPU shader.
• Don't expect emulation soon.

More: Where the project stands › Native homebrew

Risk and bans#

Will running it get me banned?#

Unknown. No bans had been reported as of 25 Oct, but the risk is unknown, not zero.

• Nobody knows whether it would be caught, and nobody has read the console's telemetry yet.
• On Switch 1, bans followed piracy, online cheating and modified online saves, not homebrew alone.
• The server's FAQ warns of a possible ban if you update and reconnect.

More: Start here › Risks in brief

If I'm banned, what do I lose?#

Verified. A ban hits the whole console, not your account or family, unless you cheat online or tamper with the account.

• One user quotes the message: online services "on this console" are restricted.
• Banned consoles still get updates.
• There's no evidence of remote bricking.
• One user says a backup of the console's storage can't undo a ban, because bans are recorded on Nintendo's servers (Unverified).

More: Start here › Risks in brief

Does staying offline avoid a ban?#

Disputed; the cautious side is stronger. Staying offline is the usual advice, but it may only delay things.

• One user says that on Switch 1, activity was logged and sent on reconnect.
• Nobody has checked what a Switch 2 logs.
• The cautious norm is offline plus a DNS block.

More: Prepare your console › Stop updates with 90DNS

Has anyone bricked a console?#

Verified. Two confirmed bricks, plus one softbrick that was recovered. Both bricks involved extra steps.

• One owner restored a SmileBASIC save after a failed run, without rebooting first.
• The other let an AI model edit system storage.
• A third console froze on every boot after about 190 tries. A factory reset fixed it.
• So reboot after any failure, never write to the console's storage, and keep AI tools and unattended rigs off it.

More: Start here › Risks in brief

Which tools are fake or risky?#

Refuted. The "NX2 CFW ACTIVATOR" isn't real: it's fake and likely malware.

• The "ounce-core" emulator is an AI-generated fake; no malware was found.
• The WebKit route hasn't been released, so files offered as it are fakes.
• Zips and tarballs shared without a repo are unvetted. One modified tarball hung kurumuz's system.

More: Links and tools › Known fakes and untested files

Where the project is going#

Is it CFW or a kernel exploit?#

Verified. No: it runs code in one system module and the filesystem service, without kernel access.

• Some say it "does most of what CFW would". The side pointing to its limits, tethered with no persistence, is stronger.

More: Where the project stands › What it can reach

What can it reach?#

Verified. ns2jb's filesystem stage gets privileged access beyond SmileBASIC's container.

• HBLauncher apps don't; they stay inside SmileBASIC's files.
• Anything kernel-level, such as Linux, is out of reach for now.

More: Where the project stands › What it can reach

Will it become untethered or run native homebrew?#

Unverified. Not yet: it's still tethered, and every "untethered" claim is unshown.

• kurumuz says their build survives leaving the app and is "not that useful" alone.
• A relayed Gezine save-based route has no detail and is reported still in progress, secondhand. kurumuz says that kind of route was already known.
• Metr1k's private build wasn't released.
• For native homebrew, kurumuz has an NRO loader privately.

More: Where the project stands › Persistence

Is there another way in besides SmileBASIC?#

Unknown. None is public as of 26 Oct.

• GreenSwede relays that pepsipu has a browser (WebKit) route working on 23.0.1, still in testing (Unverified). It would give the same access, not more.
• The Artemis-save and cartridge routes are unreleased, and no Artemis saves have surfaced. The Artemis route's developer says it works on Switch 2, and a free demo is enough.
• Japan-only consoles fail the SmileBASIC route; see Does it work on a Japan-only console?

More: Where the project stands › Other entry points

Does it work on a Switch 1?#

Disputed; the hands-on result is stronger. The first stage reproduced on a Switch 1, but the filesystem step didn't work as-is.

• Others argue it should, because the two systems share most of their software.
• On a Switch 1 OLED, two helpers expect the exploit would fail because its memory layout differs; that's a prediction, untested.

More: Where the project stands › Other entry points

Backing up your games#

Can I back up the games I own?#

Verified. Yes: Hexa's OunceCake, public since 25 Oct, dumps the unencrypted RomFS and ExeFS of games you own.

• It needs a run of kurumuz's fork started with the --rpc option.
• You get loose files, not NSP, XCI or NCA packages. Installed games and cards dump, and so do their updates and DLC.
• Not covered yet: saves, which Hexa plans to try a tool for. Nintendo Classics apps still fail.
• Dump only your own games; Hexa doesn't share assets.

More: Backing up your own games

Can I play or emulate the games I back up?#

Verified. No: dumps can't be reinstalled or run on the console.

• No Switch 2 emulator runs them, and emulators may take a while.
• Hexa says the tool isn't meant for playable dumps; it's for datamining and study.
• It's read-only on purpose, so it can't write files back either.

More: Backing up your own games

What have people found in game files?#

Verified. Mostly codenames and file layouts so far.

• "Ounce" is the Switch 2's codename, and "Spiral" appears in Splatoon Raiders' files.
• A "banana" service in one game's metadata is a profiler service that most apps carry.
• A New Super Mario Bros. U Deluxe update ships symbols, not a debug build.
• Legends Z-A's Switch 2 Edition file is a dummy.

More: Datamining

The community#

Where are new findings posted?#

Verified. In the research threads, such as "Improving ns2jb reliability" and the microSD firmware fix.

• r/switch2hacks has guides for typing devices.
• 0ver_flow (staff) expects more is shared on ReSwitched.

More: Links and tools

Myths and facts#

Each myth below has been shown false or replaced by newer facts.

Where the project stands

ns2jb works, but not reliably: the game-side step always runs, while the filesystem step often fails, and nothing survives a reboot.

Works, doesn't yet, in progress#

Works

• Full runs to "FS execution verified" on firmware 23.0.1 with SmileBASIC 4.4.9. Users began reaching 4/4 on 10-23, and many have since.
• The game-side stage: kurumuz calls it "100% reliable".
• kurumuz's fork on consoles before and after the microSD update.
• Hosts on macOS and Linux, and now on WSL and SteamOS; see Run it.
• Shader apps inside SmileBASIC, such as HBLauncher and ftpd-sb. A Celeste Classic port runs the same way.
• Typing the bootstrap by hand or with several kinds of device; see Type the bootstrap.
• Backing up your own games with OunceCake, and the system's programs with kurumuz's firmware dumper; see Backing up your own games.

Doesn't work yet

• Reliable runs. Self-reported success runs from 0% to about 85%, and the figures aren't comparable.
• Anything that survives a reboot.
• Native homebrew, custom firmware or kernel access.
• The free demo (4.4.6).
• Playing, emulating or reinstalling games you back up: dumped games can't run.
• Emulation, which staff say is far off.

In progress

• Reliability patches and forks, from kurumuz and crueter.
• Running code as a separate process.
• Native apps and loaders, shown or announced but unreleased; see Native homebrew.
• Other entry points: the browser (WebKit) route in testing, plus a cartridge route and an Artemis-save route.

What it can reach#

ns2jb's filesystem stage reaches beyond SmileBASIC's sandbox; the apps built on it so far don't.

• The release blog says code runs as an ordinary system module and as the filesystem module. It shows Mario Kart World character mods, which weren't released.
• The community guide calls it "userland with extra benefits". Staff confirm it has privileged filesystem access, outside SmileBASIC's container.
• There's no kernel exploit, so anything kernel-level is out of reach.
• HBLauncher apps are GPU shaders that stay inside SmileBASIC's container.
• Public tools now read your own installed games and the system's programs, unencrypted, since the filesystem service serves them that way. Details are in Backing up your own games.

What's new#

The last two days brought public backup tools, a nag on offline consoles and a browser route in testing.

• 10-26. mac2jb went from v0.4.0, which added homebrew, to v0.4.3, which adds OunceCake. v0.4.1 removed its fully-off SIP check. An NS2 typed from the original bootstrap must be retyped; see Type the bootstrap › Mac (mac2jb).
• 10-26. Unverified: GreenSwede relays that pepsipu's browser (WebKit) route works on 23.0.1 in testing, and another user relays that pepsipu is looking for testers on older firmware. It wasn't released as of 10-26.
• 10-25. Hexa released OunceCake, renamed from PoundCake, for backing up your own games; see Backing up your own games › Running OunceCake. Datamining of those backups followed; see Datamining.
• 10-25. kurumuz reversed their advice and now urges taking the microSD update. It installs the newest firmware, so this holds only while that's 23.0.1; see Prepare your console › If you want to use a card.
• 10-25. Users of offline and 90DNS consoles began reporting the supernag, "This feature is not available" in web apps. It doesn't affect the SmileBASIC route; see Prepare your console › The supernag.
• 10-24. kurumuz published a firmware dumper in their fork, and several users ran it. It outputs system programs only, without keys.

As of about 11:55 UTC on 10-26, no newer firmware or patch had shipped, and as of 10-25 no ban had been reported. Two consoles are confirmed bricked; see Start here › Risks in brief.

Open challenges#

Six problems shape what comes next. Each lists what's been shown, what's claimed, and what's next.

Reliability of stages 2 and 3#

• Shown: The game-side step is reliable; the filesystem step depends on factors nobody yet understands.
  • A wired console, SmileBASIC in system memory and kurumuz's fork help most; see Run it › Best odds.
  • One tester measured 0 of 29 runs on Wi-Fi and 5 of 29 wired. Luck also varies from day to day.
• Claimed:
  • crueter reports 80%+ after their own changes.
  • kurumuz puts their own rate at about 30%. Another user estimates 5–10% on the original and about 20% with fixes.
• Next:
  • Proposals include a written spec of the exploit and a Rust or Go port. Another asks for one shared launcher.
  • crueter plans to publish their own fork.

Persistence#

• Shown: Nothing survives a reboot; it runs from memory only.
• Claimed:
  • Shinko reports moving control to a resident process, until reboot.
  • Metr1k claims a private build that does the same. Neither is released.
  • Unverified: kurumuz says they made it "untethered": it survives leaving the app. They call that "not that useful" alone. Nothing has been shown, so it stays tethered.
  • Unverified: Gezine's save-based route is reported in progress, secondhand and without detail. kurumuz notes an Artemis save route was already known.
  • Disputed: whether it can ever survive a reboot. Gezine thinks so, and kurumuz said "no way" on 10-23. The skeptics' side is stronger, since nothing has been shown.
• Next: kurumuz is working on running it as a separate process.

Native homebrew#

• Shown: Every public app runs as GPU shaders inside SmileBASIC, not native code. HBLauncher's author calls it a proof of concept.
  • Two clips aren't native: fuyuka's Linux runs inside a Vulkan shader, and a Half-Life clip was streamed.
• Claimed:
  • kurumuz says C code can run, but no public app or toolchain uses it yet.
  • HBLauncher's author agrees real homebrew needs CPU execution.
  • Shown or announced, but unreleased: a streaming client, FP's file explorer, kurumuz's NRO loader and IZLauncher. Nobody else has run them.
• Next: A separate native process, which Rixy says is "not a trivial thing to do". Another member is building a loader for NRO files.

Deeper access#

• Shown: Reads of the filesystem service and 64 system-title executables. kurumuz's firmware dumper now does this for anyone, with system executables only.
  • OunceCake dumps your own installed and card games, unencrypted; see Backing up your own games.
  • Keys aren't obtainable.
• Claimed:
  • Metr1k claims full filesystem read and write.
  • kurumuz expects no kernel exploit, ever.
  • A viral "kernel exploit" post most likely meant this softmod.
  • Disputed: whether the Switch 2 kernel or early-boot code has been dumped. One user reports dumping the kernel, still encrypted, and another says early-boot code was dumped. kurumuz says they have no handle to that code, and a researcher says a kernel dump would need a kernel exploit or a key that's likely unreadable. The denial is stronger: nothing has been shown, and the reported kernel dump is still encrypted.
• Next:
  • Researchers warn against any writes, and Hexa keeps OunceCake read-only on purpose.
  • Hexa will port it to the browser route if it doesn't work there.

Other entry points#

• Shown: None is public. ns2jb needs SmileBASIC today.
  • It fails on Japan-only consoles, for one user so far.
  • On a Switch 1 OLED, dj found the filesystem step didn't work. Others put this down to a different memory layout.
• Claimed:
  • Staff say other entry points exist.
  • Unverified: GreenSwede relays that pepsipu's browser (WebKit) route works on 23.0.1 in testing. It isn't out, so "WebKit" files offered now are fakes; see Links and tools › Known fakes and untested files.
  • Disputed: the browser route's reach. mason expects the same access as SmileBASIC, while one user relays, unsure, that Gezine expects no filesystem access. The same-access side is stronger.
  • Gezine's cartridge route is still to come, and no Artemis save files are out. pazoshama guesses the cartridge route targets firmware below 22.5.
  • Unverified: the Artemis route's original developer says it works on Switch 2 but isn't released. A free demo of an Artemis-engine game is enough for it; full or physical copies aren't needed.
  • As of 10-26, one or two Artemis-engine demos were pulled. Seedsow Lullaby's is still on the US and UK stores. Get it from your own region's store. Hexa suggests installing a free one just in case, going online only while 23.0.1 is the newest firmware (Prepare your console › Check your versions).
  • A second game only eases relaunch and still needs SmileBASIC.
• Next:
  • pepsipu's release of the browser route, after testing on older firmware.
  • The console's captive-portal browser doesn't open with a DNS blocker, and the supernag blocks web apps; see Prepare your console › The supernag.

The demo (4.4.6)#

• Shown: Unsupported. The unmodified bootstrap fails with BOOT FAILED 14, and staff say it doesn't work.
  • One user's adapted bootstrap also stopped at stage 2. Researchers agree the demo lacks storage the run needs.
  • It still fails as of 10-26, 14:15 UTC: one user retried it with mac2jb without success.
• Claimed:
  • "Works on the demo" reports cover only saving and starting the bootstrap, and at most RPC, which doesn't mean the exploit worked. The run never reaches the filesystem stage, and mac2jb's demo option claims only the bootstrap part.
  • Disputed: Braxiatel relays pepsipu saying on 10-24 that it should work in theory with updated offsets. Nobody has shown it working, so the failure side is stronger.
  • Refuted: reports of 4/4 on the demo. One was on the full game, and no demo run has reached the filesystem stage.
    • Cold says the demo works with mac2jb, all four stages, and later that it needs the latest mac2jb. No log was shared. A user who followed their steps hit BOOT FAILED 14, and a later retry with mac2jb failed too.
• Next: Nothing verified.

Where the project stands ›

Backing up your own games

You can now back up games you own. Hexa's OunceCake, public since 10-25, copies a game's code (ExeFS) and assets (RomFS) to your computer, unencrypted. The copy is for study and Datamining: it can't be played, emulated or reinstalled.

Ground rules#

• Your own copies only. OunceCake reads the games on your own console. Hexa won't share game assets, and this page covers nothing about games you don't own.
• Never share dumps. Staff ask: "don't share full dumps in this server". The same goes for extracted files and links to them, and for asking others for them. Posting game dumps publicly is a good way to get the server banned.
• No keys. None are needed, since the console serves the files unencrypted. This page gives none.
• Read only. Copy files off the console; never write to it. OunceCake is read-only on purpose, and filesystem writes can brick the console.
• Write-ups go to the research threads. Rixy invited Hexa to document her RomFS reads in a thread.

What's been shown#

OunceCake dumps games as loose folders. Hexa says downloads, cards and key cards all dump fine, but some content fails, such as Nintendo Classics apps.

A few single titles fail; see Fixing common problems.

What a dump is:

• Loose, unencrypted RomFS and ExeFS folders, not NSP, XCI or NCA packages. Raw NCAs can be copied by other means, but nobody can decrypt them.
• Each game has a /base folder, plus /updates/<version> when an update is installed. The update folder already holds the full game, so copy /base only if you want the original version.
• It can't be played, emulated or reinstalled. Hexa built it for sprites, models and the like, not playable copies.

kurumuz's firmware dumper:

• It's public in kurumuz's fork since 10-24, and several users have run it.
• Run node dump-firmware.cjs instead of node run.cjs, with the same SmileBASIC steps. After 4/4 it saves each system program's code to dumps/, with or without the microSD update. The fork's README has the details.
• On a Mac, mac2jb's System-code dump mode saves accessible system-program code, then finishes.
• dumps/firmware-dump.json lists what was saved, with a SHA-256 hash per file. The next dump run clears dumps/, so copy it first.
• It outputs only the system programs' code (ExeFS), as plain files. There's no RomFS or assets, no keys and no kernel: a researcher says dumping the kernel would need a kernel exploit or a key that's likely unreadable.

Running OunceCake#

You need a run that reaches 4/4, then a few commands on the same computer. It works, but isn't beginner-friendly. Exact commands are in OunceCake's README.

What you need:

• kurumuz's fork as your host, updated on 10-25 or later for its --rpc option. OunceCake's README asks for it.
• The latest OunceCake, cloned from its repo. It's plain Node.js, so there's nothing to build. Copies before Hexa's 10-25 evening fix can corrupt files.
• The computer that runs the host, since OunceCake reads the host's run folder. Node.js and the network setup are as in Run it › Start the host.
• Your console's local IP address, from its network settings.
• An FTP client you can set to binary mode (also called Image or TYPE I), such as FileZilla.

Steps:

1. Start the host with node run.cjs --rpc and reach 4/4 as usual. If you forgot --rpc, run again: OunceCake needs that open connection.
2. Leave SmileBASIC open and the host running. Note the "Run folder" path the host prints.
3. In a second terminal, in OunceCake's folder, run node ouncecake.cjs <run folder>. It lists your installed and card games with their title IDs; pick one. A title ID after the folder skips the menu.
4. Wait for FTP up!, then connect your FTP client to the console's IP, port 2121. No username or password is needed.
5. Set binary mode, then copy only the folders you want.
6. For another game, or after swapping a card, stop OunceCake and start it again. The run doesn't need redoing.
7. When you're done, stop OunceCake, press Ctrl-C in the host's terminal, and restart the console.

On a Mac, mac2jb v0.4.3 has OunceCake built in (Official). After a Held RPC run reaches 4/4, enter the console's IP, choose Open game list, pick your game, then Start FTP. Wait for "Game files are ready", then connect as in steps 4 and 5, in passive mode. It's one tool per console session, and there's more in Type the bootstrap › Mac (mac2jb).

One user reports dumping about 12 of their own games with kurumuz's fork and both devices on the LAN. Their runs reached 4/4 in 30–40 minutes on average (Unverified: one report).

Fixing common problems#

Update OunceCake first: on 10-25 Hexa fixed crashes, hangs and corrupted transfers.

Check your dump:

• Compare each file's size with the size the FTP server lists. A smaller file is corrupted.
• The dump-hash thread. The community's Game Dump Hashes thread lets owners confirm a good dump. Its starter asks for SHA-256 hashes of each game's exefs and romfs folders, and pins the ones two people match.
• Hash your own folders the way the thread explains, then compare. A match means your dump is intact. Post hashes only, never files.

Still debated#

Refuted: "dumps are .nca files", "cartridges stay encrypted" and "ExeFS is unusable without keys". The README and Hexa's check of the code show unencrypted ExeFS, from cards and downloads alike.

What it would take#

Backing up works today. Playing, modding or restoring games would take much more:

• Keys for packages. Whole NCA4 packages stay encrypted, and nobody has the keys. Switch 1 tools can't help: Switch 2 cards use a newer protocol and keys.
• A way to use the files. There's no Switch 2 emulator and no public mod loader. Modified RomFS written back would fail signature checks, so the game wouldn't launch.
• No writes. Hexa won't risk any writes, and writing to the console's storage is risky.
• A run each time. The softmod is tethered, so every reboot means another run before you can dump; see Run it › Best odds.
• Patch risk. kurumuz expects the filesystem bug to be fixed. If the browser route needs it, Hexa plans to port OunceCake.

Where the project stands ›

Datamining

Datamining here means looking inside files from games and system software you own, after you've backed them up; see Backing up your own games. This tab covers which formats open, with what, and what people have found so far.

Ground rules#

• Your own copies only. Work on what you dumped from your own console and games.
• Never share extracted files. No assets, files or links to them, and don't ask for them: it's the server's rule. Hexa doesn't share them either.
• Findings are fine to discuss. Names, folder layouts, formats and codenames are what this tab collects.
• Leave unreleased titles and preloads alone. Hexa doesn't want them dumped and datamined. A preload only dumps if the console mounts it; otherwise OunceCake just errors out.
• Posting images may draw takedowns. Users relay that Nintendo has copyright-struck posts of datamined models and had such tweets DMCAed. Unverified.

Formats and tools#

Switch 2 games use Switch 1's format families, often in newer versions, so older tools may need an update. Many files are zstd-compressed, so decompress .zs files first.

What's been found#

• "Ounce" is the Switch 2's codename. Switch 1 games refer to it that way, and Pokopia keeps its data under KIDS_PLATFORM_OUNCE. Verified.
• "Spiral" is Splatoon Raiders' codename. Many of its file names carry it, and outside dataminers agree. Verified.
• A "banana" service in game metadata is a profiler. Zest spotted it in DK Bananza's NPDM. Two researchers identify it as the profiler service most apps carry. Verified.
• New Super Mario Bros. U Deluxe's Switch 2 update ships symbols. Abood found symbols in it, which Nintendo's releases usually strip. Unverified: one first-hand report.
• Legends Z-A's Switch 2 Edition is a placeholder. Its content is a dummy file, 0 bytes in size. Another user's dump also had a 0-byte DLC file, but it was missing many models and may not be the Switch 2 Edition. The first owner guesses the code changes are in the regular game binary. Unverified: one first-hand report.
• Mario Tennis Fever's RomFS is one big file. It's a single file named 42, about 8 GB. Unverified: one report.
• Mario Kart World 1.0.0 shows no DLC so far. It holds data for 16 cups, 8 Grand Prix and 8 survival, per a second-hand report. Unverified.
• Mario Kart World keeps much of its tuning in data tables, such as the frame each item can first appear. Unverified: one report.

Still debated#

Whether firmware comes out fully unencrypted is in Backing up your own games › Still debated.

Links and tools

Three sources are official: the ns2jb repo, the community guide and kurumuz's fork. Start with them. Everything else here is a community tool, a write-up or an account, and each one carries a trust label.

The three official sources#

All three are Official. Which build fits your console is in Prepare your console › Choose your build.

How to read the trust labels#

• Official: the three sources above, 90DNS, and maintainers' own posts, trackers and accounts.
• Verified: the docs plus one independent user, or two or more users, report it works as described.
• Unverified: one report or the author's word only, unreviewed code, or not released.

A label reports what people have seen, not that a file is safe. Download from the release pages linked here, not from re-uploads.

Blocking updates#

Setup is in Prepare your console › Stop updates with 90DNS.

Typers#

A typer types the bootstrap into SmileBASIC for you. The order matches Type the bootstrap, which has setup, trade-offs and known issues for each method.

Reliability patches#

After 4/4: homebrew and research tools#

The homebrew apps here run as GPU shaders inside SmileBASIC, not as native code; setup is in Run it › After 4/4. OunceCake and the firmware dumper instead use a full run's filesystem access; see Backing up your own games.

Tools that open dumped files, such as Switch Toolbox and vgmstream, are in Datamining › Formats and tools.

Write-ups and trackers#

Reddit and X#

Reddit#

r/switch2hacks collects tools and discussion. Its Flipper and plume-usb posts are under Typers.

X accounts#

Known fakes and untested files#

Skip everything here. None of it is a reviewed release, and some of it can harm your console or computer.

• The "NX2 CFW ACTIVATOR" is Refuted: it isn't a working tool. It's a GitHub "Switch 2 CFW activator" promoted on X on 23 Oct. Helpers call it fake, and moderators had already warned it's malware. Even its promoter lists red flags: a password-protected ZIP behind a redirect, advice to bypass your antivirus, and "firmware 18.0.1" support.
• The "ounce-core" Switch 2 emulator is Refuted: it doesn't work. A member who read the code calls it AI-generated, and others agree it isn't legit. Two users who inspected it found no malware.
• "WebKit route" files offered before an official release are fakes. Claims that the route is out are Refuted: it's still in testing as of 26 Oct; see Where the project stands › Other entry points.
• Modified ns2jb tarballs posted on Discord (one, another) are Unverified. Their origin is unknown, and they claim 70%+ success. kurumuz reports one "hangs my system constantly". Use kurumuz's fork instead.
• IZlauncher is Unverified. It was announced on 23 Oct with "source code dropping soon"; no code had appeared by 26 Oct. Its "kernel" follow-up most likely means the existing SmileBASIC softmod.
• A demo-tuned bootstrap posted on 24 Oct is Unverified. Its author says the FTP app runs on the demo, but GPU apps don't, and nobody else has confirmed it. The demo itself isn't supported.
• Unreleased builds: crueter's own fork wasn't public on 24 Oct. Neither were the modified runs from Metr1k and Zest. Treat anything offered under those names as unverified.
• New typers and apps are untested files, each Unverified with no user reports:
  • flipper2jb, a Flipper Zero typer
  • ezBasic, a Switch 1 .nro posted as an improved plume-usb
  • plume-usb 0.1.7, known only from a news article
  • PicoUSB_Switch2, a Pico typer its poster calls vibe-coded
  • the nxcontroller firmware for ESP32-S3 boards
  • NS2-Desktop, a desktop GUI for the exploit
  • an HBLauncher video player, shown only on X
  • input-noop.patch, a no-Pico HBLauncher patch shared only on Discord
• Files posted only on Discord are Unverified:
  • FP's HBLauncher zips, which failed on one Mac, and their replacement inspect-input.cjs
  • FP's "Payload Writer" Pico zip, and a Pico typer posted with no source
  • an AI-written Steam Deck script
  • the reduced bootstrap, which its author says "needs revalidation"
• Edited softmod code, AI-written or not. A helper warns against altering it in any way, since the code has unchecked write access.

Glossary

This tab explains each term the guide uses, A to Z, and links to the place where it's covered in full.

0–9#

• 23.0.1. The only system version ns2jb supports, with no downgrade. Still the newest as of 26 Oct; keep updates off. → Prepare your console › Check your versions
• 2811-1007. The eShop error that confirms your 90DNS block works. No other result does. → Prepare your console › Confirm the block
• 90DNS. Free DNS servers that block Nintendo's update servers, so you stay on 23.0.1. → Prepare your console › Stop updates with 90DNS

A–D#

• BFRES (.bfres). Nintendo's model and texture format. Switch 2 games use version 10, which the latest Switch Toolbox opens. → Datamining › Formats and tools
• BOOT FAILED N. A fail code, not a line number. Usually a typo; 58 means the console can't reach the host. → Troubleshooting
• Bootstrap (bootstrap.bas). The program of about 224 lines you type into SmileBASIC once. It starts every run. → Type the bootstrap › What you're typing
• BWAV. Nintendo's streamed-audio format, used for game music. vgmstream plays it. → Datamining › Formats and tools
• BYML. Nintendo's binary data format, for things like map placements and effects. → Datamining › Formats and tools
• CapsLock on USB Keyboard. A SmileBASIC setting. Turn it off so letters keep their case. → Type the bootstrap › Settings every method needs
• CFW (custom firmware). A permanent system replacement. ns2jb isn't one, and the "CFW activator" is fake. → Links and tools › Known fakes and untested files
• crueter's patches. Unverified host changes to retries, timeouts and the pairing code, for kurumuz's fork. → Links and tools › Reliability patches
• Demo. The free SmileBASIC 4 trial, version 4.4.6. It can't save the bootstrap or finish a run. → Get it running › Requirements
• Direct mode. SmileBASIC's command line, where you enter the run commands. Type the bootstrap in the editor instead. → Run it › Step by step
• Dumping. Copying your own games off the console, with OunceCake. → Backing up your own games

E–H#

• ESP32-S2/S3. Boards with native USB that can type the bootstrap. Plain ESP32s can't. → Type the bootstrap › ESP32-S2/S3
• Evidence labels. Verified, Unverified, Disputed, Refuted and Unknown say how well a claim is backed. Official marks first-party sources. → Start here › What's verified, what's claimed, what's refuted
• ExeFS / RomFS. A game's code (ExeFS) and its assets, such as models, music and text (RomFS). OunceCake dumps both. → Backing up your own games › What's been shown
• exFAT / FAT32. microSD card formats. exFAT offers the microSD update; FAT32 doesn't, and a Switch 1 formats cards of 32 GB or less as FAT32. → Prepare your console › If you want to use a card
• Firmware dumper. kurumuz's tool, in their fork, that saves your console's system-program code. → Backing up your own games › What's been shown
• Flipper Zero. A pocket multi-tool that types the bootstrap with a BadUSB script in 20–40 minutes. → Type the bootstrap › Flipper Zero
• Freeze. Auto-update off plus 90DNS on every saved network, so nothing moves you off 23.0.1. → Prepare your console › Stop updates with 90DNS
• FS execution verified. The host's message when the stage-4 demo succeeds. It's the only sign of success. → Run it › Reading the stages
• ftpd-sb. An FTP server for SmileBASIC's own files. Its writes change real files. → Run it › After 4/4
• HBLauncher. A launcher for shader apps. It skips the filesystem stage, so it starts more reliably but has no file access. → Run it › After 4/4
• Held RPC. mac2jb's default run mode. It keeps the connection open after 4/4, for homebrew or OunceCake. → Type the bootstrap › Mac (mac2jb)
• Host (run.cjs). The program on your computer that drives a run: Node 22+, macOS or Linux (WSL with extra setup), port 39380. → Run it › Start the host

I–M#

• Kext (usbgadget.kext). The macOS driver mac2jb uses. It's unsigned, so the Mac's SIP and startup security must permit it. → Type the bootstrap › The SIP trade-off
• kurumuz's fork. ns2jb that handles both memory layouts and retries more. The guide recommends it. → Prepare your console › Choose your build
• Live USB. Linux booted from a USB stick, to run the host without installing it. → Run it › Live USB
• LOAD, RUN, REMOVE. The Direct-mode lines that start the bootstrap. "Out of memory" after REMOVE is expected. → Run it › Step by step
• m1mu2. A research workbench that probes memory in a running session. → Links and tools › After 4/4: homebrew and research tools
• mac2jb. Makes an Apple Silicon Mac a USB keyboard that types the bootstrap and runs the host. v0.4.3 can also load homebrew and OunceCake after a run, and needs its own bundled bootstrap. → Type the bootstrap › Mac (mac2jb)
• Make a Program. The SmileBASIC editor you type the bootstrap into. → Type the bootstrap › What you're typing
• Memory layout (A)/(B). Item 3 in System Settings → Support/Health & Safety. (B) means the microSD update is installed. → Prepare your console › microSD and your layout
• microSD update. The first card used installs the newest firmware. Used a card? You've probably had it; use kurumuz's fork. → Prepare your console › microSD and your layout

N–R#

• NCA4. Switch 2's encrypted package format, a newer version of Switch 1's NCA. Nobody can decrypt one off the console. → Datamining › Formats and tools
• NS2. The name you save the bootstrap under, in slot 0. The full game keeps it. → Type the bootstrap › What you're typing
• ns2jb. The softmod, by pepsipu: a SmileBASIC bootstrap plus a host. → Start here
• ns2jb-guide. The community setup guide, by fuyuka-group. → Links and tools › The three official sources
• nxhid. Makes a modded Switch 1 a Wi-Fi-controlled keyboard. Use the jgallardst fork. → Type the bootstrap › Modded Switch 1
• OunceCake. Hexa's tool, formerly PoundCake, for backing up your own games over a read-only FTP server. → Backing up your own games › Running OunceCake
• Pairing values. The one-time numbers in the original release's V=START line; kurumuz's fork drops them. Redact them before posting a log. → Troubleshooting › Still stuck?
• Pico (RP2040/RP2350). A cheap microcontroller that types the bootstrap with pico-smilebasic-autotyper. → Type the bootstrap › Raspberry Pi Pico (RP2040)
• plume-usb. Switch 1 homebrew that types a text file into the Switch 2. → Type the bootstrap › Modded Switch 1
• Retry routine. After a failed run, restart the console before trying again, as the README says. Whether every attempt needs it is Disputed. → Run it › Retry routine
• RPC. The host-to-console link once the bootstrap runs. "RPC working" isn't success. The fork's --rpc keeps it open after 4/4, for OunceCake. → Run it › Reading the stages
• Rubber Ducky. A USB stick that types preset keystrokes. One payload exists, unreviewed. → Type the bootstrap › Other devices

S–Z#

• SARC. Nintendo's archive format. .msarc text archives are SARCs. → Datamining › Formats and tools
• Shader app. A program that runs as GPU shaders inside SmileBASIC, like Celeste-Classic-NS2. All homebrew so far is this kind. → Where the project stands › What it can reach
• SIP (System Integrity Protection). A macOS safeguard that mac2jb's driver needs lowered. A real trade-off: re-enabling it afterwards isn't verified to keep the driver working. → Type the bootstrap › The SIP trade-off
• SmileBASIC 4 (SB4). The programming game the softmod runs in; you need 4.4.9. It's delisted, but past purchases re-download. → Get it running › Requirements
• Softmod. A mod that runs from memory and changes nothing permanent. → Start here
• Stages 1/4–4/4. The host's progress: check, acquire memory, start the helper, run the demo. Runs usually stall at 2 or 3. → Run it › Reading the stages
• Supernag. A lock on the console's web applets, which then show "This feature is not available". It doesn't affect the SmileBASIC route. → Prepare your console › The supernag
• switch-script-keyboard. A rooted-Android app that types the bootstrap over USB. → Type the bootstrap › Rooted Android
• Tethered. Nothing survives a reboot, so you redo the run each time. "Untethered" claims so far cover only leaving the app. → Where the project stands › Persistence
• Typer. Any device or app that types the bootstrap for you. → Type the bootstrap › Choose a method
• Upstream. pepsipu's original ns2jb, built for consoles without the microSD update. → Prepare your console › Choose your build
• USB keyboard layout. Set the Switch's to English (US), or symbols come out wrong. → Type the bootstrap › Settings every method needs
• Userland. The unprivileged level of the system. ns2jb reaches it, not the kernel. → Where the project stands › What it can reach
• V=START(…). The line the host prints with your computer's address. Type it in Direct mode. kurumuz's fork also prints a ,0,0,0,0 line for an NS2 typed from the original. → Run it › Step by step
• WebKit route. pepsipu's entry point through the console's browser. In testing, not released as of 26 Oct. → Where the project stands › Other entry points
• WSL. Windows Subsystem for Linux. Several users now reach 4/4 with it, using mirrored networking and Hyper-V firewall rules. → Run it › Windows and WSL
• zstd (.zs, .zst). The compression on many game files. Decompress them with zstd first. → Datamining › Formats and tools