[HN Gopher] LLVM-powered devirtualization
       ___________________________________________________________________
        
       LLVM-powered devirtualization
        
       Author : dddnzzz334
       Score  : 234 points
       Date   : 2024-11-26 12:38 UTC (1 days ago)
        
 (HTM) web link (blog.thalium.re)
 (TXT) w3m dump (blog.thalium.re)
        
       | anthk wrote:
       | 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 wrote:
         | 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 wrote:
           | Bochs can use several BIOSes than its own ones.
        
           | ronsor wrote:
           | > 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.
        
           | jchw wrote:
           | 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 wrote:
       | 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 wrote:
       | 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 wrote:
         | The phrasing of the headline really does suggest strongly that
         | this is going to be an article about compiler optimization!
        
       | mshockwave wrote:
       | 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.
        
       ___________________________________________________________________
       (page generated 2024-11-27 23:02 UTC)