2026-08-05 04:58:01 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： Coldcard硬件钱包因固件中一个写错五年的#ifndef宏定义缺陷，导致种子生成使用软件PRNG而非硬件TRNG，有效熵大幅降低至40-72位。攻击者离线枚举候选种子并比对链上UTXO，累计从4585个地址盗走约8860万美元BTC。用户应立即升级固件并迁移受影响钱包中的资产。 综合评分： 100 文章分类： 漏洞分析,应急响应,威胁情报,安全大事件,区块链安全

cover_image

黑客离线算出了 4585 个比特币钱包的助记词，并盗走价值 8800 万美元的数字货币，目前攻击还在持续！

原创

mmc mmc

AGI安全

2026年8月3日 09:58 北京

在小说阅读器读本章

去阅读

黑客离线算出了 4585 个比特币钱包的助记词，并盗走价值 8800 万美元的数字货币，目前攻击还在持续！

攻击者没有碰过任何一台设备，也没有拿到任何一份助记词备份——他在自己的机器上，把这些钱包的助记词算了出来。源头是 Coldcard 硬件钱包固件里一个写错了五年的 #ifndef：助记词种子生成用的从来不是硬件真随机数，而是一个确定性软件 PRNG。

从「构建配置」到「链上清空」· 事件示意构建期集成错误#ifndef 只查「定义」不查「值」种子来自软件 PRNG而非 STM32 硬件 TRNG有效熵 128bit → 40 / 72bit离线枚举 + 链上比对算候选种子 → 推地址 → 查 UTXO首波 41 分钟 · 累计 4,585 个地址全程无需接触设备：这是一次纯粹「算出来的」盗窃攻击事件

导语

硬件钱包被认为是加密资产托管的安全底线：私钥不出设备、离线签名、物理隔离。这套模型的前提，是设备生成的助记词是真随机数。

2026 年 7 月 30 日 UTC 01:10 到 01:51 之间，攻击者用 6 个区块的时间清空了 1,196 个比特币地址，合计 1,082.65 BTC，按当时价格约 7,020 万美元。Galaxy Research 追踪链上资金流向后，把源头指向加拿大厂商 Coinkite 的比特币专用硬件钱包 Coldcard——一个 2021 年 3 月引入、藏了五年多的固件集成缺陷，让种子生成用上了软件伪随机数生成器（PRNG），而不是 STM32 芯片内置的硬件随机数发生器（TRNG）。

截至 8 月 2 日，Galaxy 已识别出三波清扫，涉及 4,585 个地址、1,367.05 BTC，约 8,860 万美元。这篇文章梳理这个 bug 到底是怎么发生的、为什么所有防线都没拦住它，以及对做嵌入式和密码学工程的人来说，值得思考记的一些问题。

事件速览

弱随机数种子可离线枚举升级固件不修复旧种子构建期静默降级

事件时间线

2018 年 5 月 —— MicroPython 上游引入 Yasmarang 软件 PRNG 作为无硬件 RNG 时的兜底实现。此时与 Coldcard 无关。

2021 年 1 月 28 日 —— libngu 中那段有问题的 STM32 守卫代码已经存在。

2021 年 3 月 1 日 —— 提交 b18723dd 把种子生成从 ckcc.rng_bytes() 改为 ngu.random.bytes()。这一行改动，是整个事件的起点。

2021 年 3 月 17 日 —— 固件 v4.0.0 发布，带着这条路径进入生产。

2022 年 3 月 11 日 —— 提交 01cb43f7 为 Mk4 加入开机重播种（reseed），但只注入了 32 bit。

2026 年 7 月 30 日 01:10 UTC —— 首波攻击清扫开始，41 分钟结束。

2026 年 7 月 30 日 —— Block 的比特币工程与安全团队看到用户损失报告后介入，独立定位到根因并通报 Coinkite；Coinkite 发布针对 Mk3 的初步通告。

2026 年 7 月 31 日 —— Coinkite 为所有受影响型号推送紧急固件；第二波、第三波清扫同期发生。

2026 年 8 月 2 日 —— Galaxy Research 把观测规模上调到 4,585 个地址、1,367.05 BTC。

注意首波清扫发生在 Coinkite 公开披露之前约 30 小时。也就是说，攻击者是在厂商知情之前就完成了准备和执行。

根因：`#ifndef` 只检查「有没有定义」，不检查「值是多少」

这个 bug 的形态非常经典，也非常容易在任何一个 C 项目里复现。

Coldcard 自己写了一套硬件 TRNG 的封装，暴露给 Python 层的接口是 ckcc.rng_bytes。既然有了自己的实现，开发者就在板级配置里把 MicroPython 自带的 RNG 关掉：

