You called ur-tones the sleeper hit. It now has a real signer built around it: #1607417

Follow-up to your question: if a DSi is hard to find, I built another answer, a signer you put together from a Raspberry Pi Pico and a few parts for about $13. #1607417

A couple of days later than I said, sorry: your fuzzing suggestion is in v0.2.2-alpha. tests/fuzz has libFuzzer + ASan/UBSan harnesses for the whole image path, quirc_decode and the QR type detection, with quirc built exactly as the ROM builds it. In its first seconds it found undefined behaviour in quirc (nothing out of bounds), now fixed. After that, 30 minutes per harness came back clean. The image harness is slow, so longer runs are welcome: make -C tests/fuzz run.

Thanks again for the review.

https://github.com/ndssigner/nds-signer/releases/tag/v0.2.2-alpha

Update: the fixes for your notes shipped in v0.2.2-alpha.

• ARM9 stack: on lid close the wipe now switches to a small stack of its own and clears the app thread’s whole 128 KB stack, where all the key-handling C code runs. Checked over GDB in melonDS (6,841 non-zero bytes before, none after) and on a real DSi XL.
• secureZero clears any length and alignment now.
• Microphone: SP 800-90B’s Repetition Count and Adaptive Proportion tests run in C on every buffer, and only buffers that pass count towards Done. Dropped buffers are counted and documented.

One finding from testing on the console: a covered microphone passes the health tests (the amplifier’s own noise), which is exactly why the ea_non_iid figure still matters. That one stays open in #8.

https://github.com/ndssigner/nds-signer/releases/tag/v0.2.2-alpha

LOL. I think that for them it is worth purchasing hundreds of SIM cards from countries like Nigeria or similar. The ROI makes worth the effort.

Thanks, these are good catches, especially the stack one. The heap wipe on boot shipped yesterday in v0.2.1-alpha, but nothing clears the ARM9 stack yet, so C locals that touched key material can survive. I’ve put your notes where they’ll get worked on:

• Health tests (RCT/APT) and the dropped buffers: ndssigner/nds-signer#8
• The ARM9 stack and the secureZero word-length nit: ndssigner/nds-signer#12

And agreed on the entropy number: dumping raw buffers and running ea_non_iid is the plan, it’s long overdue

Yes ideed. The problem is that I have not telegram yet. This is a different problem, but I want to keep my identity hidden for bitcoin related projects, and TG requieres a phone number to register. I've been trying services like SMSPool to get a temporary registration code but I haven't been lucky. I will keep trying anyway.

Thank you very much for your review It provides an additional layer of reliability on this project. I think that, seen what we have witnessed recently with all the attacks on hardware wallets, we should be as paranoid and as strict on auditing security and integrity as we can. I will work on your suggestions probably by the next weekend. Again, thank you very much for your review <3

Thank you! I am not a gamer at all, but I still remember how cool it was when the firsts models of NDS were released. Unfortunately, I suck playing super mario.

These devices can be easily obtained at second hand platforms like FB marketplace at very decent prices, around 50 +/- 20 USD. They use to be in quite good conditions.

The device itself has a proprietary charging connector, but it is also easy to find USB adapters to charge from any standard USB-A charger. No data involved.

It actually comes with two cameras: a rear one on the lid and a front one on the hinge.

As for the japanese model, I think (i am not 100% sure) that the only that changes is the name and probably some regional restriction for legitimate game cartridges, but the exploit that allows running homebrew software (like nds-signer) seems to work.

The only device I have testes is my second hand NDSi XL, so tests in different devices are welcome :-)

Thanks, good to see you here again! One small correction that actually makes the point stronger: the DSi DOES have WiFi, but NDS-Signer never links the driver and switches the radio off at boot, so the “no wifi” is enforced in the code, not assumed. that’s in the threat model: https://github.com/ndssigner/nds-signer/blob/main/docs/threat-model.md

If anything in it looks weak to you, the open questions are issues now: https://github.com/ndssigner/nds-signer/labels/audit

Actually, https://github.com/ndssigner/nds-signer/releases/tag/v0.2.1-alpha is out today with a start-up memory wipe that came from this kind of feedback! <3

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

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

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

Sooner or later all bitcoin users need to be aware that some "targeted" devices are prone to supply chain attacks, and hardware wallets are, of course, such kind of devices to be aware of.

The first time I got really obsessed with the possibility of supply chain tampering was during the 2024 Lebanon electronic device attacks. Thankfully I am not involved at all with such events, but when I saw on the news what actually happened I really freaked out.

And it isn't only the tampering risk that should scare us, but also the possibility to be flagged during screenings. Current AI technology is very capable of spotting well known hardware. Just imagine when X-ray scanners at the airport become able to detect your tiny Trezor inside your luggage.

That's one of the reasons that made me begin this project: nds-signer – A #NintendoDSi software implementing #SeedSigner.

https://github.com/ndssigner/nds-signer/

My main obsession is to go unnoticed and reuse multipurpose hardware to avoid problems like the one we are witnessing.

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 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).

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