REBlog
October 19th, 2007, 20:27
I was looking at a malware sample last week that used a variation of Joanna Rutkowska's infamous Red Pill (http://invisiblethings.org/papers/redpill.html) to determine whether or not the malware was being run from inside a Virtual Machine. Based on the Red Pill concept, the guest OS's IDTR should be different from the host OS's IDTR.
I was using Virtual PC to step through the malware sample in OllyDbg, with the goal of skipping the conditional-jump after SIDT led to the detection of my VM (see http://download.intel.com/design/Pentium4/manuals/25366720.pdf#page=275 for details on the SIDT instruction). You can imagine my surprise when SIDT returned 0x8003F400 as the base address of the IDT, which is the same base address of the IDT for my host Windows XP system!
My first thought was that maybe the Virtual PC team figured out some ingenious way to make this happen via the Virtual Machine Additions add-on (see http://www.microsoft.com/technet/prodtechnol/virtualserver/2005/proddocs/vs_tr_components_additions.mspx?mfr=true). So I uninstalled Virtual Machine Additions, rebooted, and tried again. To my continued surprise, OllyDbg was still showing the host OS's IDTR when stepping through the SIDT instruction on my guest OS.
After some more thinking, I thought, "maybe it has something to do with the fact that I'm single-stepping through SIDT in OllyDbg." To test this hypothesis, I set a breakpoint after the SIDT instruction, and ran the program from the start. Sure enough, SIDT returned 0xF9CB6440 as the base address of the IDT that time.
The whole trick behind the Red Pill is that VMs don't typically have the opportunity to intercept SIDT since it's not a privileged instruction. However, when the Trap Flag is set (due to single-stepping), Virtual PC intercepts the int 1 interrupt and can execute the current instruction however it pleases; when it has the opportunity, it will use the host's IDTR for the SIDT instruction.
Hopefully this knowledge will make the Red Pill a little easier for you to swallow (or spit-out if the Trap Flag is set).
http://malwareanalysis.com/CommunityServer/blogs/geffner/archive/2006/08/21/15.aspx
I was using Virtual PC to step through the malware sample in OllyDbg, with the goal of skipping the conditional-jump after SIDT led to the detection of my VM (see http://download.intel.com/design/Pentium4/manuals/25366720.pdf#page=275 for details on the SIDT instruction). You can imagine my surprise when SIDT returned 0x8003F400 as the base address of the IDT, which is the same base address of the IDT for my host Windows XP system!
My first thought was that maybe the Virtual PC team figured out some ingenious way to make this happen via the Virtual Machine Additions add-on (see http://www.microsoft.com/technet/prodtechnol/virtualserver/2005/proddocs/vs_tr_components_additions.mspx?mfr=true). So I uninstalled Virtual Machine Additions, rebooted, and tried again. To my continued surprise, OllyDbg was still showing the host OS's IDTR when stepping through the SIDT instruction on my guest OS.
After some more thinking, I thought, "maybe it has something to do with the fact that I'm single-stepping through SIDT in OllyDbg." To test this hypothesis, I set a breakpoint after the SIDT instruction, and ran the program from the start. Sure enough, SIDT returned 0xF9CB6440 as the base address of the IDT that time.
The whole trick behind the Red Pill is that VMs don't typically have the opportunity to intercept SIDT since it's not a privileged instruction. However, when the Trap Flag is set (due to single-stepping), Virtual PC intercepts the int 1 interrupt and can execute the current instruction however it pleases; when it has the opportunity, it will use the host's IDTR for the SIDT instruction.
Hopefully this knowledge will make the Red Pill a little easier for you to swallow (or spit-out if the Trap Flag is set).
http://malwareanalysis.com/CommunityServer/blogs/geffner/archive/2006/08/21/15.aspx