跳转至

闲鱼上那些“带锁”的ESP32模组

闲鱼上那些“带锁”的ESP32模组

为了准备 ESP32 故障注入培训,我们从淘宝买了很多家 ESP32 的开发板,结果全是 V3 版本的芯片,似乎已经很难买到老版本的 ESP32 开发板了,随后我们将目光转移到了闲鱼,买了几个也是新版,要不买 ESP32 模组,配合 ESP32 烧录座使用吧

1722047941820-d7a33a8d-d218-46ea-80eb-750f4c9a6550.jpeg

于是就在闲鱼看二手的 ESP32 模组,发现了一个有芯片丝印的图,确实是老版本,很符合要求

1722047959049-96f756dd-35ad-4374-8874-ac8abcfcf2f2.jpeg

但是描述说锁了,在一个安全研究员的角度看,锁了应该是启用了类似安全启动或者 Flash 加密,这种一般人没法用的,但是在描述里还有一句:不懂请勿买,现在故障注入已经普及到这种程度了吗,随便打?

1722047969526-14007dd3-43ff-4045-bce9-aaef9a2bad05.jpeg

在闲鱼其他人的评论区发现大家都在说小米/灯具的锁了

1722047980013-bed47a3f-ae1a-4349-b50d-0ec2edfe4059.jpeg

卖家显然确实不太懂

1722047993710-d843d98c-7370-41f5-8ccd-7dbf239c72f5.jpeg

于是下单搞几块看看,通过加热台成功将模组与原来的 PCB 板分离,上机测试,串口有输出

接下来烧个 hello world 看看,结果确实没跑起来,观察串口显示是:Running on single core variant of a chip, but app is built with multi-core support. 看起来是个如卖家所说的单核 ESP32 芯片

1722048000691-c0a16fa0-cb5e-4c4f-91c6-f27a6667ec1a.jpeg

那好说,直接在 idf.py menuconfig 里面修改一下 freeRTOS 的配置即可,启用 Component config → FreeRTOS → Kernel 中的 Run FreeRTOS only on first core

1722048012602-6ca25794-7d9e-41ee-83f7-ac08344cf359.jpeg

然后重新编译烧录就跑起来了,就这?这也叫锁?

1722048021458-d7b3f43b-c40e-4fcd-a78c-d10d4b2e735b.jpeg

然而事情并没有结束,很奇怪为什么会把这种东西称为锁,于是在网上搜了搜相关的内容,先是看到这篇文章,虽然型号不一样,但是可以确定,有些芯片确实是开启了安全机制的(带锁的 ESP32-SOLO) https://www.mydigit.cn/thread-302114-1-1.html 由于帖子比较老了拍照识图没找到相关商品,且芯片型号本身也不一样,就先放过去了

1722048030432-444babf8-9830-47ce-bfc2-faeba7057f68.jpeg

发现 B 站有人买了灯具上拆的 ESP32模组 https://www.bilibili.com/video/BV1YM411X77h 然后测试说没法用,但是结论存疑,按照他这个拆法,Flash 芯片必然已经错位(我自己拆的时候血淋淋的教训,Flash 比较重,取的时候偏了直接错位,甚至会把其他的电容电阻也给推走)

1722048041791-80876e2a-4717-4825-9c2f-93452f643716.jpeg

评论区也有人指出了问题,必须点个赞哈哈哈

1722048051134-78054cb0-4d83-44ad-a47e-6cbb59631f77.jpeg

后来刷到一篇专业点的文章,对米家智能插座的逆向 https://telegra.ph/esp32-06-08 他提到其实是小米通过烧 eFuse 把另一个核给禁用了,看了看手上的模组确实是这样的,我还以为这是乐鑫给小米定制的阉割版呢,这到底是出于什么考量??

1722048060114-6d4c84b2-0b2f-4322-9dcd-0ea7d7e0a221.jpeg

在一篇论文 https://dspace.cvut.cz/bitstream/handle/10467/89988/F8-DP-2020-Vacha-Michal-thesis.pdf 中提到,可能确实是为了提高安全性

1722048070344-ad5061bc-5c96-4959-9734-27449bce16fe.jpeg

1722048078027-547232d4-8cde-4cb9-9555-8d9885e73816.jpeg

另外米家智能插座的逆向这篇文章还提到了 MAC CRC 校验错误,前面我尝试过程中没有报错只是因为我没有用到蓝牙WiFi 这些功能,所以没有校验 eFuse 中写的 MAC 地址 CRC 和实际的 MAC 地址的 CRC 是否一致,看了看 eFuse 中的 CRC 确实不对

1722048087673-e577e264-fc3f-4267-a125-8590e10467d8.jpeg

在这篇文章 https://llccd.eu.org/2023/06/miot_custom_fw/ 中提到小米的 SDK 和官方的 SDK 校验方式是不一样的,因此需要 patch 一下代码

1722048096645-239ae9c4-0fef-4cdb-a707-9da51e3966f3.jpeg

官方回复也确实说明小米在 SDK 上做了改动:https://esp32.com/viewtopic.php?t=28102

1722048110939-672e4057-a537-4d75-80fb-ec86f1350d2e.jpeg

那来尝试烧录一个 WiFi 功能的程序固件,确实会提示 Base MAC address from BLK0 of EFUSE CRC error

1722048122276-0f621ef7-5d6d-475f-98e9-084407f61797.jpeg

但是问题不大,ESP-IDF 可以忽略这个 MAC CRC

1722048130814-2187e6c8-0788-4bab-9732-06fa5a4aeaa6.jpeg

改过之后就可以跑了!基本可以确定我买到的是小米的定制芯片

所以仅就 ESP32 D0WD XMC01ESP 这个芯片总结一下所谓的”锁了“,表现在以下两个方面:

1、把 DISABLE_APP_CPU 烧了,只能单核运行,需要配置一下 FreeRTOS

2、小米的 SDK 对于 MAC 地址 CRC 的计算方法与官方 SDK 不一致,而且默认不一致的时候会重启,但是 ESP-IDF 可以忽略这个校验错误

原文: https://www.yuque.com/hxfqg9/iot/sdg8kvi4wvd92bdk