7 ms·

LLVM-powered devirtualization

245 points by dddnzzz334 2y ago

anthk 2y ago
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 2y ago
  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.
  - anthk 2y ago
    Bochs can use several BIOSes than its own ones.
  - ronsor 2y ago
    > leveraging known bugs/mismatches What if a real CPU ends up having a similar bug? The more detection tricks you try, the higher the rate of false positives will be. Bochs emulation side-steps most VM detection because it's not a VM. You can't even use the CPUID/VMEXIT timing detection trick because it's all emulated.
    - journey0 2y ago
      [dead]
  - jchw 2y ago
    Actually, I believe it's true. It's not that detecting Bochs is necessarily hard, it's just that it's probably not on most people's radars. I had similar success evading anti-VM detection by just simply using Qemu (without KVM) instead of VMware a while ago. (Long enough ago that I still used VMware, I suppose.) If there were an anti-VM cat-and-mouse game with Qemu/Bochs/etc. that evolved beyond primitive string searches and the like, CPU emulation would likely do a lot better against anti-VM technology. I suspect this is the same thing that makes Unicorn Engine and Qiling fairly effective for analyzing obfuscated code.
PoignardAzur 2y ago
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.
sanxiyn 2y ago
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-clang.html 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 2y ago
  The phrasing of the headline really does suggest strongly that this is going to be an article about compiler optimization!
mshockwave 2y ago
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.
efilife 2y ago
I read this as "LLM powered authentication" and gasped on how ridiculous this sounds I should get some sleep

245 points by dddnzzz334 2y ago

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 2y ago
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.
- anthk 2y ago
  Bochs can use several BIOSes than its own ones.
- ronsor 2y ago
  > leveraging known bugs/mismatches What if a real CPU ends up having a similar bug? The more detection tricks you try, the higher the rate of false positives will be. Bochs emulation side-steps most VM detection because it's not a VM. You can't even use the CPUID/VMEXIT timing detection trick because it's all emulated.
  - journey0 2y ago
    [dead]
- jchw 2y ago
  Actually, I believe it's true. It's not that detecting Bochs is necessarily hard, it's just that it's probably not on most people's radars. I had similar success evading anti-VM detection by just simply using Qemu (without KVM) instead of VMware a while ago. (Long enough ago that I still used VMware, I suppose.) If there were an anti-VM cat-and-mouse game with Qemu/Bochs/etc. that evolved beyond primitive string searches and the like, CPU emulation would likely do a lot better against anti-VM technology. I suspect this is the same thing that makes Unicorn Engine and Qiling fairly effective for analyzing obfuscated code.

PoignardAzur 2y ago

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.

sanxiyn 2y ago

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-clang.html 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 2y ago
The phrasing of the headline really does suggest strongly that this is going to be an article about compiler optimization!

mshockwave 2y ago

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.

efilife 2y ago

I read this as "LLM powered authentication" and gasped on how ridiculous this sounds I should get some sleep