Glonce

Coldcard's weak-entropy bug traced to a commit message reading 'runs'

securityThe Glonce editorsHacker News🔥60Glonce rating60Impact70Novelty50Relevance60Surprise58Players38Credibility78
Coldcard's weak-entropy bug traced to a commit message reading 'runs'

A guest post published on the btcpp.dev Insider newsletter, written by Core-Lightning developer ddustin, walks through the git commit history of the Coldcard hardware wallet firmware to explain how a recent low-entropy bug happened. The author starts from a general principle: a good commit has a high ratio of commit-message length to lines of code changed, since more code touched should mean more explanation of why. As a baseline, ddustin cites one of his own commits: a 235-character message for a 15-line change, a ratio of about 16. Against that baseline, the commit that introduced the Coldcard bug carries a five-character message, the single word "runs," for a change spanning 1,534 lines of code, a ratio of about 0.003. A second commit, contributing to the same issue, has a one-character message, "x," for roughly 1,000 changed lines, a ratio of about 0.001. Neither commit is named or dated in the source, and the developer behind them is not identified.

Inside the "runs" commit, ddustin finds the line #define MICROPY_HW_ENABLE_RNG (0), which tells the MicroPython layer running on Coldcard's STM32 chip not to use the hardware random number generator and to fall back to the Yasmarang RNG instead. The inline comment attached to the change reads only "// We have our own version of this code." Reconstructing the intent, ddustin argues the developer was trying to override the STM32 library's pyb_rng_get_obj function with a custom version in a new rng.c file, but the STM32 library already defines that same symbol, which C does not allow to be defined twice; the result would have been a "duplicate symbol" compiler error. Disabling the hardware RNG removed the STM32 library's original definition of rng.c lines 31 to 80, which happened to also remove the conflicting definition and let the code compile, masking the real problem instead of fixing it.

The consequence is a confusing call chain: Coldcard's application layer is written in Python, calling into C. In firmware v4.0.0, the wallet-creation function make_new_wallet() calls random.bytes(32) to generate a new seed. That call does not go through the pyb_rng_get path the developer had overridden; it instead reaches a separate rng_get() function, which, with the hardware RNG disabled, calls pyb_rng_yasmarang(), the weak, non-hardware entropy source. So the override the developer wrote had no effect on wallet generation at all; the side effect of disabling the hardware RNG, which ddustin infers was meant to silence a compiler error, is what actually weakened new seeds. ddustin closes with a direct appeal to developers working on Bitcoin software: understand every line you ship, especially in code touching random number generation, and do not let a masked compiler error stand in for understanding why code works.

Key facts

  • A guest post by Core-Lightning developer ddustin reconstructs the Coldcard firmware commit history behind its recent weak-entropy bug.
  • The commit that introduced the bug carries a five-character message, "runs," for a 1,534-line change, a comment-to-code ratio of about 0.003, versus about 16 in the author's own baseline example.
  • A second commit, message "x," changed about 1,000 lines (ratio about 0.001) and also contributed to the issue.
  • The commit set MICROPY_HW_ENABLE_RNG to 0, which the author infers was meant to silence a duplicate-symbol compiler error, disabling the STM32 hardware RNG as a side effect.
  • In firmware v4.0.0, make_new_wallet() calls random.bytes(32), which bypasses the developer's intended override and instead falls through to the weak Yasmarang RNG.

Why it matters

The post is a concrete case study of how a masked compiler error, not a deliberate design choice, can silently weaken the random number generation behind a hardware wallet's seed creation, the single most security-critical operation the device performs.

Who it affects

Coldcard users who generated a new wallet or seed on firmware v4.0.0 during the period the hardware RNG was disabled, and more broadly developers and reviewers working on Bitcoin firmware and other code paths that depend on true hardware entropy.

How to use it

The source offers no product to use; its practical takeaway is procedural: keep a high ratio of commit-message length to lines changed, treat any code touching random-number generation as requiring stricter review, and never let a compiler error be silenced by an unrelated configuration flip without understanding why it worked.

How solid is it

The account rests on one guest author's reading of the Coldcard git history and macro expansions, published as a single newsletter post; the source names one specific commit hash for a related custom rng.c file but not for the "runs" commit itself, and it references no statement from Coldcard's maker, Coinkite.

Risks and caveats

The developer who authored the "runs" and "x" commits is not named, no dates are given for when the commits were made or the bug discovered, and the source does not state how many devices or how much in funds were affected.

“Do not ship code you do not understand.”

— ddustin, Core-Lightning developer and author of the post