`// stm32/COLDCARD/mpconfigboard.h

define MICROPYHWENABLE_RNG (0) // We have our own version of this code.`

问题出在 libngu 这一侧。它想确保底层有真随机源，于是加了一道守卫：

`// external/libngu —— 本意是「没有硬件 TRNG 就编译报错」

ifndef MICROPYHWENABLE_RNG

#error “get a HW TRNG plz”

endif`

#ifndef 判断的是宏「是否被定义」，不是「值是否为真」。宏被定义成了 0，所以 #error 没有触发，构建顺利通过，CHIP_TRNG_32() 解析到了 MicroPython 的 rng_get()。

而 MicroPython 那边用的是 #if MICROPY_HW_ENABLE_RNG——值为 0，于是它编译的是 Yasmarang 软件兜底分支，而不是 STM32 硬件外设。

两个判断，一个用 #ifndef，一个用 #if，方向刚好相反。结果是：libngu 以为自己拿到了硬件随机数，实际拿到的是一个确定性 PRNG。而且两个实现的函数签名完全一致，链接阶段不会有任何告警。

Coinkite 在事后复盘里说得很直白：「我明确地把 MICROPY_HW_ENABLE_RNG 设成了 0，以为这样两个版本都不会被编译进去，但这个宏不是这么工作的。」他们也承认，之前的代码审查确认了正确的 TRNG 代码确实存在于固件二进制里，但「没有验证从钱包种子生成到符号解析、调用可达性的端到端链路」——因为这跨越了两个 submodule。

软件 PRNG 的种子从哪来：UID + 定时器

Yasmarang 这个 PRNG 只在第一次调用 rng_get() 时初始化一次，之后不再采集任何新的熵：

pad = UID_low32 ^ SysTick->VAL; // 芯片 UID 低 32 位异或 SysTick 当前值 n   = RTC->TR; // 时分秒 d   = RTC->SSR; // 亚秒计数 dat = 0;

这四个值决定了此后所有输出。逐个看它们的性质：

Block 特别指出：UID 和 SysTick 是异或进同一个 32 位的 pad，所以两者组合的上限就是 232，「不是 2(32 + SysTick 位数)」。而且不同芯片的 UID 低 32 位甚至可能重复。对于老的 Mk2/Mk3，RTC 振荡器在启动时是关闭的，意味着冷启动时 RTC 值可能是静态的甚至是零。

更关键的一点：攻击者可以买一台同型号设备，刷上相同固件，profile 自己这台的行为，从而大幅收窄对别人设备状态的猜测范围。

为什么三道「防线」一道都没起作用

Coldcard 的代码里其实有几层看起来像保护的东西，但它们都不能凭空造出熵。

1. 再异或一个 PRNG 流

libngu 维护了第二条 Yasmarang 流，用来和第一条异或：chip = rng_get(); chip ^= my_yasmarang();。但这条流的初始状态是写死在源码里的公开常量：

yasmarang_pad = 0x0a8ce26f; n = 69;  d = 233;  dat = 0;

两个可复现的值异或，结果依然可复现。异或不产生熵。

2. 健康检查

代码会拒绝相邻两次 rng_get() 输出完全相同的情况。但一个正常工作的确定性 PRNG 本来就几乎不会产生相邻重复值——这个检查只能抓住「RNG 完全卡死返回常量」这种极端故障，抓不住「输出可预测」。

3. SHA256d 哈希

种子生成会对 ngu.random.bytes(32) 的输出做 SHA256d。哈希是确定性函数：输入只有 240 种可能，输出也就只有 240 种可能。哈希能均匀化分布，但不能增加熵。BIP-39 的校验位同理，也不提供任何额外保护。

这是密码学工程里最容易被误解的一点：异或、哈希、多轮混合，都是熵的「搬运工」而不是「生产者」。上游熵源坏掉之后，下游做多少加工都补不回来。

4. Mk4 之后的 32 位重播种

2022 年 3 月，Coldcard 为 Mk4 加了开机重播种，从安全元件读随机数注入 PRNG：

a = callgate.read_rng(1)  # SE1 的 32 字节 b = callgate.read_rng(2)  # SE2 的 8 字节 n = ngu.hash.sha256d(a + b) n, = ustruct.unpack('I', n[0:4])  # 只取前 4 字节 ngu.random.reseed(n)  # 且只写入 yasmarang_pad 一个状态字

