首页 时政热点 科技头条 智能AI 安全攻防 数码硬件 开发者生态 汽车 游戏 社会热点 开源推荐 医疗健康 归档 标签 关于

当 random.bytes() 运行但不起作用时

摘要

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. I began investigating the Coldca...

the commit code and The changes message ratio that change
2026-08-02 1 阅读 约6分钟阅读 Funes-
分享:
字号:
这是来自著名 Core-Lightning 开发人员 ddustin 的客座帖子,他深入研究了 Coldcard 固件提交历史记录,以揭示发生的情况以及代码失败的原因。我开始调查 Coldcard 黑客事件,并立即感到震惊。我需要解释一下原因。当我们开发人员编写代码时,我们会将更改组织或编码为更改集,我们称之为“提交”。这样做的目的是清楚地显示代码更改的历史记录,包括更改原因和方式。这样做正是针对像这样的情况,比特币人的资金似乎被大量盗取,因此我们可以调查并准确了解它是如何发生的。优秀的开发人员会编写清晰的提交消息、与代码更改一起编写的注释,以解释具体更改要完成的任务。为了做出清晰的提交消息,您通常希望提交代表较小的代码更改,因此需要注释的内容较少。作为开发人员的一个好的目标是高提交消息更改率。您更改的代码行越多,解释更改代码原因的注释就越多。每次提交更多的消息和更少的代码更改通常是一个好主意。这是从我自己的一些作品中随机选择的一个例子。提交消息有 235 个字符,提交更改了 15 行代码。比率为 235/15 = ~16。在冷卡中,引入低熵错误的提交就在这里。提交消息有 5 个字符,只是单词“runs”。这次提交更改了 1534 行代码,使得比率 5/1534 = ~0.003 这是一个非常糟糕的注释与代码更改比率。在一些罕见的情况下,低注释率是合理的——但更改代码最重要的部分不是这些情况之一!涉及对项目安全至关重要的功能的代码需要有更高的注释更改比例和更严格的审查。导致 Coldcards 弱熵问题的第二个提交就在这里。提交消息有 1 个字符:只是字符“x”。提交更改了大约 1000 行代码,使得比率 1/1000 = ~0.001 在标题为“runs”(比率:~0.003)的提交中,他们似乎正在导入和配置 C 代码,以使自定义 micropython 代码在 STM32 上运行,所有 Coldcard 都在该板上运行。 STM32 是此类小型设备最常见的 CPU,并且像本次提交引入的配置很常见。在“runs”提交中,使用以下代码行禁用了硬件 RNG(随机数生成)。 #define MICROPY_HW_ENABLE_RNG (0) 这就是导致该错误的原因。将此值设置为零告诉默认的 micropython rng 代码不使用硬件 RNG 设备,而应该使用 Yasmarang RNG。开发人员添加了一个内联注释“解释”此更改 // 我们有自己的此代码版本。此代码的 COLDCARD 版本似乎引用了 rng.h 和 rng.c rng.h MP_DECLARE_CONST_FUN_OBJ_0(pyb_rng_get_obj); 中添加的函数; MP_DECLARE_CONST_FUN_OBJ_1(pyb_rng_get_bytes_obj);这些似乎是试图覆盖 stm32 rng 库的“pyb_rng_getobj”函数。这种方法遇到了麻烦。 stm32 rng.c 文件已经定义了 pyb_rng_et_obj 变量并将值设置为“pyb_mg_get”。您不能对同一变量有两个定义并对其进行编译。 rng.c MP_DEFINE_CONST_FUN_OBJ_0(pyb_rng_get_obj, pyb_rng_get);展开宏并从逻辑上思考它就是这个伪代码: var pyb_rng_get_obj = pyb_rng_get Commit ` 37e4af5` 添加了一个自定义 rng.c 文件,他在其中复制粘贴了相同的宏定义 MP_DEFINE_CONST_FUN_OBJ_0(pyb_rng_get_obj, pyb_rng_get);现在无法编译此代码。看来开发人员天真地尝试通过创建变量的重复版本来覆盖“pyb_rng_get_obj”变量。 C 不是这样工作的。这个错误会给他带来“重复符号 pyb_rng_get_obj ”的编译器错误,因为现在有两个地方定义了它:stm32 库和新添加的 rng.c 文件。从这里开始,我假设他在一阵沮丧中将 `MICROPY_HW_ENABLE_RNG` 设置为 0,这将解决编译器错误。有时,当开发人员陷入困境时,他们会随机尝试看看是否有帮助。将 ` MICROPY_HW_ENABLE_RNG 设置为 0 会使编译器错误消失***由于错误的原因***。 // 我们有自己的此代码版本 #define MICROPY_HW_ENABLE_RNG (0) 将 MICROPY_HW_ENABLE_RNG 设置为零完全删除了使用硬件随机数生成器的代码或第 31 至 80 行。 stm32 rng.c 文件。这具有删除 pyb_rng_get_obj 的第二个定义的副作用,它“修复”了编译器错误,要求程序员重新考虑他的逻辑,但编译器错误只是被静音了。
这篇文章对您有帮助吗?

订阅66必读

每日精选科技资讯,直达你的邮箱