hidevm sur Windows 11 et Windows 10 : un chiffre hexa manquant, les offsets fastprox.dll et une course sur ntdll.dll

Catégorie : DRAKVUF

Résumé

Le plugin hidevm de DRAKVUF masque la VM au malware, entre autres en réécrivant les requêtes WMI Win32_PerfFormattedData* au passage dans fastprox.dll. Sur Windows 11, il ne produisait aucun événement, sur les six builds, sans erreur. Le billet suit l'enquête dans l'ordre, avec ses fausses pistes : un scénario de test qui ne pouvait pas marcher, LibVMI qui classe Windows 11 en Windows 10, un hook posé sur du code jamais exécuté, un soupçon de course dans la pose des hooks, et finalement une constante 0xFFFFF7800000000 à 15 chiffres au lieu de 16. Ce bug était dans main depuis le début, sous --hidevm-delay. Au passage : les offsets ExecQuery et ExecQueryAsync de fastprox.dll pour les six builds, une vraie course dans libusermode qui abandonnait un processus pour toujours, et la suite sur 14 builds Windows 10.

Suivi upstream : drakvuf#1881 (hidevm Windows 11, fusionnée le 30/09), drakvuf#1882 (course ntdll, fusionnée le 30/09), issue drakvuf#1883 (commentaire Windows 10 du 06/10). La PR Windows 10 n'est pas ouverte.

Environnement

Hôte habituel (Xeon E5-2683 v4, 32 Go, Debian 13, Xen 4.21.0, altp2m=1, viridian=0, cpuid="host,hypervisor=0", SMBIOS Dell OptiPlex 7090, réseau isolé). DRAKVUF main 071b0f2, puis b2f64d8 pour Windows 10. Six VM Windows 11 : 21H2 (22000), 22H2 (22621), 23H2 (22631), 24H2 (26100.1742), 25H2 (26200), 26H1 (28000), snapshot after-install-cold chacune.

1. Le symptôme

-a hidevm : 0 événement sur les six builds, quelle que soit la requête WMI injectée. Pas d'erreur, pas de crash, rien.

2. L'enquête, dans l'ordre

Le scénario de test ne pouvait pas marcher. Première requête injectée : Get-WmiObject -Namespace root/wmi -Class MSAcpi_ThermalZoneTemperature. Résultat écrit dans C:\Users\Public\wmiresult.txt, relu avec guestfish : Not supported. Le matériel QEMU/Xen n'expose aucune zone thermique ACPI, la requête échoue avant d'atteindre l'IOCTL que hidevm surveille. Ça disculpe le scénario, ça ne valide rien.

Relire la PR d'origine. hidevm (#1499) a trois mécanismes indépendants : l'avance de TickCount via --hidevm-delay, le hook de IWbemServices::ExecQuery dans fastprox.dll qui réécrit les requêtes Win32_PerfFormattedData* et Win32_PerfRawData* vers Win32_BIOS, et le hook de NtDeviceIoControlFile en trois étapes pour la zone thermique. J'avais confondu les deux derniers.

LibVMI classe Windows 11 en Windows 10. gdb sur win_ver avec 22H2 : VMI_OS_WINDOWS_10. pe2version() ne voit que 10.0 et ntbuild2version() s'arrête à 19041. Le switch prend la branche Windows 10 et pose le hook à 0x2b280, l'offset d'un fastprox.dll de Windows 10. Le hook s'installe sans erreur sur du code que Windows 11 n'exécute jamais.

Premier correctif, et toujours rien. Lecture de NtBuildNumber à KUSER_SHARED_DATA+0x260, et une table build vers offset. gdb montre on_dll_hooked qui se déclenche (« DLL hooked - done »), mais ExecQuery_handler jamais.

Fausse piste : la course. Le hook s'installait dans PowerShell, jamais dans WmiPrvSE.exe, où la requête est réellement traitée. Hypothèse de course dans la pose des hooks (voir section 5, il y en avait bien une, mais ce n'était pas la cause ici). Découverte au passage de --userhook-injection-mode : le mode pf par défaut est une machine à états qui a besoin d'environ 27 appels système du même processus pour converger, et sur un processus éphémère ça peut ne jamais finir. Avec ce flag, le hook s'installe dans WmiPrvSE (confirmé deux fois). Toujours 0 déclenchement.

La vraie cause. En traçant quel offset est réellement utilisé : encore 0x2b280. La constante kuser = 0xFFFFF7800000000 a 15 chiffres hexadécimaux au lieu de 16 (0xFFFFF78000000000), un facteur 16 d'écart. vmi_translate_kv2p échouait, nt_build_number restait à 0, et on retombait dans la branche Windows 10. Ce bug était déjà dans main, utilisé par --hidevm-delay, et personne ne l'avait vu. Corrigé aux deux endroits.

Deux maillons de plus. PowerShell (Get-WmiObject, Get-CimInstance) appelle IWbemServices::ExecQueryAsync, une fonction distincte, avec strQuery au même rang (troisième argument). Hookée aussi. Et check_object_name() ne réagit qu'à win32_perfformatteddata et win32_perfrawdata : le scénario de test devait donc être Get-WmiObject -Query "SELECT * FROM Win32_PerfFormattedData_PerfOS_Processor".

3. Les offsets

PDB de fastprox.dll récupérés sur msdl.microsoft.com avec le GUID exact de chaque build, lus avec llvm-pdbutil dump -publics. x64 seulement.