方向是对的，落地打了折：40 字节的安全元件随机数，最后只有 4 个字节进入 PRNG，而且只覆盖了一个状态字，其余状态字保持原样。这就是 Mk4/Mk5/Q 的搜索空间上限被卡在 232 量级的原因。Block 还指出 SE2 那一路实际读的是 ROM 选项页，并没有跑活的随机数命令。

熵到底剩多少：两家给的口径

Coinkite 和 Block 的估算方法不同，需要分开看。

Coinkite 的口径（官方估计，标注为初步值）

| 型号 | 估计有效熵 | 对照 | | — | — | — | | Mk2 / Mk3 | 约 40 bit | 12 词 BIP-39 种子应为 128 bit | | Mk4 / Mk5 / Q | 约 72 bit（安全元件的值作为「兜底的兜底」混入） |

Block 的口径（条件上限，不是安全强度）

Mk2/Mk3 v4，定时器状态已知：20——完全确定。
Mk2/Mk3 v4，UID 已知、SysTick 未知：约 216.29。
Mk2/Mk3 v4，宽松上界（枚举所有 SysTick + RTC 状态）：低于 240.7；若冷启动时 RTC 稳定，收窄到约 216.3。
Mk4/Q/Mk5，重播种成功且定时器已知：≤ 232（平均搜索约 231）。
Mk4/Q/Mk5，定时器未知：宽松上界 低于 273.3。
Mk1，以及 Mk2/Mk3 v3.2.2 及更早：约 2256，不在此次回归范围内。

Block 反复强调的一句话：273.3 不等于 73 bit 的密码学安全性。因为这些定时器字段之间彼此相关、且部分可观测，真实搜索成本远低于这个数字。Block 也明确说明自己没有做完整的实证测试，没有发布任何暴力破解基准数据，之所以提前公开是因为攻击已经在发生。

需要补充的是：如果攻击者不确定生成种子之前设备调用过多少次 RNG（call history），上述数字还要乘以可能的执行轨迹数量。反过来说，攻击者如果能约束这个变量，成本会进一步下降。

攻击是怎么执行的

整条链路不需要接触设备，也不需要任何用户交互：

离线枚举候选种子：

在攻击者自己的机器上，按上述状态空间遍历，复现 PRNG 输出流。
推导地址：

把每个候选种子按 BIP-39 / BIP-32 推出地址。对纸钱包这条路径更省事——RNG 输出直接就是 secp256k1 私钥，中间连 BIP-39/BIP-32 都不经过。
拿公开区块链当验证器：

把候选地址和公开 UTXO 集合比对。命中即确认，比对完全免费。
批量清扫：

命中的单签地址直接全额转出。

公开区块链在这里变成了一个免费的、无速率限制的口令校验预言机。这也是弱熵类漏洞在加密货币场景里格外致命的原因：在其它领域，攻击者还得逐个去线上系统试；在这里，验证是纯本地的查表操作。

受影响的不只是钱包种子

Block 梳理出所有走 my_random_bytes() 这条流的功能，都同样受影响：

新种子与临时种子（ephemeral seed）
纸钱包与 secp256k1 私钥

——RNG 输出即私钥，且公开的地址本身就是验证预言机。用「掷骰子」选项生成的可绕开这条路径。
Seed XOR 掩码

——仅限「随机拆分」模式：若攻击者手里有 B 份，可枚举掩码并用 xpub 验证；只拿到 A 份则无泄露。默认的确定性拆分不受影响。
克隆 / USB / Key Teleport / Web2FA 的 ECDH 临时密钥

——克隆场景中公钥会存在 MicroSD 上（甚至在文件名里），可直接校验候选值。
Secure Notes 密码

——「加密选项」调用两次 generate_seed() 并不能让熵翻倍，两次都来自同一个小状态生成器。手动输入和 BIP85 派生的密码不受影响（前提是底层种子安全）。
HSM 本地码材料

而调用 ckcc.rng_bytes 的那些地方，走的是真正的硬件 RNG——用 Coinkite 自己的话说，手写的 TRNG 代码「确实还在被用，但只是碰巧，而且只用在不太重要的地方」。

多签不是万能解：如果多签仲裁组里的设备全部受影响，多签提供不了任何保护。只有当足够数量的参与设备是已知安全的，多签才成立。

受影响与已修复的固件版本

关键前提：暴露与否取决于「生成种子时用的固件版本」，而不是当前安装的版本。升级固件既不会修复也不会进一步损坏一个已经生成的种子；把这个种子导出到别的钱包，同样带着漏洞。

版本号陷阱：Standard 和 Edge 是两条独立的发布线。不要因为一个 Edge 的 6.x 版本号看起来比 Standard 的 5.6.0 大，就以为它是安全的。Coinkite 专门提示了这一点。

