看到一个STM32破解的信息，分享一下
本帖最后由 fcm32 于 2024-3-7 10:36 编辑最近，STM32系列的破解器好多人在卖了，之前是帮你破解，现在直接卖破解器，价格越来越便宜，授人以渔了{:cry:}
我们偶尔会有客户失效的芯片，寄回来要求分析，但客户程序加密了，除了IO损坏等，没办法读到程序，就不知道FLASH数据有没有被修改！
也买过一个F0的破解器，我们的破不出来，和卖家简单沟通了，也看了一些其它卖家的说明，发现国产兼容的MCU，有部分能破解，有部分不能。
今天得到一个信息，据说他们的破解原来，是来源于麻省理工，有朋友知道哪里能看到这个文件吗？
本帖最后由 whatcanitbe 于 2024-3-7 15:45 编辑
找到一些链接 看起来是
https://www.aisec.fraunhofer.de/content/dam/aisec/ResearchExcellence/woot17-paper-obermaier.pdf
https://prog.world/read-secure-firmware-from-stm32f1xx-flash-using-chipwhisperer/
https://www.eevblog.com/forum/microcontrollers/dumping-stm32-protected-firmware/
https://github.com/doegox/stm32f1-firmware-extractor
https://blog.zapb.de/stm32f1-exceptional-failure/ 不开盖也能破解？ modbus 发表于 2024-3-7 15:57
不开盖也能破解？
(引用自3楼)
当然是指不开盖，开盖破解的成本大了去了。每个厂家的电路不一样，没有谁会花那么大力气去找点，最简单是探针下去读FLASH，但FLASH几十条线，估计不好弄。
去闲鱼看看，F0的破解器已经几百了。 据说F1xx有一个bug，可以反复从变成口 dump一些flash字节出来，我记得github有相关内容。 本坛有大佬们讨论过的 我记得那篇文章是有人dump了xx-link的bootloader出来从里面提取了固件加密密码之类的 很多芯片都可以用异常注入方式破解，破解硬件成本很低，主要是时间成本。
几年前就已经不设置STM32的读保护了，输出调试信息用RTT，不用占串口。谁想读就读，程序用UUID保护，写到其他芯片里不能正常工作，能把UUID保护破解了的人，完全有能力重新写个程序，防不住的。 那现在开始换到新出的RISC-V芯片，是不是暂时可以安全？ zhanyanqiang 发表于 2024-3-7 16:45
那现在开始换到新出的RISC-V芯片，是不是暂时可以安全？
(引用自8楼)
注入攻击和用什么内核没太大关系。 80%以上的 f1都没锁回读直接读就好 ，你说的这种 破解 其实 就是碰运气 没啥技术含量 ackyee 发表于 2024-3-7 16:55
80%以上的 f1都没锁回读直接读就好 ，你说的这种 破解 其实 就是碰运气 没啥技术含量 ...
(引用自10楼)
不是碰运气，这里讨论的是加了LEVEL1的保护 whatcanitbe 发表于 2024-3-7 15:32
找到一些链接 看起来是
https://www.aisec.fraunhofer.de/content/dam/aisec/ResearchExcellence/woot17 ...
(引用自2楼)
https://blog.zapb.de/stm32f1-exceptional-failure/
这里讲了F1的破解，大意是通过以下方法：
1 M3具有中断向量重映射
2 使MCU产生异常，然后单步
但还是有几处不明白：
1 复位的时候，PC和MSP的内容，是FLASH第一和第二个地址的内容，即得到了2个字的内容，其它的内容没看明白是怎么得到的？难道是反复修改中断向量表，然后观察PC和MSP？
2 按以上方法，为什么得不到100%的内容
3 这个时间挺久的，要近1个小时，但现在的破解器，是非常快的
4 M0没有中断向量重映射，显然不是这个方法 Doding 发表于 2024-3-7 16:31
很多芯片都可以用异常注入方式破解，破解硬件成本很低，主要是时间成本。
几年前就已经不设置STM32的读保护 ...
(引用自7楼)
我想说你错了，破解的那帮人，2000可以包绕过UUID。根本不是用户搞。 https://prog.world/read-secure-firmware-from-stm32f1xx-flash-using-chipwhisperer/
这个文章了解了一下，是针对ST的boot，在读加密位的时候，用电源干扰。那说明了一个问题：ST的系统引导时的读保护，不是硬件上的，是软件处理的，否则此种攻击应该是无效的。 kitten 发表于 2024-3-7 17:15
我想说你错了，破解的那帮人，2000可以包绕过UUID。根本不是用户搞。
(引用自13楼)
绕过UID，是拿到了hex。
现在讨论的，是怎么拿到hex。 zhanyanqiang 发表于 2024-3-7 16:45
那现在开始换到新出的RISC-V芯片，是不是暂时可以安全？
(引用自8楼)
请问哪个品牌的RISC-V芯片? kitten 发表于 2024-3-7 17:15
我想说你错了，破解的那帮人，2000可以包绕过UUID。根本不是用户搞。
(引用自13楼)
用UUID保护，不仅验证UUID是否一致，还要防止别人改UUID地址，比如做程序完整验证。 会不会在擦除指令准备擦除加密位的时候才给编程电压？ tang_qianfeng 发表于 2024-3-7 18:03
会不会在擦除指令准备擦除加密位的时候才给编程电压？
(引用自18楼)
不是的。不是OTP，FLASH的擦除和写入，高压是在IP里面，外部不可控。 本帖最后由 fcm32 于 2024-3-7 18:36 编辑
https://www.usenix.org/system/files/conference/woot17/woot17-paper-obermaier.pdf
根据最新消息，是采用了这篇文章里的3.3.3节的方法。
不能被此方法破解的，据说是可能arm内核打过小补丁，但无法证实。因为我没有办法拿到ST的arm内核来比较一下源代码。
或者说：不清楚是不是有不同版本的m0代码，因为arm官方给的数据，m0只有一个版本。 zhanyanqiang 发表于 2024-3-7 16:45
那现在开始换到新出的RISC-V芯片，是不是暂时可以安全？
(引用自8楼)
如果是利用了arm核本身的机制，那换risc-v可能会安全些。 Doding 发表于 2024-3-7 16:51
注入攻击和用什么内核没太大关系。
(引用自9楼)
这要看注入攻击是针对的哪个硬件部分，也有可能和内核是有关系的。 这个是针对所有m3系列的吗？还是只针对f103型号的？ fcm32 发表于 2024-3-7 18:35
https://www.usenix.org/system/files/conference/woot17/woot17-paper-obermaier.pdf
根据最新消息，是采 ...
(引用自20楼)
看到后面的ic厂都是标M0+ ddcour 发表于 2024-3-8 17:12
看到后面的ic厂都是标M0+
(引用自24楼)
文章里是STM32F051，M0内核 tang_qianfeng 发表于 2024-3-8 17:06
这个是针对所有m3系列的吗？还是只针对f103型号的？
(引用自23楼)
网络上有F0、F1都能破的工具，至于是不是同一种方法，就不得而知了。
前面我说明过，利用中断重映射的话，M0是没有这个功能的。 tang_qianfeng 发表于 2024-3-7 18:03
会不会在擦除指令准备擦除加密位的时候才给编程电压？
(引用自18楼)
编程电压是不可控的，但可以掉电。
另外，原厂在设计时，擦除加密位的时候，是先擦除主FLASH，再擦除加密位。
如果先擦除加密位，再擦除主FLASH，这是设计上的低级失误，好像以前51 IC犯过这种错？ fcm32 发表于 2024-3-8 17:53
网络上有F0、F1都能破的工具，至于是不是同一种方法，就不得而知了。
前面我说明过，利用中断重映射的话 ...
(引用自26楼)
m0没有中断向量重映射功能？ Doding 发表于 2024-3-7 17:38
用UUID保护，不仅验证UUID是否一致，还要防止别人改UUID地址，比如做程序完整验证。 ...
(引用自17楼)
内部温度传感器校准参数搭配外部模拟器件的校准参数，由于模拟器件离散性大，破解了程序也不好保证量产产品一致性
当然，这些内部校准参数等地方的地址也要伪装一下的 Elex 发表于 2024-3-9 04:59
内部温度传感器校准参数搭配外部模拟器件的校准参数，由于模拟器件离散性大，破解了程序也不好保证量产产 ...
(引用自29楼)
用dma来读取， Elex 发表于 2024-3-9 04:59
内部温度传感器校准参数搭配外部模拟器件的校准参数，由于模拟器件离散性大，破解了程序也不好保证量产产 ...
(引用自29楼)
器件老化后会变的，又要产品可靠，又要识别出盗版，我认为用外部模拟器件难度很高。UUID能对付大多破解的人了，只要程序写的没有明显漏洞，需要通读反汇编程序才能破解，能让别人下这么大成本破解的产品，应该用加密芯片保护。 tang_qianfeng 发表于 2024-3-9 00:19
m0没有中断向量重映射功能？
(引用自28楼)
M0没有，M0+才有 Doding 发表于 2024-3-9 07:11
器件老化后会变的，又要产品可靠，又要识别出盗版，我认为用外部模拟器件难度很高。UUID能对付大多破解的 ...
(引用自31楼)
看你选择何种器件怎么用吧，比如放大器的Vos就是一个可以利用的参考资源
tang_qianfeng 发表于 2024-3-9 06:37
用dma来读取，
(引用自30楼)
地址关键字还是能搜出来的，要变换地址使得代码里不会出现能直接看到这些地址的内容 Elex 发表于 2024-3-9 10:25
看你选择何种器件怎么用吧，比如放大器的Vos就是一个可以利用的参考资源
...
(引用自33楼)
局限性比较大，用单片机自身的资源比较好。只要能识别出来别人把UUID改到其他地址上，就能识别出盗版被改UUID了，最简单的就是把读UUID的代码块做完整性校验，我一直就是这么做的，除非通读反汇编，否则无法发现做完整性校验的代码。 Doding 发表于 2024-3-9 10:33
局限性比较大，用单片机自身的资源比较好。只要能识别出来别人把UUID改到其他地址上，就能识别出盗版被改 ...
(引用自35楼)
很好的方法{:handshake:} 把读UUID的代码块做完整性校验;可否介绍一下方法. 本帖最后由 Doding 于 2024-3-9 10:49 编辑
lb0857 发表于 2024-3-9 10:39
很好的方法 把读UUID的代码块做完整性校验;可否介绍一下方法. ...
(引用自36楼)
程序里有什么校验算法就可以用什么，比如和通信共用一个校验函数，用分散加载文件把读UUID的代码写到固定位置上，设置某些触发条件，校验一下这段代码有没有被改，检测到改了再延时个比较长的时间，出一些故障就行了。我一直是延时uint32_max个ms后再出问题。 本帖最后由 Elex 于 2024-3-9 10:59 编辑
Doding 发表于 2024-3-9 10:33
局限性比较大，用单片机自身的资源比较好。只要能识别出来别人把UUID改到其他地址上，就能识别出盗版被改 ...
(引用自35楼)
UID之类和内部校准值之类的也是要用到的，比如根据校验数据对放大器的Vos的补偿值编码，即使解码出来UID和补偿值也因不能单独补偿Vos的离散值也不能量产。
况且可以把这些数据隐藏在代码存储区的中间甚至分多个地方存放，没那么容易看出，多片比较的难度也会增加。如果只用UID判断，人家修改指令跳转就跳过了 Elex 发表于 2024-3-9 10:58
UID之类和内部校准值之类的也是要用到的，比如根据校验数据对放大器的Vos的补偿值编码，即使解码出来UID ...
(引用自38楼)
校准值随环境变化可能需要随时要校准的，老化后也需要校准，比用UUID麻烦很多了，把验证UUID跳转指令和读UUID的指令代码块做完整性校验，别人改过了能知道，然后不定时出错就达到防盗目的了。这种不通读代码，没人会发现还有完整性校验，几个月后随机出故障更不会发现是防盗问题。 Doding 发表于 2024-3-9 11:09
校准值随环境变化可能需要随时要校准的，老化后也需要校准，比用UUID麻烦很多了，把验证UUID跳转指令和读 ...
(引用自39楼)
老化的范围跟补偿的范围很可能就不是一个数量级，看你怎么用了。反正我用近十年了，几百K产品也没因此出了问题的。
倒是有个风险是被人克隆产品后他们卖出去的产品可能会被外面市场上当成你的正品出了问题 Elex 发表于 2024-3-9 11:18
老化的范围跟补偿的范围很可能就不是一个数量级，看你怎么用了。反正我用近十年了，几百K产品也没因此出 ...
(引用自40楼)
具体情况不一样，看怎么方便吧，用UUID只是一种常见思路，没有UUID的芯片，还得用其他方法。我做的很多产品模拟部分，要么是高精度的，要么是完全不需要考虑精度的，所以用MCU自带的特性通用性更强。之前做暖通产品时，成本限制不严的直接用数字传感器，那些需要联网才能用的产品，根本连防抄都没做，hex直接给客户，没授权连不上服务器。
抄我产品的，不会打我的Logo的，所以出问题也不会有影响。 lb0857 发表于 2024-3-9 10:39
很好的方法 把读UUID的代码块做完整性校验;可否介绍一下方法. ...
(引用自36楼)
把加密校验函数放在一个固定的地址，然后把这段程序做校验码存储到flash，然后就好办了 carefree1986 发表于 2024-3-9 11:41
把加密校验函数放在一个固定的地址，然后把这段程序做校验码存储到flash，然后就好办了 ...
(引用自42楼)
哦哦，原子烧写器里面有教程。类似于这样的操作 Elex 发表于 2024-3-9 11:18
老化的范围跟补偿的范围很可能就不是一个数量级，看你怎么用了。反正我用近十年了，几百K产品也没因此出 ...
(引用自40楼)
你说的后者不怕，方法倒是新颖。
需要慢慢去消化，验证。 lb0857 发表于 2024-3-9 12:24
你说的后者不怕，方法倒是新颖。
需要慢慢去消化，验证。
(引用自44楼)
主要思路是从破解方法出发，一般的破解UUID，是把读UUID的ldr指令改为读另一个地址，这个地址写上正确的UUID，这样程序就被骗过去了，或者把判断是否相等的跳转改了，这样相等通过改为不相等通过，防范方法是把读UUID和校验的程序代码做完整性校验，如果按前面说的方法改了程序，就能发现，延迟出问题，是让破解者以为破解成功了，当然要放一些不延迟的出错作为伪装。 Doding 发表于 2024-3-9 12:40
主要思路是从破解方法出发，一般的破解UUID，是把读UUID的ldr指令改为读另一个地址，这个地址写上正确的U ...
(引用自45楼)
你说的思路是这样实现吧
/**
1. **生成UUID**: 使用STM32的随机数生成器或自定义的UUID生成算法生成UUID。
2. **添加签名或哈希**: 在生成UUID后，计算其哈希值或签名。你可以使用STM32的加密库来实现哈希函数（如SHA-256）或数字签名算法（如HMAC）。
3. **存储UUID和签名/哈希**: 将生成的UUID和其对应的签名或哈希值存储在芯片的非易失性存储器（如Flash）中。
4. **验证UUID完整性**: 当需要验证UUID时，从存储器中读取UUID和关联的签名或哈希值，然后重新计算UUID的签名或哈希值，并将其与存储的签名或哈希值进行比较。
5. **完整性检查**: 在你的应用程序中添加完整性检查的逻辑，确保在每次使用UUID时都进行完整性验证。
***************/
#include "stm32f4xx_hal.h"
#include "stm32f4xx_hal_flash.h"
#include "stm32f4xx_hal_hash.h"
#include <string.h>
#define UUID_SIZE 16
#define HASH_SIZE 32
uint8_t uuid;
uint8_t storedHash;
void generateUUID() {
// 在这里实现生成UUID的代码
}
void calculateHash(uint8_t *data, uint32_t dataSize, uint8_t *hash) {
// 在这里实现计算哈希值的代码，可以使用STM32的加密库
}
void storeData() {
// 在这里实现将UUID和哈希值存储在Flash中的代码
}
void readStoredData() {
// 在这里实现从Flash中读取UUID和哈希值的代码
}
int verifyIntegrity() {
uint8_t calculatedHash;
// 重新计算UUID的哈希值
calculateHash(uuid, UUID_SIZE, calculatedHash);
// 比较计算出的哈希值和存储的哈希值
if(memcmp(calculatedHash, storedHash, HASH_SIZE) == 0) {
return 1; // 完整性验证通过
} else {
return 0; // 完整性验证失败
}
}
int main(void) {
// 初始化HAL库
// 生成UUID
generateUUID();
// 计算哈希值
calculateHash(uuid, UUID_SIZE, storedHash);
// 存储UUID和哈希值
storeData();
// 模拟验证过程
readStoredData();
if(verifyIntegrity()) {
// 完整性验证通过
} else {
// 完整性验证失败
}
while (1) {
// 主循环
}
}
```
本帖最后由 Doding 于 2024-3-9 13:25 编辑
lb0857 发表于 2024-3-9 13:13
(引用自46楼)
UUID是指MCU自己的唯一ID，这个地址是固定的，厂家出厂时烧写，且每片IC都不一样，所以才能防盗，不是自己生成。因为地址是固定且已知的，破解者在汇编代码里找读这个地址的ldr，把地址改到别的地方就破解了，不用分析验证算法。
完整性验证，是验证烧写在Flash里的验证代码是否被改过，需要读出flash内容，校验后和保存的检验值对比，所以需要知道读UUID这段程序在flash中的地址和大小。 mcu的禁止读出这么容易被破解么 lb0857 发表于 2024-3-9 13:13
(引用自46楼)
你这个和硬件没有关系，读出hex后，烧到哪片MCU都能运行。
要用MCU本身的唯一ID，因为这个ID每片是不同的，所以用到了唯一ID的程序，烧入另外一片，结果就不对。 akey3000 发表于 2024-3-9 15:47
mcu的禁止读出这么容易被破解么
(引用自48楼)
破解器只有几百块了！！！
以前的MCU，各种类型的，都是把原片寄过去破解，到目前为止，只看到卖STM32的破解器{:smile:} 其实最根本的问题，是两个原因：
一是因为cortex系列的一些不合理的硬件设计，这个锅应该arm来背。
二是加密后，SRAM的访问应该禁止，这样就杜绝灌入木马程序。这个锅应该ST来背。
fcm32 发表于 2024-3-9 17:22
破解器只有几百块了！！！
以前的MCU，各种类型的，都是把原片寄过去破解，到目前为止，只看到卖STM32的 ...
(引用自50楼)
震惊，就是你一楼这个解ROP 的软件，只要几百元了？ yc2 发表于 2024-3-9 17:26
震惊，就是你一楼这个解ROP 的软件，只要几百元了？
(引用自52楼)
解M0的几百，解F1的现在几千 fcm32 发表于 2024-3-9 09:56
M0没有，M0+才有
(引用自32楼)
嗯，记得M0写bootloader因为不能重定向中断向量表，只能
1. 把中断向量表复制一份到SRAM起始位置
2. 把复位地址改为SRAM起始位置
3. 把lds文件里的SRAM起始位置向后移256字节
4. 把lds文件里的SRAM长度减掉256字节 fcm32 发表于 2024-3-9 09:56
M0没有，M0+才有
(引用自32楼)
那M0用户怎么做bootloader啊？ 本帖最后由 fcm32 于 2024-3-11 10:18 编辑
tang_qianfeng 发表于 2024-3-11 10:06
那M0用户怎么做bootloader啊？
(引用自55楼)
两种方法：
1 采用你上一楼的方法
2 共用中断向量表。中断后先判断是否为boot，再跳转至app或boot的函数。正常来说bootloader不会很复杂，用到的中断也极少，只要修改用boot用到的几个中断即可。
第二种方法更简单一些。 fcm32 发表于 2024-3-11 10:12
两种方法：
1 采用你上一楼的方法
(引用自56楼)
明白了，谢谢 Doding 发表于 2024-3-7 16:31
很多芯片都可以用异常注入方式破解，破解硬件成本很低，主要是时间成本。
几年前就已经不设置STM32的读保护 ...
(引用自7楼)
有人专门解软加密的服务高，
页:
[1]