STM32固件逆向

[复制链接]

STMCU小助手发布时间：2022-12-1 18:00

文章
文章封面:
文章简介:	STM32固件逆向

一、概括
用的很久之前做的一个电风扇的课设来做实验。

微信图片_20221129184848.png

用到了外部中断，定时器中断，pwm。MCU是STM32F103ZET6。

微信图片_20221129184844.png

在keil的设置中可以看到固件的起始地址，默认情况下为0x8000000。另外，keil生成的是hex文件，hex文件是带有基地址信息的bin文件，如果我们要生成bin文件，需要进行如下设置：

微信图片_20221129184839.png

另外，烧录到mcu中的固件是不带符号表等调试信息的，即hex和bin文件都不带调试信息，因为mcu的内存有限，但keil会单独生成一个带有调试信息的axf文件，我们可以以这个axf文件为基准，对照着恢复bin文件或者hex文件，下面我们来观察一下这三个文件的区别：
首先是axf文件

微信图片_20221129184836.png

几乎和源代码一摸一样，除了一些外设名用地址代替了。

再看到hex文件：

微信图片_20221129184829.png

首先需要将架构修改为arm小端序，再修改一下架构版本，stm32f103zet6是cortex-m3内核的，armv7架构。

微信图片_20221129184826.png

修改完后加载hex文件。

微信图片_20221129184824.png

IDA会自动识别出基地址，能识别出不少函数了，但伪代码是真的难看。

微信图片_20221129184821.png

基本上是看不出个什么东西来。

最后是bin文件。

微信图片_20221129184818.png

bin文件去除了地址信息的hex文件，需要手动设置基地址。

# f- P, s/ ~+ D5 Z- x3 r
二、手动设置固件基地址

我们的分析将以bin文件为目标。

将基地址重设为0x8000000，这个地址怎么来的？可以看stm32f103zet6的datasheet。

微信图片_20221129184815.png

从0x8000000开始就是flash的空间。

重新设置加载地址之后再将其按照代码解析就变成了hex文件的样子。

微信图片_20221129184812.png

但此时存在很多标红的地址，这是因为这些地址在IDA中并没有设置，因此IDA将其解析为非法地址，标红了，我们现在要做的就是手动添加一些段。

