Fix for Timing: remove outdated CPUID timing check on modern Windows 26H1 due to VBS and Hyper-V

[IgorKorkin]

Remove outdated CPUID timing check on modern Windows rdtsc_diff_vmexit due to false positive.

• Tested Al-Khaser on Windows 25H2 and 26H1 (regular modern laptop, non-sandbox environment).
• On Windows 11 25H2/26H1, virtualization-based security (VBS) and Hyper-V are enabled by default on typical clean installs, placing a hypervisor layer under the OS even on bare-metal laptops.
• In this configuration, CPUID is trapped by the Windows hypervisor, so CPUID timing (rdtsc_diff_vmexit) reports a “virtualized” environment on non-sandbox systems.
• This check is outdated and misleading — it undermines the credibility of Al-Khaser’s detection results on modern Windows systems.
• To maintain accuracy and relevance, this check has been disabled from active test sets.
• Applied code style formatting.

Note: Two new detection techniques will be added in the next pull requests, so this removal will be compensated by fresh, more reliable checks.

26H1-results-al-khaser_x64.txt
26H1-Get-ComputerInfo.txt
26H1-systeminfo.txt

[NotRequiem]

no need at all

just check if you're running on top of a Hyper-V layer (type 1) or a Hyper-V VM (type 2), and if you're running under type 1, attempt to detect nested virtualization using a higher latency threshold. When KVM runs on top of Hyper-V for example you will hit 8k+ cycles or even more (not in all cases), being in a root partition alone (Hyper-V) will flag around 1k to 2.5k cycles without taking into account kernel noise, but you can reliably detect or discard from cpl3 when theres jitter/spikes due to an interrupt/dpc or something else, otherwise just flag the Hyper-V VM

[NotRequiem]

also no offense but this seems like blatant ai sloop

[IgorKorkin]

@NotRequiem

• Thank you! I get your point, yes, I use AI to fix my English, because I'm not a native speaker 🙂
• What you suggest is doable, but your checks mostly increase noise and instability in the results.
• My PhD was on the challenge of hypervisor detection using timing‑based heuristics
• You can find my results about detecting (and!) calculating numbers of nested bare-metal hypervisors here - Two Challenges of Stealthy Hypervisors Detection: Time Cheating and Data Fluctuations: paper, slides.
• It requires a lot of loops and computation to 100% detect hypervisors via timing-based heuristics, and such techniques are applicable only for lab experiments, rather than being a common must-have tool like Al-Khaser.
• These days, tons of enterprise users are actively working inside VMs running on top of hypervisors (cloud, VDI/DaaS, etc.), so simply “seeing” a hypervisor or higher CPUID/RDTSC latency is no longer a strong indicator of sandboxing by itself. A typical working environment for security experts at Huawei was a VDI desktop accessed via a browser (sometimes even chained into another VDI session and another 🙉) That’s why this particular CPUID/RDTSC timing check was removed.
• I hope it is clear now
• and let's add more simple and reliable checks for sandbox env!

[NotRequiem]

I've fully read the papers you had, and now I strongly believe you don't get the full picture of the idea at all, you don't need to give up on "Hyper-V + VBS"

What you suggest is doable, but your checks mostly increase noise and instability in the results.

I didn't even mention a single check that is being taken into account during calculations, all kernel noise discards are made after collecting information, I strongly discourage trying to make syscalls to compute interrupt information while you actively collect samples

I don't know where this project mentions that the only goal is to detect sandboxes, that routine covers VM detection as well, and timing attacks are the first thing one looks for when detecting hypervisors and/or VMs, I don't think the idea of this project is to actually have absolutely zero false flags but to give a detailed amount of information that can be lated manually reviewed, given the amount of false flags this project does not cover in real world scenarios, VM detections is just a side topic/feature on this project like with sandboxes.

You don't need a lot of computations (althought that word is extremely subjective) to expose vmexit latency while also ignoring the kernel noise itself, and I can provide evidence of more than 200000 machines running the same test and not having false flags. For reference, I've computed the following tests in this manner (in the case of Windows):

• having the check fully inlined and without performing any syscall from ntdll.dll
• _mm_lfence (ensuring the CPU pipeline is drained of previous loads before we start the clock)
• __rdtsc
• _ReadWriteBarrier() or asm volatile("" ::: "memory") (preventing the compiler from moving the __cpuid call before the t1 read)
• __rdtscp to cover CPU speculation, to let rdtscp internally wait until cpuid is executed rather than using another memory barrier
  _mm_lfence to ensure the read of t2 doesn't bleed into future instructions
• a stack dependency on register so the __cpuid((int*)regs, static_cast<int>(leaf)); call isn't skipped
• declare the registers as volatile so writes cannot be optimized out
• pre-allocate sample buffer and touch pages to avoid page faults by MMU during measurement (this doesn't count as a syscall during the cycle measurement even if there's a NtAllocateVirtualMemory call under the hood involved)
• ensure your thread is pinned to a single core with NtSetInformationThread. There are a lots of research involving creating two threads pinned to different vCPUs in order to do divergence tests that expose vmexit latency easily and/or detect TSC offsetting/downscaling, this just creates more noise and any guest TSC manipulation can be detected reliably with only one thread
• DO NOT increase thread priority, contrary to what a lot of people may think, this creates more noise and more chance of re-scheduling
• optionally calculate using pdh.h whats the "less-busy" physical core
• Correlate with an interrupt timer that does not depend on __rdtsc, such as QueryInterruptTimer, you can disassemble it yourself in kernelbase.dll and you will see that it just accesses KUSER_SHARED_DATA, a virtual read-only page provided by a kernel mapping, with intervals of 100 nanoseconds. This is specially helpful as its resolution is 100 nanoseconds and the kernel routine that backs up this api runs at CLOCK_LEVEL(13), only preempted by IPI, POWER_LEVEL and NMIs
• a voluntary context switch to get a fresh quantum calling NtDelayExecution, taking into account the default resolution of 64Hz (15.625ms)
• a warm up to exercise different paths in the kernel routine that backs cpuid
• run the loops
• collect enough samples doing different iterations at times, you could even detect if the sample distribution is uniform enough but normally is not needed

