From c497b0c9f1c4909ea65a46c01c5d479ae782ccbc Mon Sep 17 00:00:00 2001
From: "iliya.saroukha" <iliya.saroukhanian@etu.hesge.ch>
Date: Fri, 28 Mar 2025 18:59:47 +0100
Subject: [PATCH] fix: wip proof reading chap 3
---
thesis/chapters/chap3.tex | 47 ++++++++++++++++++++-------------------
1 file changed, 24 insertions(+), 23 deletions(-)
diff --git a/thesis/chapters/chap3.tex b/thesis/chapters/chap3.tex
index f323daf..f65d71e 100644
--- a/thesis/chapters/chap3.tex
+++ b/thesis/chapters/chap3.tex
@@ -6,17 +6,17 @@ La suite de ce rapport se focalisera sur la présentation des deux grands axes
pratiques abordés lors de ce travail de semestre. Le premier fut une tentative
d'implémentation d'un hyperviseur \textit{bare-metal} malveillant pour
le système d'exploitation GNU/Linux. Celui-ci devait prendre la forme d'un
-\acrshort{lkm} (module noyau chargeable à l'exécution) utilisant les extensions
+\gls{lkm}\footnote{Module noyau chargeable à l'exécution} utilisant les extensions
matérielles Intel VT-x pour parvenir à virtualiser dans un premier temps le(s)
\acrshort{cpu}(s) de l'hôte, puis de mettre en place et initialiser toutes les
structures de données associées à une \acrshort{vm} afin de l'exécuter
correctement. Le but ultime de l'implémentation de ce \acrshort{poc} est de
transférer l'exécution de l'\acrshort{os} de l'hôte dans une machine virtuelle
-contrôlée par notre hyperviseur. Ceci aura comme effet une élévation de
-privilèges additionnelle et un contrôle total, en théorie, sur l'exécution du
+contrôlée par notre hyperviseur. Ceci aura pour effet une élévation de
+privilèges supplémentaire et un contrôle total, en théorie, sur l'exécution du
système d'exploitation sous-jacent. Suite à l'envergure de la tâche, celle-ci
n'a pu être aboutie dans les délais prévus pour le projet de semestre et sera
-donc poursuivi lors du travail de bachelor.
+donc poursuivie lors du travail de bachelor.
Ceci nous amène à la raison d'être de ce chapitre. En m'étant jeté tête baissée
dans cette implémentation, au bout d'un certain temps j'ai rencontré certaines
@@ -46,17 +46,17 @@ Pour parvenir à réproduire un environnement aussi proche que possible de celui
de l'époque, je me suis basé sur une image ISO de la seconde version béta
de Windows Vista \cite{microsoft_windows_2006} afin d'instancier ma machine
% TODO: rajouter vm specs en annexe
-virtuelle. Les spécifications exactes de la \acrshort{vm} sont fournis en
-annexe cependant un détail crucial à préciser est celui des capacités fournies
+virtuelle. Un détail crucial à préciser est celui des capacités fournies
aux v\acrshort{cpu}s. Ceux-ci disposent des extensions matérielles nécessaires
-pour la virtualisation complète assistée matériellement du fait qu'on ait permis
-à la machine virtuelle d'hériter des capacités du \acrshort{cpu} de l'hôte.
+pour la virtualisation complète assistée par le matériel du fait qu'on ait
+permis à la machine virtuelle d'hériter des capacités du \acrshort{cpu} de
+l'hôte.
Afin de pouvoir compiler correctement le code source (transféré au
préalable dans la \acrshort{vm} susmentionnée), il fut nécessaire de se munir de
la \textit{toolchain} \footnote{Chaîne de compilation} adéquate. Celle-ci est
fournie dans la version 7.1.0 du \textit{\gls{wdk}} \cite{noauthor_download_nodate}.
-Le \acrshort{wdk} est un ensemble d'outils (e.g. chaînes de compilation,
+Le \acrshort{wdk} est un ensemble d'outils (ex.: chaînes de compilation,
fichiers sources) fourni par Microsoft afin de développer des pilotes pour la
plateforme Windows. Étant donné que les pilotes sont exécutés au même niveau
de privilège que le noyau de l'\acrshort{os}, ils répresentent donc un vecteur
@@ -71,7 +71,7 @@ car le produit compilé ne sera évidemment pas signé.
% À présent, ayant en ma possession les outils nécessaires, il ne me reste
Afin d'obtenir un pilote Windows valide ayant l'extension \verb|.sys|, il est
nécessaire d'utiliser l'environnement de compilation \textit{\say{Windows Vista and Windows Server 2008 x64 Checked Build Environment}}
-fourni dans l'\acrshort{wdk}. Celui-ci doit être choisi en fonction de
+fourni dans le \acrshort{wdk}. Celui-ci doit être choisi en fonction de
l'architecture ciblée, en l'occurrence la notre est x86-64. En naviguant à la
racine du projet via l'invite de commandes fourni par cet environnement, il sera
par la suite possible d'exécuter le script \verb|build_code.cmd| dont le contenu
@@ -109,7 +109,7 @@ pilote noyau. Les arguments fourni au programme permettent de respectivement :
Le binaire \verb|ctags.exe| quant à lui n'a aucune incidence sur le pilote
créé. Cet exécutable permet de simplement indexer les divers symboles présents
-dans le code source (i.e. nom de fonctions, variables, etc\dots) afin de pouvoir
+dans le code source (c-à-d.: nom de fonctions, variables, etc\dots) afin de pouvoir
les référencer rapidement dans un éditeur de texte. L'option \verb|-R| permet
d'effectuer cet indexation de manière récursive à travers toute l'arborescence
du projet.
@@ -137,8 +137,8 @@ au démarrage du système d'exploitation ou être lancé à la demande de
l'administrateur.
La ligne de commande ci-dessous nous permet de créer un service associé à notre
-pilote compilé en luis spécifiant le type exacte de service (i.e. \textit{kernel}
-pour noyau) ainsi que le chemin absolu vers le ficier \verb|.sys|.
+pilote compilé en lui spécifiant le type exacte de service (c-à-d. \textit{kernel}
+pour noyau) ainsi que le chemin absolu vers le fichier \verb|.sys|.
\begin{figure}[tbph!]
\begin{minted}
@@ -197,14 +197,14 @@ contradictoire avec l'option choisie au démarrage (voir Figure~\ref{fig:disable
Plusieurs approches différentes furent explorées afin de pallier cette
problématique. La première était de faire basculer le système d'exploitation en
-mode \textbf{test} en modifiant certaines données du \acrshort{bcd}
+mode \textbf{test} en modifiant certaines données du \gls{bcd}
\footnote{Données de configuration de l'amorçage} via le programme
\verb|bcdedit.exe|. La désactivation de la vérification d'intégrité à l'aide de
la commande \verb|bcdedit /set nointegritychecks on| n'a fourni aucun résultat
concluant.
% FIXME: à plus documenter psk léger imo
-Avoir émis l'hypothèse que possiblement le système d'exploitation requérait
+Ayant émis l'hypothèse que possiblement le système d'exploitation requérait
tout de même un pilote signé, cette théorie fut testée en activant au préalable
le mode \verb|bcdedit /set testsigning on|. L'effet cependant fut toujours le
même, Windows réussissait, malgré tous mes efforts, à bloquer le lancement du
@@ -217,7 +217,7 @@ service créé pour le pilote \verb|newbp.sys|.
\section{Analyse du code source}
-Afin de tirer malgré tout un enseignement de la tentative de réproduire le
+Afin de tirer malgré tout un enseignement de la tentative de reproduire le
\textit{malware} Blue Pill qui s'est avérée être peu concluante, j'ai décidé de
me pencher sur une analyse approfondie du code source de ce \textit{rootkit}
\acrshort{hvm} dont l'entièreté est à ma disposition. Ceci sera donc le sujet
@@ -238,11 +238,12 @@ assimilée au symbole \verb|main| dans un programme C. Dans cette fonction, nous
allons nous concentrer sur deux fonctions : \verb|HvmInit()| et
\verb|HvmSwallowBluepill()|.
-Le but de \verb|HvmInit()| est de vérifier si la plateforme sur laquelle
-s'exécute le code est compatible avec les extensions matérielles d'Intel ou
-AMD. Le cas échéant, un code d'erreur est retourné et le pilote n'est jamais
-lancé. Suite à cette fonction, la routine \verb|HvmSwallowBluepill()| sera
-appelé qui entamera l'initialisation des \acrshort{cpu}s.
+Le but de \verb|HvmInit()| (voir la Figure~\ref{fig:code_driver_entry}) est de
+vérifier si la plateforme sur laquelle s'exécute le code est compatible avec les
+extensions matérielles d'Intel ou AMD. Le cas échéant, un code d'erreur est
+retourné et le pilote n'est jamais lancé. Suite à cette fonction, la routine
+\verb|HvmSwallowBluepill()| sera appelé qui entamera l'initialisation des
+\acrshort{cpu}s.
\begin{figure}[tbph!]
\begin{minted}
@@ -285,8 +286,8 @@ NTSTATUS DriverEntry(PDRIVER_OBJECT DriverObject,
\caption{Fichier \lstinline{common/newbp.c:46}. Source : tiré du code source de Blue Pill, ref. URL06 / réalisé par RUTKOWSKA Joanna}\label{fig:code_driver_entry}
\end{figure}
-Dans la fonction \verb|HvmSwallowBluepill()|, dont le contenu est illustrer
-ci-dessous, nous pouvons voir qu'une fonction du nom de
+Dans la fonction \verb|HvmSwallowBluepill()|, dont le contenu est illustré par
+la Figure~\ref{fig:code_hvm_swallow_bp}, nous pouvons voir qu'une fonction du nom de
\verb|CmDeliverToProcessor()| est appelée en boucle. Cette fonction aura pour
but de modifier l'\textbf{affinité du processeur} et d'exécuter la
\textit{callback}\footnote{Fonction de rappel}.
--
GitLab