看到 CZ @cz_binance 昨天关于硬件钱包的推，有点话想说。 他那段写得很直接：自托管的情况下，开发者把漏洞补了，也修不了之前已经生成的钱包。而且开发者根本联系不到那些空气隔离设备上的用户。你的钱包会一直暴露着，直到你自己动手。他说自己是自托管的信徒，但责任最终还是落在用户身上。 这话把这次事件的本质点透了。 2026年7月30日前后，链上突然出现一批很反常的比特币转账。几百上千个沉睡了很久的单签地址，短时间内被一个个清空。没有多签，没有复杂操作，就是一笔笔很干脆地转走。最开始公开的大概是594枚BTC，后来Galaxy Research继续追，累计一度超过1300枚，按当时价格接近9000万美元。 这些地址有个共同指向：种子大概率是在某些版本的Coldcard上生成的。 不是设备被黑，也不是钓鱼。是一个藏了五年多的固件问题——随机数生成环节出了事。 硬件钱包最核心的承诺，是种子必须在设备内部用高质量的随机源生成。正常情况下，Coldcard会用主控芯片上的硬件真随机数生成器采物理噪声，再混合处理，生成符合BIP-39的助记词。 问题出在2021年3月那次固件改动。 那次为了配合某个库和编译配置，把MICROPY_HW_ENABLE_RNG设成了0。要命的是，相关库检查的时候只判断了这个宏“有没有被定义”，没管它到底是不是启用状态。代码就这么静默回退到了MicroPython自带的软件伪随机数生成器——Yasmarang。 这个软件生成器是确定性的，初始化主要靠芯片唯一ID和定时器寄存器这类相对固定的东西。对Mk3来说，有效熵大概只有40 bit左右；后面型号虽然多了安全元件做补充，但reseeding机制还是不够，有效熵大概在72 bit，远低于设计目标的128 bit。 设备以为自己在用真随机，实际跑的是一个可预测的软件伪随机序列。 这个坑从2021年3月一直埋到2026年7月才被大规模利用，中间固件迭代了很多次，居然一直没被充分暴露。 攻击者怎么做的。 不需要碰你的设备，也不需要骗你输入助记词。 他们先把受影响固件的随机数逻辑彻底摸透，搞清楚那个有限的状态空间；然后离线大规模生成候选种子，再从这些种子推导出比特币地址；拿去跟链上公开数据比对，专门找有余额、长期没动、单签的地址。匹配上了，直接签名转走。 整个过程高度依赖链上透明。攻击者本质上是把“能被算出来的种子空间”和“链上能查到的余额地址”做了一次碰撞。这也解释了为什么很多被盗地址是生成好几年后才动——它们是后来才被算出来的。 哪些人风险更高。 风险不是均匀的。 高风险主要是这几类：Mk2/Mk3，在固件4.0.1到4.1.9期间生成的种子（有些分析会延伸到更晚版本）；生成时没有扔足够多独立私密骰子，一般认为至少50次以上才有实际意义；同时也没有设置强且唯一的BIP-39密码短语。 如果你生成的时候认真扔了足够多真实骰子，50次以上能把熵明显抬到128 bit量级，99次以上就接近256 bit了；或者用了足够强的独立Passphrase，风险会低很多。多签结构里，只要不是所有密钥都来自同样有问题的设备，也能提供额外缓冲。 有一件事得拎出来强调：升级固件本身修不了已经生成的旧种子。种子生成那一刻，熵缺陷就固定了。唯一的办法是用修复后的固件重新生成新种子，再把钱迁过去。 怎么应对比较稳妥。 碰到这种事，最危险的往往不是漏洞本身，而是慌乱中又踩一次坑。 相对靠谱的步骤大概是这样：先确认自己的设备型号和生成种子时的固件版本；在已经修复的固件上生成全新种子，强烈建议叠加真实骰子；仔细验证新种子的备份、钱包指纹和接收地址——这步千万别急，这里出事前面全白干；然后先发一笔小额测试交易，确认没问题再逐步迁移剩余资金；旧备份在迁移完成并确认无误之前，先别急着销毁。 临时措施可以是给旧钱包加一个强密码短语，把资金转到带Passphrase的派生地址上。但这只是争取时间，不是最终解法。操作过程中尽量别把大额资金先转到安全性更低的热钱包或者认证很弱的平台上。 最后说一句。 这次最让人难受的，不在于某款具体产品，而在于它打中了自托管模型里一个被默认得太久的前提：设备内部生成的随机数，一定够好。 我们平时聊多签、聊空气隔离、聊防物理攻击、聊供应链安全，聊得很多，却很少认真怀疑过随机数本身的质量够不够。这个地基一旦出问题，上面再厚的防护也会瞬间失效。 硬件钱包解决的是“私钥不出设备”，但它不能自动保证“生成私钥时的随机性足够强”。后者同样需要被认真对待。 自托管从来不是买个硬件塞进抽屉就完事了。种子怎么来的、熵够不够、有没有单点依赖——这些事不会因为你用的是大牌设备就自动消失。漏洞在身上时，唯一有用的动作就是安静验证、踏实迁移。别的都是噪音。