"Devirtualization" in this post is something different, being an inverse of virtualization which is an obfuscation technique to hinder reverse engineering.
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.
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.
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.
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.
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.
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.
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.
The phrasing of the headline really does suggest strongly that this is going to be an article about compiler optimization!
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.
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.
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.
> 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.
[dead]
Bochs can use several BIOSes than its own ones.
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.
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.
I read this as "LLM powered authentication" and gasped on how ridiculous this sounds
I should get some sleep