# 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](index.html?w=drakvuf-xen-reason49-ept-ad0.md), [hidevm sur Windows 11 et 10](index.html?w=drakvuf-hidevm-windows-11-10.md), et [les tests sur six builds Windows 11 et les correctifs qui en sont sortis](index.html?w=drakvuf-six-builds-windows-11-et-correctifs.md). ## Le tableau | Pièce | Sujet | État | |---|---|---| | [#1874](https://github.com/tklengyel/drakvuf/pull/1874) | injecteur : blocage intermittent dans la détection de fin de `createproc` | fusionnée le 20/09 | | [#1875](https://github.com/tklengyel/drakvuf/pull/1875) | injecteur : `readfile` Linux renvoyait un fichier vide et un échec | fusionnée le 26/09 | | [#1876](https://github.com/tklengyel/drakvuf/pull/1876) | `--userhook-target-process` : ne hooker qu'un processus et ses descendants | fusionnée le 26/09 | | [#1877](https://github.com/tklengyel/drakvuf/pull/1877) | `repl` : trouver `libdrakvuf.py` dans le layout meson, ne plus laisser le domaine en pause | fusionnée le 26/09 | | [#1878](https://github.com/tklengyel/drakvuf/pull/1878) | `vmi.c` : `DRAKVUF_DEBUG` à la place d'une macro `DEBUG` qui n'avait jamais compilé | fusionnée le 26/09 | | [#1879](https://github.com/tklengyel/drakvuf/pull/1879) | `libhook` : vérifier le contexte de retour dans `ReturnHook` lui-même | fusionnée le 26/09 | | [#1880](https://github.com/tklengyel/drakvuf/pull/1880) | suppression des `verifyResultCallParams()` devenus redondants dans les plugins | fusionnée le 27/09 | | [#1881](https://github.com/tklengyel/drakvuf/pull/1881) | `hidevm` : support de Windows 11 pour le masquage des requêtes WMI | fusionnée le 30/09 | | [#1882](https://github.com/tklengyel/drakvuf/pull/1882) | `libusermode` : réessayer la recherche du VAD de `ntdll.dll` un nombre borné de fois | fusionnée le 30/09 | | [#1860](https://github.com/tklengyel/drakvuf/issues/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](https://github.com/tklengyel/drakvuf/issues/1883) | issue : résultats sur six builds Windows 11, puis offsets `fastprox` Windows 10 | ouverte | | [#1884](https://github.com/tklengyel/drakvuf/issues/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](https://github.com/tklengyel/drakvuf/issues/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](https://github.com/tklengyel/drakvuf/issues/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](https://github.com/libvmi/libvmi/pull/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.