v2.8.0 🎉 #714
NotRequiem
announced in
Announcements
v2.8.0 🎉
#714
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
2.8.0 Release
Additions
VMAware is now available in more programming languages. Rust, JS and Ruby are officially supported.
Official support for multiple architectures:
amd64, arm64, armhf, armel, i386, mips64el, ppc64el, riscv64, s390x.Windows TUI: New CLI design for Windows. You can enable it using the
--richargument.VM::TPM: Analyzes measured boot logs exported by the TPM, detecting hardcoded memory bounds of the SEC and PEI execution phases of certain OVMF builds, and flagging physical CPUs not providing a real manufacturer signature or platform GUIDs directly to PCR 0 as suspicious.VM::SINGLE_STEP: Detects whether a hypervisor delays trap flags over exiting instructions. It sets the trap flag viaPUSHFQ/POPFQ(orPUSHFD/POPFDin 32-bit mode) and executes a vmexiting instruction. The check expects a single-step exception (EXCEPTION_SINGLE_STEP/#DB) to trigger immediately on the vmexiting instruction. If a hypervisor incorrectly delays the trap flag, execution falls through to an invalid opcode (0xC7 0xB2), triggering an undefined opcode exception (EXCEPTION_ILLEGAL_INSTRUCTION/#UD) instead.VM::EIP_OVERFLOW: Detects whether a hypervisor does not correctly emulate instructions in compatibility mode. This is checked by transitioning to 32-bit compatibility mode using anIRETQinstruction and attempting to executeCPUIDplaced at the boundary of the 32-bit address space (0xFFFFFFFE). If correctly handled, the instruction pointer wraps to0x0and triggers an access violation (EXCEPTION_ACCESS_VIOLATION); incorrect emulation fails to truncate the instruction pointer. For example, if the hypervisor only handles 64 bits, it would be at0xFFFFFFFE + 2 = 0x100000000.VM::INTERRUPT_SHADOW: Detects if a hypervisor does not properly restore or respect the interruptibility state (interrupt shadow) after a VM-exit. It modifies the trap flag usingPUSHF/POPFand blocks debug exceptions for one instruction usingMOV SSbefore executing a vmexit. On bare metal, the single-step exception (EXCEPTION_SINGLE_STEP/#DB) is suppressed during the shadow and only fires afterward, whereas hypervisors like KVM trigger the exception early.VM::SVM_EXCEPTIONS: Detects whether a hypervisor leaks EFER.SVME into guest context via the SVM instruction fault type. It attempts to execute SVM instructions (VMRUN,VMLOAD,VMSAVE,CLGI,INVLPGA) under conditions where SVM capabilities are hidden. When SVM is disabled, these instructions must trigger an undefined opcode exception per the AMD's APM (EXCEPTION_ILLEGAL_INSTRUCTION/#UD). If a General Protection fault exception occurs when Hyper-V or other legitimate Windows virtualization components are not present, it indicates some other privileged component (a hypervisor) enabled SVM.VM::BOOT_LOGOandVM::DISK_SERIALsupport for Linux.VM::CGROUP: Detection for cgroup paths in/proc/self/cgroup.HYPER_X: Checks for whether a hypervisor is nested within a Hyper-V partition. Checks for Hyper-V enlightenments on guests.VM::EXPERIMENTALand--experimentalCLI argument. Disables execution of techniques marked as experimental/untested.Note
For Intel users, CPU-based techniques will need a patch in their respective hypervisors in order to bypass.
For AMD users, most of the detections can be passed by disabling the CPUID interception bit.
Improvements
VM::TIMER: Accuracy was improved over 517% after measuring billions of runs in more than 4000 machines.For Intel: All the bypasses explained in the 2.7.0 release were detected.
RDRAND/RDSEEDin order to make impossible to predict the exact moment where VMAware is measuring its reference instruction, and explictly detect pauses by implementing a communication protocol between all the threads timing vmexit overhead.CPUID exit from guest -> L0 (KVM with fast CPUID handlers) -> return cached data to L2.For AMD: Accuracy was improved, but bypass detections were not.
VM::SVM_EXCEPTIONS), or to run a Hyper-V nested setup.Caution
It is highly advisable to test
VM::TIMERusing a Release build, not a Debug build. To see debug outputs on a Release build, compile the binary using the__VMAWARE_DEBUG__macro.VM::is_hardened(): Improved hardened environment detection accuracy.VM::DBVM: Stronger detections for Dark Byte's VM:Dr6andDr7states, andICEBPexception probing.VM::HYPERVISOR_HOOK: Stronger detections for EPT/NPT hooking via race-conditions against hypervisors, by overwritting virtual memory pages that may be hooked to intercept hardware breakpoints.VM::PCI_DEVICES: Added checks for PCI Subsystem IDs.VM::ACPI_SIGNATURE: Now queries all ACPI nodes instead of display device paths only. Added more detections:VM::FIRMWARE: Added more detections:VM::CLOCK: Improved PIT system timer presence detection.VM::AZURE: Improved execution performance.VM::KVM_INTERCEPTION: Improved stability by flushing instruction cache before attempting to check whether KVM attempts to patch a mismatched hypercall instruction.CLI modularization into several C++ source and header files.
Fixes
VM::BOOT_LOGOfalse flagging some legitimate MSI boards due to an update in VirtualBox repository.VM::TIMERfalse flagging some AMD CPUs due to a delta mismatch between XSS states, falsely believing a hypervisor with CPUID interception disabled was present.Removals
VM::EDID: Not reliable enough for VM detection.VM::DEVICE_STRING: Not reliable enough for VM detection.VM::NSJAIL_PID: Decayed to general container brand.FWCF. False flags on some OEMs, like on HP ProBook 445 G8 Notebook.Note
Techniques are not removed because they're "bypassed". Techniques are removed if they're unreliable for VM detection. It is highly recommended to test the concealment of your VM using only the latest version of VMAware.
Secondary Changes
VM::TIMER(which runs at the end). Modified score of several techniques to improve accuracy.brandsnamespace.Ongoing Research
Since I'm on vacation for a few months, I now have more free time to work on the project, so new versions of the library will be released more frequently.
Currently, I'm focusing on the following for the next 2.9.0 and 3.0.0 releases:
Software TPMs can be detected simply because they will never posses a private EK chained to a valid certification authority. Someone can dump a legitimate public EK certificate and public key from a physical motherboard, but they will never be able to leak a private EK (unless there's some heavy vulnerability in some TPM/CA) or brute-force it (unless you got a quantum computer). Therefore, even a user-mode app can do a proof-of-possesion challenge. The idea is to simulate the
TPM2_MakeCredentialprotocol in VMAware:RSA-OAEPencryption in the ephemeral seed using the spoofed EKPub as the standardIDENTITYlabel.KDFakey derivation to derive a 128-bit AES symmetric key (STORAGE) and a 256-bit HMAC key ((INTEGRITY).AES-128-CFB.HMAC-SHA256signature over the encrypted nonce and theAIKname.TPM2B_ID_OBJECT, then VMAware issues the command to the TPM.If you passthrough your physical TPM, since PCRs can't be overwritten but extended, they will also contain the PCRs of the host, not the ones from your VM only. After reconstructing the TCG logs from the TPM itself, and comparing it to the first PCRs, you will always detect a mismatch. The TPM 2.0 specification also provides ways to quote it and receive a signed response using an attestation identity key, which prevents spoofing.
Many would say TPMs are the kind of hardware devices specifically manufactured to detect these kind of things, and it will the new meta for the next releases of VMAware.
More aggressive checks will be added. Some DSDT checks are hard to patch because the DSDT is executable ACPI bytecode that the guest OS interprets at boot. It's becoming easier to find detections that break machines entirely after bypassers try to modify a DSDT signature that it's revealing the presence of their VM. It's not the first time a "safe-looking" edit can cause missing devices, failed boot, broken power management, or VM instability in general. Complex heuristics on this ACPI table are the new target for firmware checks.
To bypass some hypervisor detections, and since many anticheats require HVCI at some point, it's starting to be a must. Althought many techniques of VMAware can detect nested virtualization indirectly, there's only one weak, specific check for this case, which relies only on documented CPUID leaves. Therefore, ongoing research is focusing on looking for architectural, hard-to-spoof mismatches between a host running Hyper-V only, and a VM running inside Hyper-V + another L0 hypervisor.
VirusTotal Results and Executables
https://www.virustotal.com/gui/file/24bccc9e1a7af1e1d97d22bdb74412692c7a57cb6aec63ccb48b1b28e0f84678?nocache=1
All the binaries were generated in GitHub's CI/CD purely from the source code here.
Contact
For any inquiries, contact us on Discord at
shenzken, or email us at vmaware.support@gmail.com.This discussion was created from the release v2.8.0 🎉.
Beta Was this translation helpful? Give feedback.
All reactions