符号混淆(LTO)

自己觉得有一点成果了,发上来分享一下,大佬们点个赞或者提点意见!感谢QAQ!

主要思路如下:
1、编译阶段处理存在硬伤,所以确定方案在链接时处理;
2、链接时的module是被链接成的一个大的module;
3、pass不再注册在PassManagerBuilder,而是集成进库 libLTO.dylib 里
4、链接参数需要指定链接库
-lto_library /xxx/LLVM/llvm-project-llvmorg-13.0.0/build_xcode/Debug/lib/libLTO.dylib"
5、最后编译链接成的二进制符号被混淆。

详细文章发在我的简书博客:LLVM 进阶一:符号混淆(LTO) - 简书

1 个赞

但利用LTO去做CrossTU的一个问题是没记错的话静态库的时候不会走这条路径

我再去研究下静态库咋弄 :+1:

而且这个方法我怀疑linkonceCOMDAT的情况下可能有问题。
总的来说, CrossTU去混淆绝大多数时候都是个坏主意

我以为发现了新大陆,原来还是有坑。。。

我刚去测试了,只需要在静态库的target编译参数加上 -flto 就行,因为 -flto 参数会让clang编译生成bitcode,而不是目标文件

:thinking:我记得我写那篇博客的时候不是这种行为,行吧

按你胃,还是那句话,实际业务中其实意义不大

要得 :nauseated_face:

你这思路我三四年前就用了。 :laughing:

:cold_face: :cold_face: :cold_face: i’m out

先赞后看

编译时期的pass创建的init函数在链接后会很多。在链接时期的pass里的创建一个解密函数,比较干净。

这个不是也能混淆吗 为什么说在实际业务中其实意义不大,打的包不能上架?

我觉得应该是实际的release模式会strip掉符号,可能实际上混淆导出符号有用处

release模式不会strip掉符号,不然没法上架

因为攻击者就算没有符号也能逆向?