Power configuration check can be more specific (not sure about potential false positives on desktops)

[mhdo298]

The current test in VMAware can probably be tightened to check if one of S0 or S3, along with S4 and S5, are enabled, instead of just any of S1-4 as of right now.

Most popular VM platforms don't have S3 or S0 sleep enabled by default for Windows (due to lack of support for these modes), while certain platforms like VMWare has S1 enabled for a standard Windows VM. KVM also has a flag to enable support for S4 sleep.

Conversely, most modern Windows laptops will support either S0 or S3, along with S4 and S5. I do not currently have a desktop system to test this on, but I presume this would be the same there. Would love to get more data on this, and if this check does not lead to false positives it could be a relatively difficult check to harden VMs against.

[NotRequiem]

checking S0 || S3 is ok
checking S0|S3 + S4 + S5 is risky, people can disable hibernation and some AoAc/S0-only hardware don't even define _S4 in DSDT aml

best is (S0 || S3) && (S4 || HiberFilePresent) -> physical
!(S0 || S3 || S4 || HiberFilePresent) -> vm if at least one of SystemS1 or SystemS2 is true
cases like S0 present but hibernate disabled; or S3 present but S4 absent; VMs explicitly exposing S3/S4; physical devices with S0 only and no hibernation, etc etc would be threated as physical

to bypass your NtPowerInformation hook on capemon someone would just need to directly/indirectly syscall NtPowerInformation rather than calling a stub inside ntdll.dll, might include a syscall core in vmaware 2.6.0

[mhdo298]

Yes user mode debuggers are definitely detectable with the techniques above, for example capemon can already be detected by al-khaser’s scanning memory for injected modules. I was just thinking that there might be a way to directly access the information with a more generic syscall/API call so that attempts to intercept them would be harder. I now see that at the end of the day there’s only a couple of syscalls with specific arguments that could get this information, and if someone patches the firmware then these checks will be bypassed all the same so there’s not much of a point.

The checks you’ve added are exactly what I meant in the original suggestion! Thank you for the fast and detailed response!

[NotRequiem]

Thank you for your suggestion!

[mhdo298]

I just re-read the snippet above and realized that QEMU/KVM will pass the above check since it has all S0-4 disabled. It is probably a good idea to add the current check back in as a case, since that check does detect QEMU's default config (maybe without the S4 check since S4 can be enabled).

[NotRequiem]

yes I'm still considering the current check before merging it to main, but by the moment i have no idea if i should keep the check for thermal zones in the ACPI (return (caps.ThermalControl == 0);) or just return true directly if S0 to S3 are disabled because most hardened setups just report the thermal capabilities and not the sleep states (which might generate false positives on a real world scenario)

[NotRequiem]

final suggestion:

const bool s0_supported = caps.AoAc;
const bool s1_supported = caps.SystemS1;
const bool s2_supported = caps.SystemS2;
const bool s3_supported = caps.SystemS3;
const bool s4_supported = caps.SystemS4;
const bool hiberFilePresent = caps.HiberFilePresent;

const bool is_physical_pattern = (s0_supported || s3_supported) &&
    (s4_supported || hiberFilePresent);

if (is_physical_pattern) {
    return false;
}

const bool is_vm_pattern = !(s0_supported || s3_supported || s4_supported || hiberFilePresent) &&
    (s1_supported || s2_supported);

if (is_vm_pattern) {
    debug("POWER_CAPABILITIES: Detected !(S0||S3||S4||HiberFilePresent) + S1|S2 pattern");
    return true;
}

const bool no_sleep_states = !s0_supported && !s1_supported && !s2_supported && !s3_supported;
if (no_sleep_states) {
    return true;
}

return (caps.ThermalControl == 0);