Not passing Al-Khaser test

[Samuil1337]

Dear Sir or Madam,

I hope this message finds you well. It has come to my attention that our beloved anti-detection patch is able to fool PaFish, but not the Al-Khaser tool.

First, I ran the program on bare metal and in the VM. Then I used diff to filter out the false positives. The results:

[*] Checking power capabilities                                                                    [ BAD  ]
[*] Checking Win32_CacheMemory with WMI                                                            [ BAD  ]
[*] Checking Win32_MemoryDevice with WMI                                                           [ BAD  ]
[*] Checking Win32_PortConnector with WMI                                                          [ BAD  ]
[*] Checking CIM_Memory with WMI                                                                   [ BAD  ]
[*] Checking CIM_PhysicalConnector with WMI                                                        [ BAD  ]
[*] Checking CIM_Slot with WMI                                                                     [ BAD  ]
[*] Checking Enum\IDE and Enum\SCSI entries for VM strings                                         [ BAD  ]
[*] Checking SMBIOS tables                                                                         [ BAD  ]
[*] Checking RDTSC Locky trick                                                                     [ BAD  ]

Here is a little bit more info about my test setup. My Libvirt domain XML looks like this: win11.xml I am also using the RDTSC patch by WCharacter on my custom-built Kernel. Obviously I have recompiled QEMU with this patch as well.

At first glance, we can immediately see that all of the WMI commands just check different sensors that do not exist in QEMU or are disabled by default. Implementing them in a separate patch should be possible though, because some of these values could be defined as constants. However, at the moment, I can't tell how one would add that to QEMU's source.

The power state check can be easily evaded by enabling <suspend-to-mem enabled="yes"/> and <suspend-to-disk enabled="yes"/> in the <pm> section. It unfortunately also checks whether thermal zones are enabled, which again, to my knowledge has to be implemented manually.

Although I have added multiple changes in the XML to spoof the SMBIOS, it seems as though the actual implementation of SMBIOS 3.0 is incomplete or somewhat incorrect, because the SMBIOS table check fails. It does not look for QEMU specific identifiers - which are 100% removed thanks to this patch - but analyses the SMBIOS structure. I don't know what exactly is wrong, but a fix may be dumping the host's DMI data (dmidecode --dump-bin), removing UUIDs and then providing it as an argument (qemu-x86_64 -smbios file=/path/to/file).

The SCSI entries are most likely checks for the fake chipset, which doesn't have a real controller. A solution might be passing through the SATA controller (Linux has to be installed on an NVMe that has it's own controller). Because that isn't viable to most, some superficial solution in QEMU would be preferable.

Interestingly enough, KVM and the RDTSC patch handle the timing based attacks quite well. Only the "Locky trick" still causes issues. We will have to research the emulated instructions that CloseHandle() executes and think about negating the side effects. However, I do wonder whether this would fall in the scope of QEMU anti detection, because this will most likely require changes in KVM itself.

Thank you for your time. I am looking forward to working together with this community, so this project can be further improved. There are some properties of the virtual hardware like fan speeds, voltages and the SMBIOS we still have to spoof, but we are getting there.

Yours sincerely, Samuil1337