( ^2 w" q: V/ _8 k4 m, g" e5 n三、添加SRAM
段在axf文件中，IDA解析出了如下几个段：

微信图片_20221129184805.png

单片机内存被总分为flash(rom)和sram（ram），flash里面的数据掉电可保存，sram中的数据掉电就丢失，sram的执行速度要快于flash，flash容量大于sram上方的最低内存地址，最高地址，都是在flash和sram中。

我们正常下载程序都是下载存储进flash里面，这也是为什么断电可保存的原因。

单片机的程序存储分为code(代码存储区)、RO-data(只读数据存储区)、RW-data(读写数据存储区) 和 ZI-data(零初始化数据区)
Flash 存储 code和RO-data
Sram 存储 RW-data 和ZI-data

在datasheet中一样可以找到sram的起始地址，为0x20000000，结束地址为0x2000ffff，我们自己添加段不必像IDA自动分析的那样详细，一个sram的段即可。

也可以在IDA启动时设置好固件加载地址和sram的开始以及结束地址。
添加了sram段之后，红色的非法地址消失了，如下：

微信图片_20221129184756.png

四、恢复符号表
下一步，我们需要恢复符号表，由于bin文件不存在调试信息，所以IDA生成的伪代码几乎没眼看，为了方便我们的逆向，我们需要恢复函数名以及导入一些结构体。在这里就需要用到axf文件。

在前面我们看到axf文件几乎和源代码是一样的效果，里面有丰富的调试信息，当然，我们不使用这个课设的axf文件来恢复bin，这样就太刻意了。

由于我这个课设使用的是库函数来开发的，所以就不能使用stm32cube生成的hal库来恢复。具体该怎么恢复？我们采用bindiff来恢复符号表。

如果有闲工夫或者是对stm32的开发非常上手，就可以自己写一个demo，尽可能多的使用到各种库函数，然后编译出一个axf文件。我这里的话，由于好久没有用stm32了，开发起来有些生疏，所以就不自己手写了，我选择捡现成的项目。我学习stm32的时候买的是xx原子家的开发板，他们提供的例程也是非常丰富的，有五十多个，由易到难，涵盖了stm32开发的方方面面，因此我就直接拿这些例程中的一部分，编译出axf文件。比如下面这个内存分配的例程：

又比如这个pwm的例程：

微信图片_20221129184753.png

可以多选几个例程，能涵盖更多的库函数，将这些axf文件用IDA打开，然后生成idb文件。然后在我们的目标bin文件中，使用bindiff加载idb文件。

微信图片_20221129184750.png

选择一个idb文件，然后会出现这样一个比较界面：

微信图片_20221129184747.png

选取similarity大的函数导入到bin文件中。

微信图片_20221129184743.png

导入之后实际上就能恢复大部分的函数名了。

微信图片_20221129184739.png

但实际上，由于我这个课设的开发中使用了一些xx原子封装好的初始化函数(相当于xx原子对原本的库函数做了二次开发)，例如uart_init，delay_init这两个函数均是二次封装后的函数，所以恢复出来的函数会比一般情况下多一点。

多使用几个idb文件进行恢复后，已经可以看了。

微信图片_20221129184735.png

五、导入SVD文件，恢复外设结构* v3 N" T5 I: F

但这还不够，我们还需要导入SVD文件，啥是SVD文件捏？

微信图片_20221129184732.png

在IDA7.5以后，就自带SVD文件加载插件了，如下图：

微信图片_20221129184728.png

打开之后如下：

我们可以自行下载相应的SVD文件，或者加载GitHub上的仓库，我这里选择自行下载然后在本地加载。下载链接是这个：cmsis-svd
选中想要加载的svd文件之后，IDA就会自动恢复bin文件中的外设结构，体现在伪代码中就是这样：

微信图片_20221129184720.png

这样：

当然，也不是所有的外设都能恢复，和axf文件中的肯定是有差别的，但对我们的逆向已经起到了很大的作用了。

到目前位置我们已经做了如下几步：加载bin文件->设置固件加载基地址->添加sram段->恢复符号表->恢复外设信息。程序还原工作已经接近尾声，还剩下最后一步，恢复结构体。

六、恢复结构体
打开某个例程的axf文件，可以查看下其中使用的结构体。

微信图片_20221129184705.png

这些结构体中，有TIM_TimeBaseInitTypeDef，NVIC_InitTypeDef，GPIO_InitTypeDef，USART_InitTypeDef，GPIO_TypeDef等是我们经常使用的，用来进行定时器初始化，中断初始化，IO口初始化等等。

我们生成c header file。

微信图片_20221129184702.png

然后在bin文件中解析生成的头文件：

微信图片_20221129184659.png

然后在local type中就能看到不少结构体了。

微信图片_20221129184654.png

光导入了结构体还不够，我们还得手动将IDA的伪代码中的变量重新设置类型，怎么确定某个变量的类型是什么呢？需要结合库函数的变量类型来设置。

以GPIO_Init这个函数为例：

微信图片_20221129184650.png

我们打开固件库使用手册，找到GPIO_Init的原型。

微信图片_20221129184646.png

可以看到原型为：

void GPIO_Init(GPIO_TypeDef* GPIOx, GPIO_InitTypeDef* GPIO_InitStruct)

第二个参数为GPIO_InitTypeDef类型的，因此我们将伪代码中的v10的类型修改为GPIO_InitTypeDef，剩下的结构体我们也一样可以使用这样的方法来恢复，只要有固件库函数，我们就能够恢复对应的结构体，效果如下：

效果还不错。

七、总结
此次逆向是基于我的一个小课设，功能不多，而且由于我的课设用到了xx原子的例程二次开发的一些库，而我用来恢复符号表时使用的axf文件也是xx原子的例程编译出来的，所以恢复出来的符号表的比例会偏高。如果能确定使用芯片型号，以及使用的是固件库还是hal库，那么按照此方法大致上能在一定程度上恢复固件，使其可读性大大增加。

转载自：Lpwn