模仿(抄袭)张总Hlkari出现了问题

-S -emit-llvm查看.ll文件是混淆成功的, 为啥-S查看.s或者最终生成.exe却又被优化掉了呢?
我可以确定我的pass是在optimize后做的了 :sweat_smile:

照着抄都不会

1 Like

冷知识:
冷知识:

啥玩意啊, 我只是开了指令替换, .ll是替换了的, .s又被优化掉了, 把pass移后到addPassesToGenerateCode也不行 :rofl:

不要把Transform Pass丢进Backend啊你这家伙

加个微信细说

IR混淆成功, 并且可以确定是后续被优化掉了, 关闭优化-O0生成的.s就是混淆的, -O3就回去解放前了 :rofl:

开源版是没做对抗优化的,所以要求流水线调度上的一些设计

As for how to workaround the optimizations “properly”, that requires a LOT more than running around randomly inject passes into the pipeline and expects it to work as intended

一种很偷懒的方案 F.addFnAttr(llvm::Attribute::OptimizeNone) :rofl:
:thinking:能不能在所有优化pass之后再做混淆?

:arrow_up:
所以要求传O0也是为了类似的目的。

:skull_and_crossbones:
难搞, CodeGen里的pass是MachineFunctionPass, 优化的对象不是IR了, 所以似乎没有办法启用Target Machine的优化了

可以,建议看看后端

TargetMachine里有个可选的Hook在DAGConstruction之前跑Pass

llc -filetype=obj -debug

按照经验TargetPassConfig::addIRPasses 应该没有什么负责优化的Pass

有的, 比如X86PassConfig::addIRPasses里就有AtomicExpandPass、X86PartialReductionPass :thinking:
简单粗暴TM->setOptLevel(CodeGenOpt::None)可以解决问题, 但目前的想法是尽可能多的优化后再进行混淆 :laughing:

AtomicExpand不是拿来做优化的。。。。。。

其实到现在我还没确定是哪个pass把我的混淆优化掉了 :rofl:

addIRPasses里多加几个printpass就知道了