Virtualization and Sandbox Detection

We are going to use Microsoft Visual Studio 2005 IDE, but 2008/2010 also works. The programming language will be C#. Detecting when we're "inside" a virtualized OS or when our software is run within a sandbox relies mostly on knowing the properties of those host applications (such as Virtual PC, VirtualBox, Anubis). After that, detecting those running processes is child's play to any programmer.

Due to the nature of the article, we're feeling compelled to mention that this article is only for educational purposes and what you plan to do after the detection routines is completely up to you. Therefore, please; with all due respect, let's stick to the positive side and think about the ways you can improve your software whenever virtualization is detected-to offer an even better user experience for the users.

Moving on, there is another reason why we may want to implement these detection routines. For example, perhaps the nature of the packets our software may transfer is sensitive and we would not like the user to be able to sniff, intercept, and examine them. Perhaps we don't want the user doing this because we would risk the packets' future validity and integrity, since the user may also manipulate their content -- you name it. The possibilities are endless.

As of late, malware has pretty much evolved and has even begun implementing similar sandbox detection routines. But please do keep in mind, we're focusing on how to improve our software applications, and I'm convinced our readers are all legit. So let's remain ethical-and focus on the beauty of coding. 

Now let's get to work.

Fire up your IDE and start up your C# project. You may want to add these into your existing project or start a new one if you're just experimenting and learning just for the sake of coding. That's great, too. We're going to use the following namespaces.

using System;

using System.Diagnostics;

using System.IO;

using System.Threading;

using System.Windows.Forms;

using Microsoft.Win32;

Now let's create an internal class that's called, say, DebugDetection, or anything that rings a bell for you. The structure of our application will be simple. Within this class we're going to enumerate our DetectSoftwareName() functions (there will be as many of them as you want to implement), and then another Detected() function that will be called as soon as one of those detection routines yields a positive result.

In order to easily detect the running processes, we have the following function. As you can see, we're basically querying all of the running processes via GetProcesses() function and then looping through the property to see whether the "process" string we're looking for is found within the active processes. It returns a boolean.

public static bool procIsRunning(string process)

{

foreach (Process p in Process.GetProcesses())

if (p.ProcessName == process)

return true;

return false;

}

Before we begin to code each of the detect-software functions, let's present the Detect() function that's called right after one of the virtualization applications or debugging sandboxes is found. Here we will display a message-box with the result. This is the place where you need to add your code that is applied in the case of abstract executions.

private static void Detected()

{

MessageBox.Show(

"Abstract execution is detected. You are running this software either within a virtualization or sandbox environment.",

"Critical Error!", MessageBoxButtons.OK, MessageBoxIcon.Error);

}

Now that our application is somewhat ready, let's present a detection routine, too.

private static bool DetectVPC()

{

if (Process.GetProcessesByName("vpcmap").Length >= 1 & Process.GetProcessesByName("vmsrvc").Length >= 1)

return true;

else

if (Process.GetProcessesByName("vmusrvc").Length >= 1)

return true;

return false;

}

Basically what the above snippet does is pretty simple. Virtual PC can be detected by the running processes vpcmap.exe, vmsrvc.exe, and vmusrvc. These are widely documented and necessary for a successful execution within Virtual PC. For example, these are required by a folder sharing service that runs due to Virtual Machine Additions.

Since the length is higher than or equal to 1, this means that at least one instance of the process is found to be running. And if so, the DetectVPC function returns true. I'm sure this also gives you ideas for how to detect various other processes. Heck, you may want to implement a DetectSelf() routine as well, so your software cannot be launched twice at the same time. These all depend on the scenario and what you want.

Starting from the next page we will get into more detection routines.

Detecting VirtualBox is easy. There is a service called "VBoxService," and we just need to check whether that service is up and running. If so, we're inside a VM. Simple.

private static bool DetectVBox()

{

if (prcIsRunning("VBoxService"))

return true;

else

return false;

}

At the beginning of the article we briefly mentioned the reasons why one might want to detect Wireshark, which is the most popular packet sniffing and analyzing tool. However, we suggest that you always use a strong layer of encryption or some sort of packet encapsulation so you don't rely just on detecting sniffers. Protection is always a better technique than just this workaround. But here's the snippet that does the job.

Wireshark can be identified with the "wireshark.exe" process. We check for its existence.

private static bool DetectWireShark()

{

if (procIsRunning("wireshark.exe"))

return true;

else

return false;

}

Another really solid way to identify a virtualized environment is based on their HDD model names. These are something along the lines of the list below:

*VIRTUAL* to detect "VIRTUAL HD"

*VMWARE* to detect "VMWARE VIRTUAL IDE HARD DRIVE"

*VBOX* to detect "VBOX HARDDRIVE"

*QEMU* to detect "QEMU HARDDISK"

Basically, if you can list the HDD properties and check for those values, if found, you can bet that its being run within a virtual machine. Find the way to implement this. For instance, you could use the DeviceIoControl function. For another solution to detect VMs, especially those running on VMware and Virtual PC, check this CodeProject article. There's another blog post here that suggests a different path. And also this page.

Moving on, let's see a couple of techniques for detecting sandboxing environments. In short, "sandbox" is a computer security term that means a tightly-secured environment where the analyst can examine and analyze the behavior of an application. These are most often used to detect malware, since no harm is possible inside a sandbox.

Unfortunately, the way these sandbox tools work is predictable. That means each of them has a unique way in which it can be identified really easily. Anubis, for example, can be recognized based on the "76487-337-8429955-22614" ProductId subkey located at HKMLSoftwareMicrosoftWindows NTCurrentVersion - in the Windows Registry.

Here's the code snippet that detects Anubis.

private static bool AntiAnubis2()

{

RegistryKey regProductID = Registry.LocalMachine.OpenSubKey("SOFTWAREMicrosoftWindows NTCurrentVersion", false);

object pid = regProductID.GetValue("ProductId");

string id = "76487-337-8429955-22614";

if ((string) pid == id)

return true;

return false;

}

Using the exact same snippet, you can detect both JoeBox and CWSandbox. These have the following ProductId strings, respectively: 55274-640-2673064-23950 and 76487-644-3177037-23510. Right now these are working, but hopefully in a future version they will add some level of complexity or randomness to make detection at least a bit tougher if not impossible. That would be great.

Detecting Sandboxie and ThreatExpert is also possible. Here's a challenge for you. There will no snippet presented on how to do this, but the hint is - their dynamic link library files are sbiedll.dll and dbghelp.dll, respectively. You just need to identify them.

As you can see, we've reached the end of this article. Hopefully you now have an idea of how to detect the existence of virtual machines and sandbox environments.

If you think about it, these implementations are truly nothing but pieces of cake. It's no wonder lots of malicious code lurks on the Internet without being able to really be identified. And that's why some respectable companies are using REAL systems (read: physical machines!) on which experts are working to diagnose issues.

The real purpose of this article was to give you a sense of how to do these and also present the real security threat that lies therein. Of course, things may change, and better yet, should change, but still, the real way to identify whether execution is being done inside an abstract environment is with assembly code. But that takes time to perfect.

As mentioned earlier, we hope you have learned of these detection coding routines and throughout your software development career. We're sure you will have plenty of occasions to use the described detection mechanisms, or perhaps other, better ones; it is hope that this article has given you plenty of food for thought. So good luck coding!

In closing, I'd like to invite you to join our experienced community of technology professionals on all areas of IT&C starting from software and hardware up to consumer electronics at Dev Hardware Forums. As well, be sure to check out the community of our sister site at Dev Shed Forums. We are friendly and we'll do our best to help you.