VMAware (VM + Aware) is a cross-platform C++ library for virtual machine detection.
The library is:
- Very easy to use
- Cross-platform (Windows + MacOS + Linux)
- Features around 100 unique VM detection techniques [list]
- Features the most cutting-edge techniques
- Able to detect over 70 VM brands including VMware, VirtualBox, QEMU, Hyper-V, and much more [list]
- Able to beat VM hardeners
- Compatible with x86 and ARM, with backwards compatibility for 32-bit systems
- Very flexible, with total fine-grained control over which techniques get executed
- Able to detect various VM and semi-VM technologies like hypervisors, emulators, containers, sandboxes, and so on
- Available with C++11 and above
- Header-only
- Free of any external dependencies
- Memoized, meaning past results are cached and retrieved if ran again for performance benefits
- Fully MIT-licensed, allowing unrestricted use and distribution
Note
We are looking for Chinese translators. If you'd like to contribute with translating this README, feel free to give us a PR! Credit will be provided.
#include "vmaware.hpp"
#include <iostream>
int main() {
if (VM::detect()) {
std::cout << "Virtual machine detected!" << "\n";
} else {
std::cout << "Running on baremetal" << "\n";
}
std::cout << "VM name: " << VM::brand() << "\n";
std::cout << "VM type: " << VM::type() << "\n";
std::cout << "VM certainty: " << (int)VM::percentage() << "%" << "\n";
std::cout << "VM hardening: " << (VM::is_hardened() ? "likely" : "not found") << "\n";
}possible output:
Virtual machine detected!
VM name: VirtualBox
VM type: Hypervisor (type 2)
VM certainty: 100%
VM hardening: not found
This project also provides a handy CLI tool utilising the full potential of what the library can do. It also has cross-platform support.
Below is an example of a basic QEMU system with no hardening modifications on Linux.
To install the library, download the vmaware.hpp file in the latest release section to your project. The binaries are also located there. No CMake or shared object linkages are necessary, it's literally that simple.
However, if you want the full project (globally accessible headers with <vmaware.hpp> and the CLI tool), follow these commands:
git clone https://github.com/kernelwernel/VMAware
cd VMAwaresudo dnf/apt/yum update -y # change this to whatever your distro is
mkdir build
cd build
cmake ..
sudo make installmkdir build
cd build
cmake ..
sudo make installcmake -S . -B build/ -G "Visual Studio 16 2019"Optionally, you can create a debug build by appending -DCMAKE_BUILD_TYPE=Debug to the cmake arguments.
# edit this
set(DIRECTORY "/path/to/your/directory/")
set(DESTINATION "${DIRECTORY}vmaware.hpp")
if (NOT EXISTS ${DESTINATION})
message(STATUS "Downloading VMAware")
set(URL "https://github.com/kernelwernel/VMAware/releases/latest/download/vmaware.hpp")
file(DOWNLOAD ${URL} ${DESTINATION} SHOW_PROGRESS)
else()
message(STATUS "VMAware already downloaded, skipping")
endif()The module file and function version is located here
You can view the full docs here. All the details such as functions, techniques, settings, and examples are provided. Trust me, it's not too intimidating ;)
If you want to learn about the architecture and design of the library, head over to https://deepwiki.com/kernelwernel/VMAware
How does it work?
It utilises a comprehensive list of low-level and high-level anti-VM techniques that gets accounted in a scoring system. The scores (0-100) for each technique are given based on an objective criteria focused on detecting the most stealthy VMs by minimizing false positives as much as possible, and every technique that has detected a VM will have their score added to a single accumulative point, where a threshold point number will decide whether it's actually running in a VM.
Who is this library for and what are the use cases?
It's designed for security researchers, VM engineers, anticheat developers, and pretty much anybody who needs a practical and rock-solid VM detection mechanism in their project. The library is useful for malware analysts testing the concealment of their VMs and for proprietary software developers aiming to protect their applications from reverse engineering. It's an effective tool to benchmark how well a VM can hide itself from detection.
Additionally, software could adjust the behaviour of their program based on the detected environment. It could be useful for debugging and testing purposes, while system administrators could manage configurations differently. Finally, some applications might want to legally restrict usage in VMs as a license clause to prevent unauthorized distribution or testing.
There are also projects that utilise our tool such as Hypervisor-Phantom, which is an advanced malware analysis project that we helped strengthen their hypervisor environment and undetectability.
Why another VM detection project?
There's already loads of projects that have the same goal such as InviZzzible, pafish and Al-Khaser. But the difference between the aforementioned projects is that they don't provide a programmable interface to interact with the detection mechanisms, on top of having little to no support for non-Windows systems. Additionally, the VM detections in all those projects are often not sophisticated enough to be practically applied to real-world scenarios while not providing enough VM detection techniques. An additional hurdle is that they are all GPL projects, so using them for proprietary projects (which would be the main audience for such a functionality), is out of the question.
Pafish and InviZzzible have been abandoned for years. Although Al-Khaser does receive occasional updates and has a wide scope of detections that VMAware doesn't provide (anti-debugging, anti-injection, and so on), it still falls short due to the previously mentioned problems above.
While those projects have been useful to VMAware to some extent, we wanted to make them far better. Our goal was to make the detection techniques to be accessible programmatically in a cross-platform and flexible way for everybody to get something useful out of it rather than providing just a CLI tool. It also contains a larger quantity of techniques, so it's basically just a VM detection framework on steroids that focuses on practical and realistic usability for any scenario.
Wouldn't it make it inferior for having the project open source?
The only downside to VMAware is that it's fully open source, which makes the job of bypassers easier compared to having it closed source. However, We'd argue that's a worthy tradeoff by having as many VM detection techniques in an open and interactive manner rather than trying to obfuscate. Having it open source means we can have valuable community feedback to strengthen the library more effectively and accurately through discussions, collaborations, and competition against anti-anti-vm projects and malware analysis tools which try to hide it's a VM.
All of this combined has further advanced the forefront innovations in the field of VM detections much more productively, compared to having it closed source. This is what made the project the best VM detection framework out there, and bypassing it has shown to be an immense challenge due to the sheer number of sophisticated and never-before-seen techniques we employ that other VM detectors don't use whether open or closed source (to our knowledge).
In other words, it's about better quality AND quantity, better feedback, and better openness over security through obfuscation. It's the same reason why OpenSSH, OpenSSL, the Linux kernel, and other security-based software projects are relatively secure because of how there's more people helping to make it better compared to people trying to probe the source code with malicious intent. VMAware has this philosophy, and if you know anything about security, you should be familiar with the phrase: "Security through obfuscation is NOT security".
How effective are VM hardeners against the lib?
Publicly known hardeners are not effective and most of them on Windows have been beaten, but this doesn't mean that the lib is immune to them. Custom hardeners that we may not be aware of might have a theoretical advantage, but they are substantially more difficult to produce.
How is it developed?
Based on online research (ranging from science papers to things like private game hacking forums and discord servers), we try to identify the methods currently used to hide VMs and investigate generic detections capable of detecting them, while constantly tracking their activity to ensure we stay one step ahead.
Once we have developed production-level code, we upload it to the dev branch to start testing it in real environments, where products using our library on hundreds or even thousands of devices run our detection algorithms and silently alert us if a VM has been detected, to be later manually verified for false positives.
If we believe that false positives have been corrected based on experimental tests and online evidence in public documentation and databases, we merge the changes to the main branch, assigning the new detections a score, taking into account their effectiveness, reliability, and their operation in conjunction with the rest of the techniques.
Other situations (such as false flags, compilation errors, possible vulnerabilities, etc.) are immediately merged into the main branch.
Once the library has undergone sufficient modifications compared to previous versions, we place the library in the releases section, explaining these changes in detail.
What about using this for malware?
This project is not soliciting the development of malware for obvious reasons. Even if you intend to use it for concealment purposes, it'll most likely be flagged by antiviruses anyways and nothing is obfuscated to begin with.
We do not intentionally develop the library to try to stop or avoid EDR flags, such as using direct/indirect syscalling, inline hooking detection, and any other kind of malware evasion technique not related to hypervisor detection.
I have linker errors when compiling
If you're compiling with gcc or clang, add the
-lmand-lstdc++flags, or use g++/clang++ compilers instead. If you're receiving linker errors from a brand new VM environment on Linux, update your system withsudo apt/dnf/yum update -yto install the necessary C++ components.
If you have any suggestions, ideas, or any sort of contribution, feel free to ask! We'll be more than happy to discuss either in the issue or discussion sections. We usually reply fairly quickly. If you want to personally ask something in private, our discords are kr.nl and shenzken
For email inquiries: jeanruyv@gmail.com
And if you found this project useful, a star would be appreciated :)
- kernelwernel (Maintainer and developer)
- Requiem (Maintainer and co-developer)
- Check Point Research
- Unprotect Project
- Al-Khaser
- pafish
- Matteo Malvica
- N. Rin, EP_X0FF
- Peter Ferrie, Symantec
- Graham Sutherland, LRQA Nettitude
- Alex
- Marek Knápek
- Vladyslav Miachkov
- (Offensive Security) Danny Quist
- (Offensive Security) Val Smith
- Tom Liston + Ed Skoudis
- Tobias Klein
- (S21sec) Alfredo Omella
- hfiref0x
- Waleedassar
- 一半人生
- Thomas Roccia (fr0gger)
- systemd project
- mrjaxser
- iMonket
- Eric Parker's discord community
- ShellCode33
- Georgii Gennadev (D00Movenok)
- utoshu
- Jyd
- git-eternal
- dmfrpro
- Teselka
- Kyun-J
- luukjp
I am not responsible nor liable for any damage you cause through any malicious usage of this project.
License: MIT