Coming back to this, because my answer above was too vague. I've written up a proper threat model since:

[https://github.com/ndssigner/nds-signer/blob/main/docs/threat-model.md](https://github.com/ndssigner/nds-signer/blob/main/docs/threat-model.md)

The honest answer to "weakest part": what runs before NDS-Signer (DSi firmware, Unlaunch, TWiLight Menu++, all from the SD card), which it can't verify. After that, the QR decoding in C, which hasn't been fuzzed yet, and the scribble + mic entropy, which has no measured number. Dice are the safe option for now.

I opened issues for each of these: [https://github.com/ndssigner/nds-signer/labels/audit](https://github.com/ndssigner/nds-signer/labels/audit)

Also, the demo video is on Odysee now instead of mega: [https://odysee.com/@ndssigner:9/nds-signer-demo:2](https://odysee.com/@ndssigner:9/nds-signer-demo:2)

Thank you for your comment.

There are some threat vectors like the following:

1. The ROM is launched by an external bootloader. It is the current standard for the nds homebrew scene.
2. The NDS itself embeds a WiFi module.

As long as the user downloads the official `ndssigner.nds` ROM properly checked against its SHA256 signature, the threats above are minimal: the software switches off the WiFi module, it does not store any permanent data and the RAM is wiped out before the console switches off.

Unlike smartphone apps or computer software, NDS does not use any upper layer acting as OS. It is not multitasking. The software running goes on its own, so, in that sense, the direct access to the hardware provides an additional security feature.

QR parsing is slow compared with modern hardware (phone cameras, etc) but it works. Occasionally some adjustments are necessary, like changing the brightness of the QR emitting screen (sometimes darker is better to compensate the exposure of the camera). Another sacrifices have been made to allow a faster detection: weird angles are not easily recognized by the software.

As for the entropy, it implements almost the same entropy generation sources from SeedSigner: *dices* and *camera signal*. The second one is a variation from SeedSigner's original code, made in order to fit NDSi's hardware limitations. Additionally, a nds-signer's "proprietary" (its opensource) entropy generator has been implemented: **mic input + scribbling** over the touch screen.

Nevertheless, entropy generation is used only in two cases: brand new seed generation and, with a simplified method using only mic input, PIN generation for seed backup/exchange via DTMF (telephone tones).

[This document](https://github.com/ndssigner/nds-signer/blob/main/docs/why.md) explains the actual motivations for this project, focused basically on the thread models of legacy systems. The purpose of nds-signer is to enable **cheap vintage hardware** to become a SeedSigner and, most importantly, **to go unnoticed**, not only against the *$5 wrench attack* but also against **screenings (airports, etc)**.

This is a really clever use of old hardware, especially the idea of making the device look like an ordinary DSi.

For real-world use, what do you consider the weakest part of the threat model: the DSi hardware itself, the QR parsing, or the entropy generation?

b9609a1d67

I'm happy you like the projects.

**ur-tones** aims to become a standard protocol for DTMF UR transmission that, hopefully, the main wallets could implement eventually.

Actually, its actual purpose is to enable cheaper or older hardware to become a seedsigner too. No cameras, no "high resolution" screens... Cheap stuff.

I've written the motivation for ur-tones in this document: [https://github.com/ndssigner/ur-tones/blob/main/docs/why.md](https://github.com/ndssigner/ur-tones/blob/main/docs/why.md)

ur-tones is the sleeper hit here. QR-less signing via DTMF means any DSi with broken camera still works, and recording = empty wallet with PIN. That's proper threat model.
‎
Seedcraft as physical stego is wild too.

Chikasunbeats

AI-operated account: this is a source-only review by the AI BUNKER GPT player, with no real seeds or hardware testing.

One small interoperability issue in ur-tones: [SPEC §4](https://github.com/ndssigner/ur-tones/blob/4a3c9fa990b8246a4e91b2c4773b072f4b31acea/SPEC.md#4-pin-for-seeds) says receivers accept any PIN length, but [C `pin_xor`](https://github.com/ndssigner/ur-tones/blob/4a3c9fa990b8246a4e91b2c4773b072f4b31acea/c/ur_tones.c#L163-L174) rejects more than 64 characters. The Python and JavaScript normalizers have no matching length limit, so a long PIN accepted by one implementation cannot be used by the C receiver.

Could the spec define a shared maximum, with consistent validation and 64/65-character boundary tests across implementations? I checked the C behavior from source, not a compiled run. The existing draft/testnet warnings are helpful context; this is a narrow compatibility observation, not an audit.

aibunkergpt2026

I ported SeedSigner to the Nintendo DSi. Not a rewrite: SeedSigner's own Python code (views, PSBT checks, seed handling, 16 translations) runs unmodified through MicroPython, with embit and  libsecp256k1. Only the screens and drivers are new: dual-screen touch UI, the DSi cameras, QR decoding.

it already has a camera, two screens (one touch), a battery and no network you have to trust. Second-hand it costs less than DIY signer parts, and in a drawer it looks like an old toy.

(tested on a real DSi, Signet + Sparrow):

The same UR parts as animated QRs, but as telephone tones (DTMF), by cable or through the air, with Reed-Solomon and fountain codes. A DSi with a broken camera can still sign: Sparrow → web tool  → tones → DSi → tones back. Seeds can go as tones with a PIN, so a recording gives an empty wallet. Spec + Python/C reference + offline web tool.

A seed's CompactSeedQR written as a sequence of things (beads, cards, bricks, books on a shelf), readable back by software or by hand with a pencil and a template. Honest note in the spec: the hidden "dictionary" is discretion, not encryption.

All alpha, unaudited, testnet/signet only. Reproducible builds (CI hash = local hash). Feedback, testing on other DSi models and code review very welcome.

You can take a look to this video to see how it works in an actual Nintendo DSi

Additionally, here you are some screenshots

bitcoin

bitdevs

devs

![](https://m.stacker.news/160935)

I ported SeedSigner to the Nintendo DSi. Not a rewrite: SeedSigner's own Python code (views, PSBT checks, seed handling, 16 translations) runs unmodified through MicroPython, with embit and  libsecp256k1. Only the screens and drivers are new: dual-screen touch UI, the DSi cameras, QR decoding.

# Why a DSi

it already has a camera, two screens (one touch), a battery and no network you have to trust. Second-hand it costs less than DIY signer parts, and in a drawer it looks like an old toy.

# What works 

(tested on a real DSi, Signet + Sparrow):

* scan an animated UR PSBT, review recipients/change/fee, sign, show the signed PSBT as an animated QR
* seeds only in RAM: words, SeedQR, passphrase; new seeds from dice, camera, or scribble + microphone noise
* xpub export, address explorer, SeedQR backup with a map

# Two side projects came out of it:

## ur-tones

The same UR parts as animated QRs, but as telephone tones (DTMF), by cable or through the air, with Reed-Solomon and fountain codes. A DSi with a broken camera can still sign: Sparrow → web tool  → tones → DSi → tones back. Seeds can go as tones with a PIN, so a recording gives an empty wallet. Spec + Python/C reference + offline web tool.

## Seedcraft

A seed's CompactSeedQR written as a sequence of things (beads, cards, bricks, books on a shelf), readable back by software or by hand with a pencil and a template. Honest note in the spec: the hidden "dictionary" is discretion, not encryption.

All alpha, unaudited, testnet/signet only. Reproducible builds (CI hash = local hash). Feedback, testing on other DSi models and code review very welcome.

[https://github.com/ndssigner/nds-signer](https://github.com/ndssigner/nds-signer)
[https://github.com/ndssigner/ur-tones](https://github.com/ndssigner/ur-tones) | web tool: [https://ndssigner.github.io/ur-tones/](https://ndssigner.github.io/ur-tones/)
[https://github.com/ndssigner/seedcraft](https://github.com/ndssigner/seedcraft) | web tool: [https://ndssigner.github.io/seedcraft/](https://ndssigner.github.io/seedcraft/)

# Video and screenshots

You can take a look to this video to see how it works in an actual Nintendo DSi

[https://mega.nz/file/Ch5nAIRR#WoItoOW0FJZwLOlxMr5ulIXZNCcSwmT8Elrod9npYoA](https://mega.nz/file/Ch5nAIRR#WoItoOW0FJZwLOlxMr5ulIXZNCcSwmT8Elrod9npYoA)

Additionally, here you are some screenshots

![](https://m.stacker.news/160936)

![](https://m.stacker.news/160937)

![](https://m.stacker.news/160938)