近期，在分析Thumb2指令的一个固件文件时，发现Thumb2指令集下执行函数的运行地址不对齐？
于是，为了分析一下原因，找了手头上现有的一款基于Cortex3内核的一块板子来实际执行看一下，结合编译后的Hex文件，通过IDA来进一步验证一下Thumb2运行地址不对其的现象。
操作示例：
- 固件代码
找了一个FreeRTOS的示例工程，加入几行打印函数地址的日志：
- 通过hex2bin将编译后的Hex文件转成二进制bin文件
执行情况：
- 通过ue打开bin文件备用，如下
* 通过Keil-IDE加载测试代码，如下：
通过IDE
debug调试后，板子reset之后在内部时序逻辑的控制下，将0x00000000地址的内容读取到SP；将0x00000004地址的内容读取到PC。此时SP中存放的是栈顶地址，PC中存放的是Reset_Handler复位处理函数地址。
- 通过IDA Pro加载上述第二步生成的bin文件，配置过程如下：
通过在示例工程中的配置，来定义加载到IDA中的内存及存储映射地址，如下：
- ida 加载后如下：
- 顺利找到程序入口地址：
进而找到main函数的执行地址，发现通过ldr加载到寄存器时的地址为main函数真正地址+1；通过debug，也可以验证，如下：
通过资料了解到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得到的。
程序debug，打印出的日志如下：
最后，在ue中固件文件中也找到了相应的Delay_nS函数的入口地址，实际在flash中的地址也是+1的，如下图：
也是+1的，如下图：
[外链图片转存中…(img-RToHkpTx-1677132990290)]
最后
对于从来没有接触过网络安全的同学，我们帮你准备了详细的学习成长路线图。可以说是最科学最系统的学习路线，大家跟着这个大的方向学习准没问题。
同时每个成长路线对应的板块都有配套的视频提供：
当然除了有配套的视频，同时也为大家整理了各种文档和书籍资料&工具，并且已经帮大家分好类了。
因篇幅有限，仅展示部分资料，有需要的小伙伴，可以【扫下方二维码】免费领取：
