电脑疯子技术论坛|电脑极客社区

微信扫一扫 分享朋友圈

已有 407 人浏览分享

关于thumb2指令下函数运行地址对齐问题及验证固件分析

[复制链接]
407 0
近期,在分析Thumb2指令的一个固件文件时,发现Thumb2指令集下执行函数的运行地址不对齐?
于是,为了分析一下原因,找了手头上现有的一款基于Cortex3内核的一块板子来实际执行看一下
结合编译后的Hex文件,通过IDA来进一步验证一下Thumb2运行地址不对其的现象。
操作示例:

固件代码

找了一个FreeRTOS的示例工程,加入几行打印函数地址的日志:

QQ截图20221109140645.png

通过hex2bin将编译后的Hex文件转成二进制bin文件

执行情况:

QQ截图20221109140725.png

通过ue打开bin文件备用,如下

QQ截图20221109140815.png


通过Keil-IDE加载测试代码,如下:

通过IDE debug调试后,板子reset之后在内部时序逻辑的控制下,将0x00000000地址的内容
读取到SP;将0x00000004地址的内容读取到PC。此时SP中存放的是栈顶地址,PC中存放的
是Reset_Handler复位处理函数地址。

949.png

22220.png

通过IDA Pro加载上述第二步生成的bin文件,配置过程如下:

8999.png

8998.png

通过在示例工程中的配置,来定义加载到IDA中的内存及存储映射地址,如下:

8997.png

8996.png

ida加载后如下:

8995.png

顺利找到程序入口地址:

8993.png

8991.png

进而找到main函数的执行地址,发现通过ldr加载到寄存器时的地址为main函数真正地址+1
通过debug,也可以验证,如下:

800.png

898.png

通过资料了解到ARM指令是4字节对齐的,Thumb-2指令是2字节对齐的,所以这里main函数和函数Delay_nS的
地址应该是2字节对齐的,但是打印出来的值却是:08000BB1和080002D9。main函数的地址和test函数的地址
都成了奇数地址了。

这个问题在于有些ARM处理器即能使用ARM指令,又能兼容Thumb指令,同一个应用程序中可能同时存在ARM指令
和Thumb指令,这两者的处理方式肯定是大不相同的,所以为了切换ARM状态和Thumb状态,在跳转到Thumb指令
编写的代码块的时候,将程序地址的最低位置1(因为不管是ARM指令还是Thumb指令,都至少是2字节对齐的所以
最低位一定是0,所以最低位可以拿来用于区分ARM状态和Thumb状态),这样处理器识别到最低位为1的话就会切
换到Thumb状态,否则则是ARM状态。Thumb2指令集也是为了兼容以前的ARM状态和Thumb状态所以这样做的。

所以编译器编译STM32F1的程序的时候,会把函数的真实地址 加上1 作为常量放在ROM空间 如果这个函数的地址
有被用到的话获取函数的指针的时候就会获取到最低位被置1的一个地址。如下图,获取Delay_nS的地址的时候到
0x08000BC4地址处读取到了0x080002D9的值,这其实就是Delay_nS的真实地址0x080002D8 + 1得到的。

798.png

程序debug,打印出的日志如下:

797.png

最后,在ue中固件文件中也找到了相应的Delay_nS函数的入口地址实际在flash中的地址
也是+1的,如下图:

796.png

您需要登录后才可以回帖 登录 | 注册

本版积分规则

1

关注

0

粉丝

9021

主题
精彩推荐
热门资讯
网友晒图
图文推荐

Powered by Pcgho! X3.4

© 2008-2022 Pcgho Inc.