fix: wip proof reading chap 3

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}.