Mes contributions à DRAKVUF : neuf PR, trois issues, trois correctifs en attente

Catégorie : DRAKVUF

Résumé

Entre le 20 septembre et le 13 octobre 2026 : neuf PR fusionnées, trois issues ouvertes, et trois correctifs qui attendent encore sur des branches locales. Ce billet les liste avec leur raison d'être, leur état et ce que Tamas, le mainteneur, en a dit. Les enquêtes qui méritent plus de place ont leur propre billet : le crash Xen reason 49, hidevm sur Windows 11 et 10, et les tests sur six builds Windows 11 et les correctifs qui en sont sortis.

Le tableau

Pièce	Sujet	État
#1874	injecteur : blocage intermittent dans la détection de fin de `createproc`	fusionnée le 20/09
#1875	injecteur : `readfile` Linux renvoyait un fichier vide et un échec	fusionnée le 26/09
#1876	`--userhook-target-process` : ne hooker qu'un processus et ses descendants	fusionnée le 26/09
#1877	`repl` : trouver `libdrakvuf.py` dans le layout meson, ne plus laisser le domaine en pause	fusionnée le 26/09
#1878	`vmi.c` : `DRAKVUF_DEBUG` à la place d'une macro `DEBUG` qui n'avait jamais compilé	fusionnée le 26/09
#1879	`libhook` : vérifier le contexte de retour dans `ReturnHook` lui-même	fusionnée le 26/09
#1880	suppression des `verifyResultCallParams()` devenus redondants dans les plugins	fusionnée le 27/09
#1881	`hidevm` : support de Windows 11 pour le masquage des requêtes WMI	fusionnée le 30/09
#1882	`libusermode` : réessayer la recherche du VAD de `ntdll.dll` un nombre borné de fois	fusionnée le 30/09
#1860	issue de Tamas, « Xen 4.21 regression » : mes analyses du gel et du crash reason 49	ouverte, 59 runs postés le 06/10
#1883	issue : résultats sur six builds Windows 11, puis offsets `fastprox` Windows 10	ouverte
#1884	issue : `dkommon` plante au démarrage sur 24H2 et plus	ouverte, PR prête
local	six traps nuls dans `procmon` et `dkommon`	commit local, pas poussé
local	mise à jour du sous-module LibVMI	validée sur 9 invités, PR pas ouverte
local	`hidevm` : offsets `fastprox` pour 14 builds Windows 10	branche locale, PR pas ouverte

Les PR

#1874 et #1875, l'injecteur. Deux correctifs antérieurs aux campagnes de ce site : un blocage intermittent, parfois sans fin, dans la détection de la fin d'un createproc, et readfile sous Linux qui renvoyait un fichier vide en annonçant un échec. Fusionnés sans discussion.

#1876, --userhook-target-process. L'issue #1828 demandait d'intégrer un patch de 2019 dont dépend SNIPER. Presque tout était déjà en amont ; il manquait le filtre sur un arbre de processus. 89 lignes, 35 runs sans violation. Une deuxième PR, « hooker un processus déjà en cours », a été mesurée puis abandonnée sur la réponse de Tamas : DRAKVUF part d'une ardoise propre, pas de victimes déjà en cours.

#1877, repl. En build meson, repl ne trouvait pas libdrakvuf.py, échouait après l'attache sans drakvuf_close(), et laissait le domaine en pause. Deux commits fusionnés ; un troisième (Ctrl+C sur ligne vide pour sortir d'IPython) est testé et pas publié.

#1878, la macro. Trois blocs de traces sous #ifdef DEBUG alors que la macro s'appelle DRAKVUF_DEBUG. Trois lignes. Avant, 0 ligne INT3 event ; après, 18 787 en 25 s.

#1879 et #1880, les return hooks. Un ReturnHook peut être touché par un autre thread ou un appel récursif ; chaque plugin devait vérifier à la main, et libhooktest ne le faisait pas (issue #1584). La vérification est maintenant dans ReturnHook lui-même, et #1880 retire les appels devenus morts dans dix fichiers (+114/-153). Mêmes comptes d'événements avant et après sur filetracer, rpcmon, apimon, procmon et codemon.

#1881, hidevm sur Windows 11. Le plugin ne masquait rien sur six builds à cause d'une constante à 15 chiffres hexadécimaux au lieu de 16, présente dans main depuis le début. Avec la lecture de NtBuildNumber, une table d'offsets fastprox.dll par build, et le hook de ExecQueryAsync en plus de ExecQuery. La CI a d'abord refusé la complexité du constructeur, réduite par extraction en trois fonctions. Fusionnée sans commentaire écrit.

#1882, la course sur ntdll.dll. libusermode cherchait le VAD de ntdll.dll une seule fois par processus et mettait l'échec en cache pour toujours. Compteur de 20 essais. Fusionnée avec #1881.

Les issues

#1860. L'issue de Tamas décrivait un gel et un crash. J'y ai posté, du 24 septembre au 6 octobre : l'impossibilité de reproduire au début, le backtrace du gel (LibVMI, corrigé dans libvmi#1123), la matrice de validation du sous-module LibVMI à jour, le reproducteur du crash en 40 lignes avec ses trois ingrédients et la matrice Xen 4.21.0, 4.21.2, 4.22.0, un gel de dom0, puis, après sa réponse sur ept=ad=0, le contre-test et 59 runs sans crash. Tamas a suggéré la mise à jour du sous-module et le passage à Xen 4.22, puis rappelé l'option ad=0. Reste ouvert : il dit voir reason 49 avec ad=0, ce que je n'ai pas reproduit.

#1883. Le rapport de la campagne sur six builds Windows 11 (aucune incompatibilité propre à Windows 11, deux faux positifs, deux non-bugs, un segfault sur attache trop tôt), puis le 6 octobre les offsets fastprox de 14 builds Windows 10. Réponse de Tamas le 30 septembre : les redémarrages du guest devraient être détectés par DRAKVUF en lisant la même source que xl. Pas traité.

#1884. MiProcessLoaderEntry n'existe plus dans le noyau de 24H2 et son trap est dans le bloc critique de dkommon : 10 démarrages sur 10 en échec. Patch prêt (sortir le trap du bloc critique, avec un message), PR pas ouverte.

Les correctifs qui attendent

Six traps nuls. register_trap() renvoie nullptr et six sites ne le vérifiaient pas : segfault at 8, vu deux fois sur 270 attaches. 18 lignes, prouvées par échec forcé sur 9 invités, non-régression sur 13. Le texte de PR et les questions pour Tamas sont écrits.
Le sous-module LibVMI. Base et bump comparés sur 9 invités, identiques. J'attendais libvmi#1126, fusionnée depuis.
hidevm Windows 10. Offsets pour 14 builds, 6 clients WMI masqués sur 6 de 1803 à 22H2. Cinq vieux builds non établis.

Sources

Les PR et issues listées, avec leurs descriptions et les archives de preuves jointes aux commentaires.