-
Notifications
You must be signed in to change notification settings - Fork 192
处理OpaquePointer的方式是错误/不合规的 #1
Comments
关于处理OpaquePointers,我一开始是打算根据OpaquePointers.html 把getPointerElementType()的调用都替换成他里面所写的,但是测试后StringEncryption编译会报错,也看不懂是哪里的问题
然后我在这个网页我往下翻看到了这些:
所以我使用了这个方法 |
看着是后端CodeGen的问题? 完整的StackTrace可以看一下.
是的,你的理解没错,用LLVM库的话可以用这个方式Disable. 但是Clang也是LLVM库的user, 所以不去Patch Clang的话会导致Clang的CodeGen继续按照OpaquePointer来实现, 而混淆按照NonOpaquePointer来Transform, 而这至少以我个人的经验听起来不是个好主意, 尤其是如果后续增加更多Pass的话, 可能会影响其他Pass的Assumption, 也不符合LLVM16+的规划. |
正确的Disable其实也只需需要Patch源码的两处地方, 你本身就是整个LLVM的源码分发, 其实并不影响 |
我在Hikari原来的issue里面更新了两个链接, 是源码层默认禁用掉OpaquePointer的至少我认为正确的方式. 供参考 |
我会创建一个opaque pointers默认关闭的branch 2022.09.22 |
为啥要禁用 |
如果不禁用,一些功能不能正常使用,因为没有兼容Opaque Pointer |
已经在aed0a0f完全支持了Opaque Pointers 关闭Opauqe Pointers的branch将会在未来删除 |
大佬牛逼,请教下如何学习LLVM和混淆pass开发呢? |
我也不太明白 |
能给个联系方式么,遇到一个bug,直接发你demo |
-mllvm -opaque-pointers=false -Xclang -no-opaque-pointers
否则CFE的CodeGen走的还是OpaquePointer
同步更新到了 HikariObfuscator/Hikari#102
The text was updated successfully, but these errors were encountered: