逆向分析part2-MCU逆向

 这里主要介绍MCU逆向分析过程中如何恢复更多的代码，以加快逆向分析的进度和相关代码的准确性

一、前言

在逆向分析MCU固件时，我们获得是MCU芯片中运行的真个固件。MCU的固件其压缩效率是十分恐怖的，可能几兆的固件，它的代码量可能就有百万行，而其中用户自定义进行编写的代码可能仅有几千行，所以，我们还原MCU正向开发过程中的SDK的函数是十分重要的，只有这样我们才能更快的找到用户自己编写的代码。

二、环境准备

在我们逆向分析前，我们需要准备的环境如下：

• MCU固件（这里使用的是本人正向开发的STM32固件）
• IDA/Ghidra逆向分析工具
• IDA/Ghidra相关的插件

三、逆向分析

这里我们重点介绍如何还原MCU的代码以及最为重要的符号表，但是不可能100%还原和原代码一致的内容。

0x01.IDA逆向分析STM32固件

这里我们有两个固件，.axf的固件为ELF格式带有符号表的固件，.bin的固件为不带有符号表的固件，同时也是我们平时遇到的最多的固件。

我们首先使用IDA载入demo3.axf带有符号表的固件。

这里可以看到IDA将其直接识别为ELF结构的文件，使用默认的选项即可。

我们可以清晰的看到所有的符号表，这对于逆向分析是最美好的状态，因为通过符号表我们能很快的分析出程序执行的逻辑及功能。但是我们在进行相关的安全研究下是很难获得这种ELF格式的MCU固件的，这种只适用在正向开发过程中进行灰盒测试使用。

接下来，我们看看我们平时获得最多类型的.bin格式的固件，这种固件符号表已经被去除，同时也不是ELF结构的固件了，那么对于这种固件我们如何进行分析呢？

使用file简单查看下demo333.bin固件

发现是data数据。对于这个固件是哪种架构的可以参照对应的芯片手册来确实，因为这个是STM32的固件，因此，可以确定为ARM32架构的。接下来，我们可以使用IDA 32加载固件

这里IDA将其识别为binary文件，我们重新指定芯片类型为ARM小端

接下来，我们指定一下ARM对应的具体架构

接下来，我们需要设置对应的ROM和RAM起始地址，对于这些起始地址，我们一般有以下几种途径获取：

• 通过芯片手册获取
• 通过开发项目的参数配置获取
• 对于摩托罗拉类型的固件，其文件的起始处会有进行标识
• 通过JTAG等接口调试进入后，逐块内存查看，也能获取部分数据

那么我们这里通过STM32的开发项目获得对应的地址。这里属于我偷懒了，对于STM32的芯片，其对应的芯片还是很容易获取的。

根据上述的地址在IDA中进行配置如下：

这里我们可以看到并没有获得对应的函数。我们通过快捷键d改变，数据类型。

这里可以清晰的看到一下地址的数据，对于STM32而言，我们跳转到0x8000269地址处，在地址-1处使用c生成代码，即可恢复大部分函数，这个属于STM32的一个逆向分析小技巧，记住在跳转前使用alt+g，将CODE32改为CODE16。

在这个地址使用c生成代码。

这时，我们可以看到左侧已经被恢复的一些函数，但是都是使用sub_地址进行命名。其实这时候，我们查看函数也能看到具体的实现逻辑，但是这其中有很多事MCU芯片自带的SDK，我们去分析这个意义不大，我们要找到开发者自定义的函数，这个是我们重点关注，因此接下来我们所有的工作都是如何恢复对应的符号，我们后面也会。

五、参考链接

1. https://xeldax.top/article/IDA_BINARY_SYMBOL_DIFF
2. http://blog.nsfocus.net/function-recognition-reverse-engineering-iot-equipment/
3. https://github.com/mandiant/flare-ida
4. https://github.com/posborne/cmsis-svd
5. https://github.com/leveldown-security/SVD-Loader-Ghidra