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

[zhaodice]

hello, did you see my rdtsc spoofer? https://github.com/zhaodice/KVM-RDTSC-SHIELD , it is a kernel driver . I provided a kernel patch , add some "easy hook point" for my driver, in case of reboot ( just unload and load driver to update my code) I provided a kernel driver (.ko) , load it , it will hook the "easy hook point" to control rdtsc

how about it?

[Samuil1337]

Thanks for the heads up. I haven't looked at this particular implementation and because it looks more sophisticated, I am not sure if I will be able to get it working quickly. Can you please clone https://github.com/LordNoteworthy/al-khaser and then open it up in Visual Studio (NOT CODE!). If you have installed all the SDKs for desktop apps, you should be able to compile and run it within seconds of clicking the green play button. Pro tip, I would set delayInSeconds within the main file to 60, so you don't have to wait an hour. It would be great help, if you could do that for me. Thanks. I also tested whether "Checking power capabilities" is OK after enabling supend to RAM or disk and it is! So we can cross that out of the list.