URL: https://linuxfr.org/news/pyvmidbg-un-debogueur-full-system-base-sur-l-introspection-de-machine-virtuelle Title: pyvmidbg : un débogueur full‐system basé sur l’introspection de machine virtuelle Authors: Wenzel ZeroHeure, Xavier Teyssier, Davy Defaud, palm123 et Benoît Sibaud Date: 2019年03月28日T23:50:32+01:00 License: CC By-SA Tags: introspection, fosdem, debugging et hyperviseur Score: 36 Voici un projet qui me (Wenzel) tient à cœur : **pyvmidbg**. Le but est assez simple : se donner la capacité de déboguer l’état complet d’un système d’exploitation, tournant dans une machine virtuelle, en utilisant uniquement l’hyperviseur et l’accès au matériel par la machine virtuelle. L’idée en elle‐même a commencé à germer lorsque je travaillais sur des outils d’analyse de logiciels malveillants (_malware_) basés sur l’hyperviseur, et, voyant leur efficacité pour l’analyse automatisée, j’ai petit à petit creusé pour transposer ces concepts afin d’aboutir à de puissants débogueurs interactifs. ---- [Code source sur GitHub](https://github.com/Wenzel/pyvmidbg) [Démo en vidéo : débogage sur Windows XP](https://drive.google.com/file/d/1clumU_P8K-M1mgQ4RaNVSrWg6sxojw8d/view) [Présentation à la conférence « Insomni’Hack » à Genève](https://drive.google.com/file/d/1ZMUszfwWDOljdDfPOJgkEfSabNy0UAJR/view) [Slack de pyvmidbg](https://vmidbg.slack.com) ---- Intérêt ======= Problématiques -------------- L’intérêt d’un tel outil ? Au‐delà du besoin évident pour des analystes en sécurité d’analyser furtivement des logiciels malveillants avancés, on peut trouver d’autres problèmes plus généraux liés aux API de débogage des systèmes d’exploitation : 1. la visibilité (l’effet d’observateur), qui va potentiellement changer l’environnement du programme ; par exemple, certains appels système auront un comportement différent ; 2. cet effet d’observateur peut parfois être volontaire, dans une tentative de protection de la propriété intellectuelle de certains systèmes d’exploitation ; 3. les nouvelles fonctionnalités de sécurité des systèmes d’exploitation modernes posent des soucis de compatibilité avec la visibilité et le contrôle total que demandent les débogueurs. Avantages --------- Déboguer depuis l’hyperviseur apporte aussi des bénéfices non négligeables : 1. en virtualisant le démarrage depuis un hyperviseur chargé sur une clef USB, il est possible d’analyser dans une machine virtuelle l’ensemble de la séquence de démarrage d’un système d’exploitation, et ce depuis le micrologiciel BIOS/UEFI ; 2. les _unikernels_, images noyau embarquant une seule application, sont dépouillés d’un maximum de fonctionnalités pour être minimaux et rapides ; le [_stub_](https://fr.wikipedia.org/wiki/Stub) de débogage est également supprimé, laissant à l’API de l’hyperviseur les seuls moyens d’accès pour un _unikernel_ en production ; 3. l’unification des outils de débogage : en rebasant nos débogueurs sur l’hyperviseur, il nous sera possible d’utiliser le même outil pour déboguer et suivre des processus, de l’espace utilisateur au noyau, et ce, sur tous les systèmes d’exploitation ! Débogage full‐system ==================== Afin de résoudre ces problématiques et implémenter une solution pérenne, j’aimerais vous présenter la vision que j’ai de nos futurs outils de débogage, travaillant en mode _full‐system_ : ![pyvmidbg](https://user-images.githubusercontent.com/964610/53703373-9fed3580-3e11-11e9-96f8-47b3f38044cf.jpg) - les multiples _stubs_ de débogage implémentent les protocoles standards pour gérer tous les frontaux ; - les _stubs_ possèdent une connaissance du système invité, c’est‐à‐dire qu’ils sont capables de suivre et d’intercepter l’exécution d’un processus cible dans la machine virtuelle ; - la **LibVMI** permet de faire le lien avec les différentes API de **VMI** (_Virtual Machine Introspection_) des hyperviseurs cibles. Démo ==== Comme une démo vaudra mieux que mille mots, je vous propose [cette petite vidéo que j’ai enregistrée pour la conférence _Insomni’Hack_](https://drive.google.com/file/d/1clumU_P8K-M1mgQ4RaNVSrWg6sxojw8d/view) qui se tenait la semaine dernière à Genève. Dans celle‐ci, avec une machine virtuelle Windows XP imbriquée, je montre comment : 1. intercepter l’exécution de `cmd.exe` ; 2. se connecter au _stub_ en utilisant radare2 ; 3. mettre en place deux points d’arrêt, en espace utilisateur sur `ntdll!NtOpenFile`, puis en espace noyau sur `nt!NtOpenFile` ; 4. suivre des événements liés à ces points d’arrêt dans le _stub_, en ignorant les autres processus pour ne renvoyer de résultat que pour `cmd.exe`. Pour aller plus loin, je vous ai également mis le lien vers la présentation. Quel est votre avis concernant nos outils de débogages actuels ? J’aimerais avoir vos retours ! Je cherche à présent à implémenter la prise en charge de GNU/Linux, et à comprendre comment l’état des fils d’exécution (_threads_) est sauvé et restauré, et comment l’ordonnanceur passe de l’un à l’autre. Vous êtes curieux ou souhaitez participer ? Nous avons [un Slack](https://vmidbg.slack.com) ! Dans l’espoir de vous présenter une meilleure version au [FOSDEM](https://fosdem.org/ "Free and Open Source Developers’ European Meeting") 2020. :) Merci à vous !

AltStyle によって変換されたページ (->オリジナル) /