LLVM-powered devirtualization

[sanxiyn]

In compiler context, "devirtualization" I encountered usually meant compiling a virtual call to a direct call. See for example "Devirtualization in LLVM and Clang" on LLVM blog: https://blog.llvm.org/2017/03/devirtualization-in-llvm-and-c....

"Devirtualization" in this post is something different, being an inverse of virtualization which is an obfuscation technique to hinder reverse engineering.

[marssaxman]

The phrasing of the headline really does suggest strongly that this is going to be an article about compiler optimization!

[anthk]

Also, Bochs can fool most VM detectors as it can emulate a whole CPU in software, but an i7 might be able to run a fully emulated Pentium 4 based computer with ease in almost real time. But Bochs' debugger can do crazy things to most malware and propietary obfuscators.

[poincaredisk]

I find that hard to believe. Bochs is trivial to detect, unless you heavily patch it, then it's still detectable (for example, by leveraging known bugs/mismatches with a real CPSs). And that's just a tip of the iceberg as far as antivm goes.

But I agree that many detectors used by malware don't expect Bochs and thus don't detect it.

[mshockwave]

I wouldn't recommend using the term "devirtualization" here, as that term has been used to refer simplifying C++ virtual function calls (into normal function call) in LLVM. And such optimization has been turned on by default for quite some time.

[PoignardAzur]

Interestingly, a lot of the techniques this article describes are also used in fuzzing. I wonder how much overlap there is between fuzzing and devirtualization.

[efilife]

I read this as "LLM powered authentication" and gasped on how ridiculous this sounds

I should get some sleep