混淆工具插件-OLLVM

可查早纳到.

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当前项目混淆.

混淆方法一: InstructionsSubstitution

[html] view plain copy

-mllvm -sub: activate instructions substitution

-mllvm -funcSUB="func1,func2,func3": if instructions substitution is activated, apply it only on functions func1, func2 and func3

-mllvm -perSUB=20: if instructions substitution is activated, apply it with a probability of 20% on each function

2. 混淆方法二: BogusControlFlow

[html] view plain copy

-mllvm -bcf: activates the bogus control flow pass

-mllvm -funcBCF="func1,func2,func3": if the pass is activated, applies it only on functions func1, func2, func3

-mllvm -perBCF=20: if the pass is activated, applies it on all functions with a probability of 20%. Default: 100

-mllvm -boguscf-loop=3: if the pass is activated, applies it 3 times on a function. Default: 1

-mllvm -boguscf-prob=40: if the pass is activated, a basic bloc will be obfuscated with a probability of 40%. Default: 30

3. 混淆方法孙卜裤三: ControlFlow Flattening

[html] view plain copy

-mllvm -fla: activates control flow flattening

-mllvm -funcFLA="func1,func2,func3": if control flow flattening is activated, apply it only on functions func1, func2 and func3

-mllvm -perFLA=20: 弊缺if control flow flattening is activated, apply it with a probability of 20% on each function

4. 则简如何用开源 source code 编译出混淆器O-LLVM ？

[cpp] view plain copy

$ git clone -b llvm-3.5 https://github.com/obfuscator-llvm/obfuscator.git  

$ mkdir build

$ cd build

$ cmake -DCMAKE_BUILD_TYPE:String=Release ../obfuscator/

$ make -j5

编译后的结果只有bin 和 lib 是有用的，其余的都可以删除：

方法：一个字节一个穗蔽字节的与一个随机字节异或

特征：导出函数中.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 都不错（四字节都没问题）

---