Build inconnu à partir de 22000 : pas de hook et un message de debug, plutôt qu'un offset faux.

Détail d'extraction sur 24H2 : ntoskrnl.exe y est stocké compressé (WOF, CompactOS, tag de reparse 0x80000017) et guestfish n'arrive pas à le lire. Extraction par qemu-nbd et dissect.ntfs : les chunks de 8192 octets sont annoncés XPRESS8K mais sont en réalité en LZXPRESS Huffman (vérifié par le MZ en tête), et 8 chunks sur 1554 sortent un octet trop courts, bien après le répertoire de debug, sans effet sur le GUID.

4. La preuve

Build release par défaut, sans gdb, injection -m createproc dans explorer.exe, -a hidevm -a procmon. Événement "Reason":"WMI query spoofed" sur 6 builds sur 6 (25H2 à la deuxième tentative). Bonus inattendu : WMIADAP.exe, un composant natif de Windows, a déclenché le masquage tout seul sur sa requête interne win32_perfrawdata (22H2, PID 5772).

La PR #1881 a d'abord eu une CI rouge sur la complexité cognitive (le constructeur passait de 49 à 70). Extraction en trois fonctions nommées, retour à 49, somme à 3783 comme main, 34 checks verts. Retest après ce remaniement sur les six builds : 21H2, 22H2, 23H2 et 26H1 à la première tentative, 24H2 à la deuxième, 25H2 à la cinquième (il a fallu --userhook-injection-mode et un -t plus long). Vérifié en build debug que les échecs n'étaient pas une branche d'erreur (zéro ligne [HIDEVM]) : fastprox.dll n'était simplement pas chargée dans la fenêtre. Fusionnée le 30 septembre, sans commentaire écrit, juste le déclenchement de Jenkins et le merge.

5. La course sur ntdll.dll, qui touchait tout le monde

try_hook_ntdll() dans libusermode cherche le VAD de ntdll.dll une seule fois par PID, au premier NtMapViewOfSection ou NtProtectVirtualMemory observé. Si le VAD n'est pas encore visible, l'échec est mis en cache (proc_ntdll[pid] = {nullopt, false}) pour toute la vie du processus. Plus aucun hook, en silence. Ça touche n'importe quel plugin userhook sur n'importe quel processus éphémère, pas seulement hidevm ni seulement Windows 11.

Correctif : un champ ntdll_lookup_retries dans module_context_t, et on relance la recherche tant qu'il est inférieur à 20, en incrémentant sur place (réinitialiser l'entrée ferait boucler). Après 20 échecs, abandon comme avant. Avec un build debug instrumenté sur 22H2 : avant, WmiPrvSE reste à is_hooked=0 sans nouvelle tentative ; après, le VAD est trouvé en quelques essais ; le processus Registry (PID 112, sans ntdll) plafonne à 20. La CI a de nouveau tiqué sur la complexité (25 vers 26 à cause d'une lambda), extraite en fonction. PR #1882, fusionnée le 30 septembre. Je n'ai pas mesuré la fréquence de la course, la PR dit « some fraction of runs », sans compter.

6. La suite : Windows 10, 14 builds

Windows 10 n'utilise qu'une paire d'offsets dans hidevm : 0x2b280 en x64 et 0x30690 en x86. Ce sont exactement ceux de 1803 (17134.1). Extraction hors ligne sur 14 builds (qemu-nbd sur chaque qcow2 éteint, le script WOF ci-dessus, PDB Microsoft, symboles ?ExecQuery@XWbemServices@CWbemSvcWrapper@@), x64 et SysWOW64, SHA256 archivés. 1903 et 1909 partagent un binaire, 2004 à 22H2 aussi (même sha256, 19041.1).

Test avec une branche locale sur b2f64d8, ept=ad=0, injection de six clients WMI : wmic 64 bits, PowerShell Get-WmiObject puis ManagementObjectSearcher.Get(observer) en asynchrone, et les trois mêmes depuis un cmd.exe 32 bits. Résultat : 1803, 1809, 1903, 1909, 2004, 20H2, 21H1, 21H2 et 22H2, 6 clients masqués sur 6 (à partir de 19041, deux événements de plus venant de WmiApSrv.exe). main non patché sur 1803 : seulement les 4 clients synchrones. 1809 : « Process startup failed » deux fois en release, aussi avec main, 6 sur 6 en debug, non déterministe.

Non établi : 1507, 1511, 1607, 1703 et 1709 (Plugin hidevm startup failed!, InitFail, 0 événement, ou pas d'explorer.exe trouvé). Je l'attribue à l'attache instable de DRAKVUF sur ces vieux builds, pas aux offsets, sans l'avoir prouvé. Résultats postés sur #1883 le 6 octobre. La PR Windows 10 attend un rejeu de la CI et une réponse sur ces cinq builds.

Ce que je n'ai PAS fait

• Le mécanisme MSAcpi_ThermalZoneTemperature n'a jamais été validé positivement : impossible sur ce matériel virtuel.
• WOW64 sur Windows 11.
• Je n'ai pas vérifié si les mises à jour cumulatives remplacent fastprox.dll, ce qui déplacerait les offsets.

Sources

• PR #1881 et #1882, issue #1883.
• Journal d'enquête (PROFILES_LOG.md), tables d'offsets et SHA256 des fastprox.dll, script d'extraction WOF. En local, fournis sur demande.
• Les chiffres de ce billet ont été recontrôlés contre ce journal.