关于ollvm字符串加密那些事

ollvm 字符串混淆（编译期完成）

方法：一个字节一个字节的与一个随机字节异或
特征：导出函数中.datadiv_decode000000000000000
这里分为三种情况来介绍：

---

第一种情况：标准的ollvm字符串混淆

导出函数 与一个随机值异或

我们可以使用010editer把值异或回去

010异或操作)

以上方法用作静态分析也可以看到，但是效率太低了
这里我们考虑使用frida去找到已经解密在内存中的数据查看

简单改改类型得到以下信息:

查看函数

IDA静态直接进去到37050地址，发现是一个data段的加密数据，这个数据在运行时是已经解谜的，所以直接去hook查看这个地址的值即可

frida dump memory

实际上是在init_array中的函数解密字符串，完成后在内存中就是明文状态了

---

第二种情况：修改过函数源码只是解密函数名字不同的

但是解密函数依旧会出现在init_array节区

init_array 节区.png

可以看到函数名已经变化了，不同于标准的函数名
但是这里用类似的方式进行处理

解密函数详情 解密函数详情1

我们在回到JNI_Onload中找到解密出来字符串指针

找到字符串指针

知道它是五个长度直接转为六个长度的字节数组

修改字符串数组长度

这里在ida中看到的也是加密后的，可以看到右边有这个字符串解密的函数引用，这就是对应我们刚开始在init_array中的字符串解密函数
由于我们刚才将这里的长度定义为了一个六个字节长度的数组，所以这里F5一下可以看到如下：

修改后的显示情况

综上可得在这个解密函数中，每一次换了随机的异或常量，这里就代表有一个新的字符串

这个玩意儿只是异或的不同写法，和上面的异或一个道理，且仅存在与arm64中

---

第三种情况：不在init_array解密，在需要时使用前解密

IDA中展现的情况

解密函数就出现在使用字符串的前面，在哪里用那里解密
这里也是很明显的特点

处于.bss段的未初始化值

这都是处于.bss段，意味着一开始没有初始化，只是一个引用放在这里
面对这种东西我们自然也是可以用frida去hook查看这个（0x3E195）位置的值
或者用hook libart.so去hook住RegisterNative
函数，再或者偷个懒用jnitrace即可hook关键函数，拿到解密后的字符串
这种操作他的解密函数可以很复杂，也不要求解密后的大小等于加密后的大小

hook查看值

回看前两种处理方式，都是简单异或操作完成的，数据都是处于.data段，异或完成后依旧是放在原位置的，程序真正运行前已经解密完成，第三种方式是独立的.bss段存放解密后的字符串，即运行到指定位置后才开始解密

最后补充一句：
frida的inlinehook对于thumb指令不太稳定（主要就是这种两字节的指令不一定成功）
arm 和 arm64 都不错（四字节都没问题）