另外，TAPSIGNER、OPENDIME、SATSCARD 使用不同代码库，不受影响。

如果你手里有 Coldcard，该做什么

Coinkite 给出的判定条件是明确的：种子生成时如果至少用了 50 次公平、独立、私密的掷骰，仅就这个 RNG 缺陷而言不必担心。骰子熵走的是另一条路径，绕开了受影响的代码。

但这个条件必须全部满足。次数不够、骰子不公平、掷骰过程被拍到或被人看到，都不算数。如果记不清了，Coinkite 的建议是按受影响处理。

关于 BIP-39 密语（passphrase）

一个强的、唯一的、与助记词备份分开保存的密语，可以降低即时暴露风险——因为它会派生出一个完全独立的钱包。但 Coinkite 说得很清楚：它不能修复一个已经受影响的种子。密语如果短、常见、有规律、来自引文、被复用过、可能已泄露，或者你自己也不确定，那这部分资金就应按受影响处理。即便密语很强，Coinkite 仍然建议更换种子。

更换种子的步骤

先升级固件到修复版本

（对应你的型号和发布线），再生成新种子。顺序不能反。
生成一个全新的种子。

在修复后的固件上，设备自带熵已经足够，掷骰变成可选项。
备份并核验：

记录助记词，核对指纹（fingerprint）和一个接收地址；密语要和助记词分开存放。
断电重启后再次核验指纹和接收地址

——每一个密语（包括打错字的）都会生成一个合法钱包，转账前务必确认指纹。
先发一笔小额测试交易

，确认到账后再迁移全部余额。
旧备份先别销毁

，等迁移完全确认后再处理。

把旧助记词重新导入升级后的固件或换一个钱包软件，漏洞依然存在。种子的熵在生成那一刻就已经定死了，之后做什么都改不了。Galaxy 的建议是：Coldcard 上的单签资金应当立即转移。

链上：三波清扫与攻击者指纹

| 波次 | 时间 | 地址数 | 金额 | 特征 | | — | — | — | — | — | | 第一波 | 7 月 30 日 01:10–01:51 UTC | 1,196 | 1,082.65 BTC | 6 个区块内完成，汇入少量归集地址 | | 第二波 | 7 月 31 日 | 1,478 | 76.16 BTC | 模式与第一波相近 | | 第三波 | 7 月 31 日至 8 月 1 日 | 1,912 | 约 207.73 BTC | 拆分进 293 个 P2WSH 地址 |

Galaxy 判断第一波是自动化执行的：每一笔交易都用写死的 30 sat/vB 费率，且不带找零输出。那一周的中位费率是 0.4–1.0 sat/vB，相当于超付 30 到 75 倍——典型的「脚本不管成本，只求快」。Galaxy 在过去 30 天的比特币交易里，没有找到第二个使用相同费率且签名方式恒定的操作者。

Galaxy 自己的提示很重要：这个模式识别的是「操作者」，而不是「盗窃行为」本身——因为「清扫结果看起来就像是币主自己在主动转移资金」。这也是这类事件难以被交易所和风控系统实时发现的原因。

第三波和前两波的资金归集方式不同：它把币拆进了 293 个 P2WSH 地址。P2WSH 在花费之前不会暴露赎回脚本，也就是说在这些币被动之前，外界看不到它们的花费条件。Galaxy 因此提示，不应假设第三波与前两波是同一个人，虽然第一波和第二波从交易模式看很可能同源。

其它几个值得记的事实：

被盗的比特币目前 100% 未被花费，攻击者似乎更倾向于归集而非立即变现。
Galaxy 已向联邦调查人员、合规机构和网络安全调查方上报了约 600 个疑似攻击者控制的地址。
Galaxy 明确说明，其结论基于链上分析，尚未在计算上逐一确认所有被识别的地址都确实由弱熵生成。
Galaxy 同时警告：未来针对任何 Coldcard 生成地址的攻击都是可能的，并不需要匹配当前这个交易模式。

一个月内的第二起 RNG 事件

就在这次事件之前，Coinspect 于 7 月 6 日披露了另一组弱随机数问题，代号 Ill Bloom：部分较老的软件钱包在生成助记词时使用了不安全的 PRNG，把可能的助记词空间缩小到了可搜索的范围。

截至 6 月 30 日，已编目 2,114 个暴露地址，覆盖 Bitcoin、Ethereum、Rootstock、Tron、Polygon 等网络；首次注资时间从 2018 年 9 月一直延伸到 2026 年 5 月。
5 月 27 日一次协同清扫清空 431 个账户，约 314 万美元；5 月 30 日至 7 月 13 日又有 522 个种子被清空，约 255 万美元。累计约 569 万美元。
风险集中在较老或较冷门的移动端应用与浏览器插件，部分从 2018 年就在流通。Coinspect 已识别出 5 个存在问题的钱包实现，出于分阶段披露考虑暂未公开点名。
Coinspect 提供了免费自查工具 illbloom.org。

