When random.bytes() runs but doesn't work - by Dusty Daemon
SubscribeSign in
OpEd<br>When random.bytes() runs but doesn't work<br>What a commit message tells us about the recent COLDCARD bug
Dusty Daemon<br>Aug 01, 2026
21
Share
This is a guest post from noted Core-Lightning developer, ddustin, who dug into the Coldcard firmware commit history to uncover what happened and why the code failed.<br>Intro
I began investigating the Coldcard hack and was immediately shocked. I need to explain why.<br>When we developers work on code, we organize or code changes into changesets we call “commits.” The purpose of doing so is to show a clear history of what code was changed including why and how.
This is done precisely for instances like this where it appears Bitcoiner’s funds are being stolen en masse, so we can investigate and understand exactly how it could happen.<br>Good developers write clear commit messages, written notes that go along with the code changes that explain what the specific change is accomplishing.<br>To make a clear commit message, you typically want to the commit to represent a smaller change of code, so there’s less to comment on.<br>A good goal as a developer is a high commit message to change ratio. The more lines of code that you change, the more comments explaining why you’re changing the code. More message and less code changes per commit is generally a good idea.<br>Here is an example chosen randomly from some of my own work.<br>The commit message is 235 characters, and the commit changes 15 lines of code. That’s a ratio of 235/15 = ~16.<br>In the cold card, the commit that introduced the low entropy bug is here.<br>The commit message is 5 characters and is simply the word “runs.” The commit changes 1534 lines of code making the ratio 5/1534 = ~0.003<br>This is an atrociously bad comment to code change ratio.<br>There are some rare instances where a low comment ratio is justifiable -- but changing the most important part of the code is not one of those cases!<br>Code that touches functions critical to the security of the project need to have a higher ratio of comments to changes and more stringent review.<br>The second commit contributing to the weak entropy issue on Coldcards is here.<br>The commit message is 1 character: simply the character “x.” The commit changes ~1000 lines of code making the ratio 1/1000 = ~0.001<br>The Issue
In the commit titled “runs” (ratio: ~0.003), it appears they are importing and configuring C code to make custom micropython code work on the STM32, the board that all Coldcards run on.<br>STM32 is the most common CPU for small devices like this, and configurations like what this commit introduces are common.<br>In the ‘runs’ commit, the hardware RNG (Random Number Generation) was disabled with the following line of code.<br>#define MICROPY_HW_ENABLE_RNG (0)<br>This is what caused the bug. Setting this value to zero tells the default micropython rng code to not use the hardware RNG device and that it should use the Yasmarang RNG instead.<br>The developer added an inline comment “explaining” this change<br>// We have our own version of this code.<br>The COLDCARD version of this code appears to be in reference to the functions added in rng.h and rng.c<br>rng.h<br>MP_DECLARE_CONST_FUN_OBJ_0(pyb_rng_get_obj);<br>MP_DECLARE_CONST_FUN_OBJ_1(pyb_rng_get_bytes_obj);<br>These appear to be an attempt to override the stm32 rng library’s `pyb_rng_getobj` function. This approach ran into trouble. The stm32 rng.c file already defines the pyb_rng_et_obj variable and sets the value to `pyb_mg_get`. You can’t have two definitions of the same variable and have it compile.<br>rng.c<br>MP_DEFINE_CONST_FUN_OBJ_0(pyb_rng_get_obj, pyb_rng_get);<br>Expanding the macro and thinking of it logically is just this pseudocode:<br>var pyb_rng_get_obj = pyb_rng_get<br>Commit `37e4af5` adds a custom rng.c file, where he copy pasted the same macro definition<br>MP_DEFINE_CONST_FUN_OBJ_0(pyb_rng_get_obj, pyb_rng_get);<br>There is now no way for this code to compile. It appears that the developer is naively trying to override the `pyb_rng_get_obj` variable by creating a duplicate version of the variable. C does not work this way. This error would have given him a compiler error of “duplicate symbol pyb_rng_get_obj, because there are now two places where it is defined: the stm32 library, and in the newly added rng.c file.<br>From here, I assume in a bout of frustration, he set `MICROPY_HW_ENABLE_RNG` to 0, which would have resolved the compiler error.<br>Sometimes when developers are flailing, they’ll try random things to see if it helps. Setting `MICROPY_HW_ENABLE_RNG to 0 would have made the compiler error go away ***for the wrong reason***.<br>This swept the compiler error of having two conflicting definitions under the rug.<br>// We have our own version of this code.<br>#define MICROPY_HW_ENABLE_RNG (0)<br>Setting MICROPY_HW_ENABLE_RNG to zero completely removed the code that used the hardware random number generator, or lines 31 to 80 in the stm32 rng.c file. This had the side effect of removing the...