特征：导出函数中.datadiv_decode000000000000000
这里分为三种情况来介绍：
我们可以使用010editer把值异或回去
以上方法用作静态分析也可以看到，但是效率太低了
这里我们考虑使用frida去找到已经解密在内存中的数据查看
简单改改类型得到以下信息:
IDA静态直接进去到37050地址，发现是一个data段的加密数据，这个数据在运行时是已经解谜的，所以直接去hook查看这个地址的值即可
实际上是在init_array中的函数解密字符串，完成后在内存中就是明文状态了
但是解密函数依旧会出现在init_array节区
可以看到函数名已经变化了，不同于标准的函数名
但是这里用类似的方式进行处理
我们在回到JNI_Onload中找到解密出来字符串指针
知道它是五个长度直接转为六个长度的字节数组
这里在ida中看到的也是加密后的，可以看到右边有这个字符串解密的函数引用，这就是对应我们刚开始在init_array中的字符串解密函数
由于我们刚才将这里的长度定义为了一个六个字节长度的数组，所以这里F5一下可以看到如下：
综上可得在这个解密函数中，每一次换了随机的异或常量，这里就代表有一个新的字符串
这个玩意儿只是异或的不同写法，和上面的异或一个道理，且仅存在与arm64中
解密函数就出现在使用字符串的前面，在哪里用那里解密
这里也是很明显的特点
这都是处于.bss段，意味着一开始没有初始化，只是一个引用放在这里
面对这种东西我们自然也是可以用frida去hook查看这个（0x3E195）位置的值
或者用hook libart.so去hook住RegisterNative
函数，再或者偷个懒用jnitrace即可hook关键函数，拿到解密后的字符串
这种操作他的解密函数可以很复杂，也不要求解密后的大小等于加密后的大小
回看前两种处理方式，都是简单异或操作完成的，数据都是处于.data段，异或完成后依旧是放在原位置的，程序真正运行前已经解密完成，第三种方式是独立的.bss段存放解密后的字符串，即运行到指定位置后才开始解密
最后补充一句：
frida的inlinehook对于thumb指令不太稳定（主要就是这种两字节的指令不一定成功）
arm 和 arm64 都不错（四字节都没问题）
可查到.
OOLVM-JSF基於 https://www.jianshu.com/p/e0637f3169a3
但是会出现 ___isOSVersionAtLeast 该异常，需要前往/build/lib/clang/版本号/lib/drawin/中添加/替换libclang_rt.ios.a
替换的方法.
直接在
在该路径下的libclang_rt.ios.a 添加/替换/build/lib/clang/版本号(8.0.0)/lib/drawin/下的
OLLVM-SF基於OLLVM-X5文件去迭代.其中只是替换了libclang_rt.ios.a 可使用混淆参数为
OLLVM-X5 基於 https://github.com/obfuscator-llvm/obfuscator.git 编译的.
开始重新布置混淆工具
制作OLLVM混淆工具插件.
https://www.jianshu.com/p/e0637f3169a3 //作者混淆工具
配置Xcode--新建Obfuscator插件
以上一个Obfuscator插件就完成了.
打开Xcode-项目-BuildSettings
以上为OLLVM当前项目混淆.