两起事件的技术形态高度一致：不是协议漏洞，不是合约 bug，而是最底层的熵源出了问题。区别只在于一个发生在硬件钱包固件里，一个发生在软件钱包代码里。

给工程团队的几条实在教训

宏的存在性 ≠ 宏的值。#ifndef FOO

和 #if !FOO 是两回事。项目里凡是用宏做「安全能力开关」的地方，都值得回头检查一遍守卫写法是否与定义方的语义一致——尤其是跨 submodule、跨上游库的时候。
关键路径要做「端到端符号可达性」验证，而不是「代码是否存在」验证。

Coinkite 之前的审查确认了正确的 TRNG 代码在二进制里，这个结论本身没错，但它回答的不是「种子生成实际调用了谁」。函数签名一致时，链接器不会替你发现绑错了实现。
为「熵源退化」加运行期与构建期断言。

Coinkite 的热修复做了两件事：直接把 MicroPython 的兜底 PRNG 对象排除在外；加入构建期符号检查，若板级代码没有提供 rng_get()、或上游兜底还在导出符号，就直接构建失败。这是这类问题唯一可靠的拦截点——运行时基本无法自证。
不要给密码学关键路径留「静默兜底」。

MicroPython 提供软件 PRNG 兜底的设计对通用场景是合理的，但对一个只做密钥生成的设备来说，「没有硬件 TRNG 就静默降级」应该是「没有硬件 TRNG 就拒绝启动」。
熵源缺陷不可事后补救。

这是它和绝大多数漏洞最大的区别：SQL 注入修了就修了，弱熵生成的密钥永远是弱的。所以这类代码的评审规格应该和普通业务代码彻底分开。有评论指出，引入这个 #ifndef 守卫的提交只有一个字符的 commit message、改动了 28 个文件、且没有走 PR；「First pass w/ libNgU」那次改了 120 个文件，同样是直推；后续两次开了 PR 但零评审合并。
公开链是免费的验证预言机。

做加密相关产品时，任何「输出可枚举」的缺陷都应按最高等级处置——攻击者不需要联网试探，本地算完直接查链就行。

Coinkite 在通告里提到一个耐人寻味的猜测：由于固件源码一直是公开的，他们怀疑「有人用 AI 审查了我们固件的历史版本」并发现了这个问题；而他们自己最近做的一次 AI 辅助安全审查没有查出严重问题。他们的结论是，攻防双方现在用的是同一套工具，「但今天它没有帮到我们，只帮了坏人」。这只是厂商的推测，目前没有公开证据支持。

最后

这次事件里没有 0day 利用链，没有侧信道，没有供应链投毒。有的只是一个宏判断写反了方向，然后在一条几乎没人会去端到端验证的路径上，安静地跑了五年。

硬件钱包的整套威胁模型都建立在「私钥不出设备」之上，而这次的攻击者从头到尾没有靠近过任何一台设备。它提醒我们一件常常被忽略的事：物理隔离保护的是密钥的存储，保护不了密钥的诞生。如果种子在生成的那一刻熵就不够，后面所有的安全元件、防篡改外壳、离线签名流程，都是在保护一个本来就可以被算出来的秘密。

需要保持克制的是：目前还没有任何公开报告证明有人成功重建出了受害者的助记词并与被盗地址一一对应，Block 也没有发布暴力破解的实测数据，Galaxy 的地址归因同样基于链上模式而非计算验证。这些都是需要后续证据补齐的环节。但对手里拿着受影响设备的人来说，这个不确定性不构成任何等待的理由——迁移资金的成本，和被清扫的成本，完全不在一个量级。

熵源缺陷不可事后修复升级固件 ≠ 资金安全端到端符号可达性验证构建期断言拦截降级立即迁移单签资金

一个宏判断的方向写反，代价是 8,860 万美元和数千个再也无法信任的钱包。后续我们会持续分享AI安全相关事件在企业的落地，欢迎点赞、收藏、转发！

AGI 安全 · 企业 AI 安全专项培训

面向固件与密码学工程的代码审计、熵源验证与 AI 辅助安全评审

我们提供完整的企业 AI 安全培训体系，助力企业建立完整的 AI 攻防与代码安全能力

如需定制企业内部 AI 安全培训、攻防演练，欢迎扫码咨询