Now perform a simple mathematical algorithm I've developed during my experimental phases based on clustering and make it the function code you will use to discard noise (if any), if you followed the previous steps you will unlikely have the 50% of your samples "poisoned" or "dirty":

Let the input be a finite multiset of nonnegative integers (latencies)
S = {x1, …, xN} ⊂ Z_{\ge 0}, with N ≥ 0.
If N ∈ {0, 1} the function returns the trivial values 0 or x1. For N ≥ 2 the algorithm proceeds as follows.
Order statistics.
Sort the samples into nondecreasing order and denote the order statistics
s_(1) ≤ s_(2) ≤ … ≤ s_(N).

Form the vector of consecutive differences (spacings)
d_i := s_(i+1) − s_(i), for i = 1,…,N−1.
This is the discrete derivative of the empirical distribution in the sorted domain and highlights places where sample density drops.

Compute the median of the gaps, in previous tests I had used `std::max/std::min` to compute averages, which of course would be worse,
dx := median{d_1, …, d_{N−1}}.
The median is a robust estimator of the typical local spacing and resists a small number of very large spacings.

Define a threshold
t := max{G_min, ceil(c ⋅ dx)},
where c = GAP_FACTOR = 5.0 and G_min = GAP_ABS_MIN = 50 in the code. Interpretation: a gap is considered a separator only if it is at least c times the median spacing (or at least the absolute minimum).

Let
k := min{ i+1 | d_i >= τ },
taking k = 0 if no such index exists. Intuitively, if the ordered samples have a large upward jump at index i, then the left block { s_(1), …, s_(i) } is the low-latency cluster (the presumed “clean” mode) and the right block is outliers/jitter. If no large gap is found, the algorithm falls back to a low-percentile split:
k <- max{ 1, floor(p_low ⋅ N) },
where p_low = LOW_PERCENTILE = 0.10.

If the chosen cluster size k is too small relative to N (i.e. k/N < f_min with f_min = MIN_CLEAN_FRACTION = 0.05), then replace k by the low-percentile fallback size floor(p_low ⋅ N). This prevents pathological splits that isolate only one or two points as the "clean" cluster when the data are more uniformly spread.

Let the cluster be C := { s_(1), …, s_(k) }. The algorithm returns a robust estimate μ̂ of the cluster central tendency defined by:
If k ≥ 10: use an α-trimmed mean with α = TRIM_RATIO = 0.10.
Concretely, t := floor(α ⋅ k) and
ux= (1 / (k − 2t)) ⋅ sum_{i = t+1}^{k−t} s_(i).
If trimming removes all observations (degenerate case k − 2t <= 0), the code instead returns the cluster median.
• If k < 10: return the cluster median:
if k is odd: ux= s_(ceil(k/2));
if k is even: ux= (s_(k/2) + s_(k/2 + 1)) / 2.

Optionally you could - or not, if you want more precision - to round the estimator to an integer

Even if this seems a lot, it does run in less than a second. You could even improve the algorithm above with a Gaussian + heavy-tailed/uniform with EM and take the smaller-mean component as "clean", because the only downside (which doesn't affect anything in practical scenarios) is that if the "clean" latency is not the leftmost mode, you could end up choosing the lower cluster incorrectly, but that's the point of doing a lot of setup before running anything.

Now to provide experimental evidence and to ensure i'm completely neutral and not just showing the "good part", I've choosen a few thousands (around 10k+ CPUs, from every type of SKU and vendor, manufactured this year or even 20-30 years ago) that include proofs of false flags in the timing checks attached to this message, that were fixed during these years of testing and testing:
report (1).json
report (2).json
report (3).json
report (4).json
report (5).json
message.txt

Not to mention that even if for some strange reason you get a FP, you will not take it immediately as a red flag, it's just an indicator/sign of hypervisor exposure, the detection should still collect more samples, but it doesn't justificate the complete removal of the routine being one of the most helpful indicators (and hardest) to patch. Nevertheless, you can get reliable detections from UM of running in a sandbox/hypervisor which tries to hide itself from timing detections, and that would immediately mean you're not under some kind of "exotic enterprise environment" like the ones you mention, which of course goes out of the scope for this message

[IgorKorkin]

@NotRequiem

• Thank you for the detailed technical proposal and experimental data — I appreciate the depth of your research on noise filtering and vmexit latency measurement
• I think your idea is good for a separate Pull request! I can help you with that!
• I'm happy that now we both agree with the point: hypervisor detection ≠ sandbox env detection

[NotRequiem]

again, the point is that the detection you're trying to remove is not primarily focused towards sandbox env detection, and the argument of "the technique is unreliable because Windows can run on Hyper-V" is wrong, the code (if anything) needs to be improved, not completely removed, because it provides valuable information of the environment

even disabling the technique in certain circumstances would be more beneficial, such as only running the rdtsc check if you detect that you're NOT running in the root partition, which is just a single cpuid call on the hypervisor leaf (ebx on 0x40000003)

[IgorKorkin]

@NotRequiem

• I got your point and completely agree with you, we shouldn't remove rdtsc_diff_vmexit, it may be useful in some specific rare cases.
• Pull request has been updated: add --vmexit-latency flag.