STM32**有多难？

只看该作者 · 2009-12-17 12:30

对于《STM32F103RB的BootLoader软件安全设计方案》一文比较质疑的一点：
文中提到“读、写保护有效时将禁止调试接口和SRAM 中运行的程序对Flash读、写操作”，但是下面的流程图中竟然有“在SRAM Debug模式下擦除Option Bytes域设置芯片写保护无效”，请问是不是自相矛盾？最好是原作者出来讲解一下到底是个什么原理？

只看该作者 · 2009-12-17 13:55

STM32的读保护一旦使能，就只有flash中运行的代码可以访问flash的内容，其他包括调试器，RAM中的程序或者BOOTLOADER都是禁止访问FLASH的。

但在SRAM中运行的代码可以取消对芯片设置的读保护和写保护，只是一旦取消了读保护，flash自动全部擦除。

只看该作者 · 2009-12-17 18:49

文中所说方法并没有直接读flash的内容,而是在ram中运行程序取消flash的写保护(不是取消读保护),
擦除部分flash,并写入读取flash的程序.
重新从flash启动,就有可能会执行到新写入的程序,
这样就可以读出部分flash中的内容.
其实问题的关键是:使能读保护后,从ram中启动,倒底可不可以写flash

1万 · 2009-12-17 21:40

20楼你说的是真的吗？………………

只看该作者 · 2009-12-17 21:49

STM32很简单，不如自己开发一个，**干啥呢？意义不大

只看该作者 · 2009-12-17 22:00

23楼的已经说了：“STM32的读保护一旦使能，就只有flash中运行的代码可以访问flash的内容，其他包括调试器，RAM中的程序或者BOOTLOADER都是禁止访问FLASH的”
就是说使能读保护后,从ram中启动,不管是读Flash，还是写flash都是不可以的，所以那篇**中所说在ram中运行程序取消flash的写保护(不是取消读保护)，再擦除部分flash是不成立的，所以也不能写入读取flash的程序。

只看该作者 · 2009-12-18 10:27

本帖最后由 bigarmer 于 2009-12-18 10:30 编辑

那篇**《STM32F103RB的BootLoader软件安全设计方案》有点自相矛盾，既然设置了读写保护，又怎么能进入SRAM Debug模式呢？他这个SRAM Debug模式到底是什么意思？如果是通过调试器进入SRAM调式的话，那是扯淡；如果是修改应用代码，通过木马方式，使代码在SRAM里面运行然后解除写保护的话，就是成立的，当然要是为了读出FLASH里面的代码，就完全没有必要解除写保护了，程序里面直接用指针读就好了。至少该讲清楚吧？论文应该是学术研究的成果，不能说得不清不楚的，让人产生怀疑和误解。

只看该作者 · 2009-12-18 10:51

楼上的还是没搞清STM32的读保护机制。

我在23楼说过了，加了读保护，不影响芯片从SRAM BOOT，并通过调试器烧录代码到SRAM里，并在SRAM里运行代码。这段在SRAM里运行的代码，可以解除读保护(但是芯片会自动擦除FLASH)，也可以解除写保护。

但是只要读保护使能，在SRAM里运行的代码是不能访问FLASH的，无论是读操作还是写操作，无论写保护是使能还是解除。

只看该作者 · 2009-12-18 11:38

To bigarmer：

《STM32F103RB的BootLoader软件安全设计方案》是论文吗？发表在那本杂志上？你怎么知道是学术研究的成果？

况且那篇**自相矛盾，这就说明那篇**的内容是伪科学的！

只看该作者 · 2009-12-18 11:38

谢谢楼上再次详细解码我的疑问。
设置了读保护可以通过调试器下载代码到SRAM，但是设置了写保护还能通过调试器下载代码到SRAM吗？

只看该作者 · 2009-12-18 11:43

通过调试器下载代码到SRAM中与是否设置了写保护无关！

1万 · 2009-12-18 11:45

请各位关注此问题的朋友仔细阅读这个文档，尤其是第2.4节：
《STM32F10x闪存编程手册(2009年6月第6版)》英文下载中文下载

只看该作者 · 2009-12-18 12:14

下面内容是从ST翻译文档中截取的：

附上完整文档

stm32f10x_flash_programming_cn.pdf (234.75 KB)

只看该作者 · 2009-12-18 14:17

这篇文档太老了，对读保护和写保护的描述都非常不清楚。还是看V6版的英文文档吧。

另外你31楼的问题，写保护只是针对flash，不影响调试器写SRAM。

1万 · 2009-12-18 14:29

是啊，34楼给的文档太老了，有点误人子弟，:L 请使用我在33楼给出的链接。

只看该作者 · 2009-12-18 15:39

本帖最后由 bigarmer 于 2009-12-18 15:50 编辑

**********帖子编辑修改原因，部分文字没有显示出来**********
谢谢vigia、香主、ST_ARM及其他网友的耐心指点。

重新阅读了香主发的新版文档发现我之前阅读的资料有误，对读写保护机制的理解是错误的，原《STM32F103RB的BootLoader软件安全设计方案》论文是没有技术问题的，作者实际上是利用了文档中提到的以下技术：
情形2：解除写保护之后仍然保持读保护，这种情况常见于用户自己的实现在程序中编程的启动程序：
-使用闪存控制寄存器(FLASH_CR)的OPTER位擦除整个选项字节区域；
-进行系统复位，重装载选项字节(包含新的WRP[3:0]字节)；写保护被解除。

我也发现JLINK软件下有一个专门使用JLINK来解锁STM32的工具，其原理就是通过JTAG向SRAM里面下载代码来解除读写保护
（实际上是整片擦除）。

我把讨论的论文《STM32F103RB的BootLoader软件安全设计方案》也发上来供大家参考（该**来自网络，版权归原作者和
出版商所有）。同时提醒大家，如果自己的产品里面使用了STM32，并且有自己设计的Bootloader的话，一定要考虑安全性
方面的问题。

只看该作者 · 2009-12-19 08:41

那是不是如果不用bootloader的话. STM32就非常安全而不容易被**?
如果如1楼给的例子能用6w解开stm32的话. 那重要项目还真不敢用STM32

只看该作者 · 2009-12-19 15:18

只要“读保护”是使能的，不可能从SRAM中执行代码来改FLASH中的内容吧。

只看该作者 · 2009-12-19 22:07

昏，那也太麻烦了

只看该作者 · 2009-12-21 09:21

为什么要讨论**这种问题呢

STM32**有多难？

常驻人口

技术高手奖章

精华达人奖章

湍急之河流

缘定三生

技术奇才奖章

荣誉元老奖章

坚毅之洋流

十世金身

技术领袖奖章

社区建设奖章