某试用版so保护函数混淆分析

so加固前后的格式变化和之前分析反调试类似，都是增加第一个PT_LOAD代码段的大小，并在原始so代码部分的最前面嵌入自己的代码，包括受保护函数混淆的后的代码。

函数混淆思路分析

函数受保护前如下

函数被混淆保护后发现代码头部首先会调转到嵌入代码中

查看嵌入代码自然是全都是花指令，老办法用unicorn跑一下被保护的函数。可以看到首先函数头部会跳转到嵌入代码中。

接着执行了大量等效的花指令后从嵌入代码中跳转回原函数体范围内（0x54a0c），原始指令（0x54a0c）被修改为了一条跳转指令继续跳转到下一个嵌入代码块。

看一下上面代码位置对应的原始代码，（0x54a0c）地址处实际是一个基本块的起始位置，后面分析情况大概类似，也就是说其会将被保护函数以基本块为单位进行划分，然后每一个基本块头部原始指令修改为b跳转指令，跳转到嵌入代码中执行等效花指令

继续往下看一下函数调用部分，嵌入代码会执行bl指令等效花指令并跳转到plt条目中，plt条目执行完后会返回到原始函数bl调用指令的下一条指令处，但是下一条指令已经被修改为一条跳转指令并跳转到嵌入代码中。这说明bl跳转指令也作为划分基本块的标准。

然后看一下全局数据访问部分，嵌入代码跳转到访问got表的指令后再跳转回嵌入代码中，这就说明访问got表的指令也作为函数基本块划分的标准。

按照他混淆的思路划分出一个具有四条指令的基本块，经过混淆后四条指令会被176条等效的花指令进行替换。

最后总结一下就是函数混淆思路是将一个函数以跳转指令（包含bl指令）和got表访问指令作为基准划分若干个基本块，然后每个基本块头部都修改为跳转指令跳转到嵌入代码执行代码块的等效花指令。

混淆函数分析方法

因为原始指令经过混淆后会被替换为等效的花指令，静态分析和单纯的动态单步调试分析难度都很大。

plt表跟踪逻辑

因为函数被混淆后并没有修改原始函数中引用的plt表部分的代码，所以可以在所有的plt表入口下断点进行跟踪分析，但是如果原始函数使用svc进行系统调用的话这种方法就不行了。

unicorn模拟执行

利用unicorn自映射so文件，然后自己做重定位（或者直接利用unidbg)。之后通过给函数参数赋予不同的值来模拟执行函数，进一步观察函数的执行效果达到分析函数实际作用的目的。