在移动端风控对抗中,端安全变得越来越重要,很多设备指纹厂商都纷纷将 java 层的设备信息采集代码移到 native 层。这么做的好处很明显,java 层的攻击相对native 来说简单不少,防御这块研究的人也不多,处于攻防不平衡的状态。native层的保护多种多样,除了常规的运行时保护,比如反调试,反注入等等,还有很多静态的保护技术,比如插花,混淆,这些保护让原来简单易懂的代码变得难以理解,让攻击者花费更多的时间去理解原来的意思。随着基于编译器的保护技术越来越成熟,越来越多的混淆方案出现在大厂的 so 中,这些 so 虽然也使用了 fla, sub ,bcf,但他们的实现跟开源的 ollvm 都有一定的区别。针对这些混淆,目前都只能通过case by case 的方式解决,没有一套通用的反混淆方案。当然,之前开源的d810 已经有了一定的探索。
本文仅讨论在 mac big sur
上编译 ollvm-4.0
时遇到的问题,以及解决方法。等后续在反混淆上有一定的积累再来讲讲如何进行反混淆
整个编译过程遇到如下问题:
1 | tools/clang/lib/CodeGen/CGOpenMPRuntime.cpp:6275:24: error: a lambda parameter cannot shadow an explicitly captured entity |
根据提示a lambda parameter cannot shadow an explicitly captured entity
google之后,找到了链接https://reviews.llvm.org/rGc6e4583dbbdc3112c9a04d35a161dc9b4657f607
, 这个patch中,我们主要关注三个部分,分别是 ThenGen
,EndThenGen
, BeginThenGen
, 将代码按 patch 修改好之后, 重新编译,发现就可以编译过去了。
这个修改,实际上是将lambda中 未使用的捕捉变量移除了,并没有其他的作用….
简单用clang
编译一下代码,发现报错了, 说是这不到 -lSystem
1
2ld: library not found for -lSystem
clang-4.0: error: linker command failed with exit code 1 (use -v to see invocation)
找了一圈, 最后发现在Big Sur
上加上-L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib
就好了, 另外如果要加入头文件的话,还需要添加-I/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include
, 但这么一搞,倒是引入了不少 warning 和 note。
至此就可以正常使用ollvm了,下图是一个 fla 的 demo。
不过现在只能编译64位的,32位貌似要修改sdk.