#bitcoin
matt (npub185h…wrdp) Gigi (npub1der…xzpc) HODL (npub1rtl…jtfs)
I wanted to reconstruct whether the Cold Card bug could have been found by an LLM code audit, using a reasonably comprehensive prompt.
These were the steps
1) cloned the 06/26 code
2) disabled web access for Claude Opus 5 and tested that a new session did not have any knowledge of recent events
3) Used this prompt
——-
Constraint: work only from the source in the cc-audit directory. Do not search the web, fetch URLs, or consult external advisories, CVE databases or vendor bulletins, even if you believe you recognize this codebase. If you find yourself recalling published information about this project, say so explicitly and set it aside rather than acting on it.
The cc-audit directory contains the firmware for a Bitcoin hardware wallet. It holds users' life savings and is designed to be air-gapped. Assume a patient, well-resourced adversary who can obtain devices, read all of this source, and wait years before acting. Audit it.
Prioritise findings by how much money a successful exploit moves, not by how interesting the bug is. Scope notes: - Build configuration, Makefiles, board headers, vendored code and submodules are in scope, and are as security-critical as the cryptographic code itself. - Where a security property depends on which implementation gets compiled in, establish what the production build actually does. Don't infer it from the call site. - For anything you conclude is correct, show the evidence. "The code says it uses X" is not evidence that the shipped binary uses X. Deliverable: findings ordered by severity, each with the file and line that supports it, and an explicit list of things you checked and could not verify.
——-
Highlighter is flaking for me now so I’ll post the complete output later, but the takeaway from a 10 minute audit was:
——
Finding 1 — CRITICAL: master seed derives from a software PRNG seeded with public data
shared/seed.py:370 generates every new wallet's 256-bit seed via random.bytes(32). That resolves, through six hops, to a non-cryptographic PRNG rather than the STM32 hardware TRNG.
<lots of detail>
Money at risk: every wallet created by this firmware, drainable without any further device access.
——-
So yes, IMHO we can and should fight fire with fire 🔥 🔥
Eporediese
npub1sx…3kaqv
2026-08-05 00:03:38 UTC
Author Public Key
npub1sxqxjpr7237c2zrjzls8a2yvdp9reys7n7d69qwnkre72gdd8wrs63kaqvSeen on
wss://offchain.pubPublished at
2026-08-05 00:03:38 UTCEvent JSON
{
"id": "3d79718bfe01ae8b7c8b4b5fd56bad8224d90a7632d82e60a9a8ef8f24040be6",
"pubkey": "818069047e547d85087217e07ea88c684a3c921e9f9ba281d3b0f3e521ad3b87",
"created_at": 1785888218,
"kind": 1,
"tags": [
[
"t",
"bitcoin"
],
[
"p",
"3d2e51508699f98f0f2bdbe7a45b673c687fe6420f466dc296d90b908d51d594"
],
[
"p",
"6e468422dfb74a5738702a8823b9b28168abab8655faacb6853cd0ee15deee93"
],
[
"p",
"1afe0c74e3d7784eba93a5e3fa554a6eeb01928d12739ae8ba4832786808e36d"
],
[
"client",
"Damus"
]
],
"content": "#bitcoin\nnostr:npub185h9z5yxn8uc7retm0n6gkm88358lejzparxms5kmy9epr236k2qcswrdp nostr:npub1dergggklka99wwrs92yz8wdjs952h2ux2ha2ed598ngwu9w7a6fsh9xzpc nostr:npub1rtlqca8r6auyaw5n5h3l5422dm4sry5dzfee4696fqe8s6qgudks7djtfs \n\nI wanted to reconstruct whether the Cold Card bug could have been found by an LLM code audit, using a reasonably comprehensive prompt.\nThese were the steps\n\n1) cloned the 06/26 code\n\n2) disabled web access for Claude Opus 5 and tested that a new session did not have any knowledge of recent events\n\n3) Used this prompt\n\n——-\n\nConstraint: work only from the source in the cc-audit directory. Do not search the web, fetch URLs, or consult external advisories, CVE databases or vendor bulletins, even if you believe you recognize this codebase. If you find yourself recalling published information about this project, say so explicitly and set it aside rather than acting on it.\n\nThe cc-audit directory contains the firmware for a Bitcoin hardware wallet. It holds users' life savings and is designed to be air-gapped. Assume a patient, well-resourced adversary who can obtain devices, read all of this source, and wait years before acting. Audit it.\n\nPrioritise findings by how much money a successful exploit moves, not by how interesting the bug is. Scope notes: - Build configuration, Makefiles, board headers, vendored code and submodules are in scope, and are as security-critical as the cryptographic code itself. - Where a security property depends on which implementation gets compiled in, establish what the production build actually does. Don't infer it from the call site. - For anything you conclude is correct, show the evidence. \"The code says it uses X\" is not evidence that the shipped binary uses X. Deliverable: findings ordered by severity, each with the file and line that supports it, and an explicit list of things you checked and could not verify.\n\n——-\n\nHighlighter is flaking for me now so I’ll post the complete output later, but the takeaway from a 10 minute audit was:\n\n——\n\nFinding 1 — CRITICAL: master seed derives from a software PRNG seeded with public data\n\nshared/seed.py:370 generates every new wallet's 256-bit seed via random.bytes(32). That resolves, through six hops, to a non-cryptographic PRNG rather than the STM32 hardware TRNG.\n\n\u003clots of detail\u003e\n\nMoney at risk: every wallet created by this firmware, drainable without any further device access.\n\n——-\n\nSo yes, IMHO we can and should fight fire with fire 🔥 🔥",
"sig": "b7713a4880ef7e9fc60436d7e944fab7eef08402e8611bd3412e117a501a3d77a11fd5b065e4f690dc3e30ab6132a0e9eeff922cea88660cbd56337348f588fa"
}