correction of the french summary

0_preamble/french_summary.typ

@@ -1,4 +1,6 @@
-#import "../lib.typ": epigraph, APK, pb1-text-fr, pb2-text-fr, pb3-text-fr, eg, etal, APKs, DEX, todo, num
+#import "../lib.typ": epigraph, APK, pb1-text-fr, pb2-text-fr, pb3-text-fr, etal, APKs, DEX, todo, num, à-maj
+
+#let eg = [_ex._]
 
 #show figure.where(kind: raw): set figure(supplement: [Code])
 #let mp = text(font: "libertinus serif", sym.dot.c)
@@ -9,48 +11,48 @@
 
 == Introduction
 
-Android est le système d'exploitation pour téléphones portables le plus utilisé depuis 2014, et depuis 2017, il surpasse même Windows toute platformes confondues.
+Android est le système d'exploitation pour téléphones portables le plus utilisé depuis 2014, et depuis 2017, il surpasse même Windows toutes platformes confondues.
 Cette popularité en fait une cible de choix pour les acteurs malveillants.
 Il est donc important d'être capable d'analyser une application pour savoir exactement ce qu'elle fait.
 Ce processus est appelé l'ingénierie inverse.
 
-Beaucoup de travail à été fait dans ce domaine pour les programmes d'ordinateur.
+Beaucoup de travail a été fait dans ce domaine pour les programmes d'ordinateur.
-Toutefois, les applications Android présentent leur propres difficultés.
+Toutefois, les applications Android présentent leur propres difficultées.
-Par exemple, les applications sont distribué dans leur format spécifique, le format #APK, et le code des applications est lui même compilé dans un format de code à octets spécifique à Android: Dalvik.
+Par exemple, les applications sont distribuées dans leur format spécifique, le format #APK, et le code des applications est lui-même compilé dans un format de code à octets spécifique à Android: Dalvik.
 La première difficulté pour l'ingénieur#mp;e inverse est donc d'avoir des outils qui comprennent les formats utilisés par Android.
 Dans le processus d'analyse, une première étape serait alors de lire le contenu de l'application.
-Des outils comme Apktool peuvent être utilisé pour convertir les fichiers binaire de l'application dans une version lisible par un#mp;e humain#mp;e.
+Des outils comme Apktool peuvent être utilisés pour convertir les fichiers binaire de l'application dans une version lisible par un#mp;e humain#mp;e.
 D'autres comme Jadx essaient de générer le code source Java depuis le code à octets.
-Toutefois, les applications Android peuvent être trés grossent et il n'est pas toujours possible de les analyser manuellement.
+Toutefois, les applications Android peuvent être très grosses et il n'est pas toujours possible de les analyser manuellement.
-D'autres outils ont été développer pour extraire une représentation plus haut niveau du contenu de l'application.
+D'autres outils ont été développés pour extraire une représentation plus haut niveau du contenu de l'application.
 Par exemple, Flowdroid a pour objectif de détecter les fuites d'informations: l'utilisateur#mp;ice définit une liste de méthodes qui génèrent des informations sensbiles, et une liste de méthodes qui exfiltrent des informations vers l'extérieur.
-Flowdroid va alors calculer si il existe des chemins dans l'application permettant de relier des méthodes de la première catégorie avec des méthodes de la seconde.
+Flowdroid va alors calculer s'il existe des chemins dans l'application permettant de relier des méthodes de la première catégorie avec des méthodes de la seconde.
 
-Malheureusement, ces outils sont difficile a utiliser, et même si ils fonctionnent sur des applications simples construitent dans le but de tester les outils, il n'est pas rare que ces outils échouent sur de vrais applications.
+Malheureusement, ces outils sont difficiles à utiliser, et même s'ils fonctionnent sur des applications simples construites dans le but de tester les outils, il n'est pas rare que ces outils échouent sur de vraies applications.
-Cela pause la problématique #pb1-text-fr
+Cela pose la problématique #pb1-text-fr
 
 Il y a deux familles d'analyse: l'analyse statique et l'analyse dynamique.
-L'analyse statique analyse l'application sans la lancer, alors que l'analyse dynamique examine le comportement de l'application peudant son exécution.
+L'analyse statique analyse l'application sans la lancer, alors que l'analyse dynamique examine le comportement de l'application pendant son exécution.
-Chacune a ses forces et ces faiblesses, et certain problèmes d'analyse sont traditionnellement associé à l'une ou l'autre pour les résoudre.
+Chacune a ses forces et ses faiblesses, et certains problèmes d'analyse sont traditionnellement associés à l'une ou l'autre pour les résoudre.
 L'un de ces problème est le chargement dynamique de code.
-Les applications Android sont initiallement prévu pour être codé en Java, et donc Android à hérité de beaucoup de fonctionnalités de Java.
+Les applications Android sont initiallement prévus pour être codé en Java, et donc Android a hérité de beaucoup de fonctionnalités de Java.
-En l'occurence, Android utilisent un systeme de chargeur de classes similaire à celui de Java, qui peut être utiliser pour charger, en cour d'exécution, du code extérieur à l'application.
+En l'occurence, Android a un système de chargeur de classes similaire à celui de Java, qui peut être utilisé pour charger, en cour d'exécution, du code extérieur à l'application.
-Etant donné que ce code chargé dynamiquement n'est pas nécessairement disponnible dans l'application initiallement, ce problème est relégé a l'analyse dynamique.
+Etant donné que ce code chargé dynamiquement n'est pas nécessairement disponible dans l'application initialement, ce problème est relégé à l'analyse dynamique.
-Toutefois, il semblerais qu'une généralisation hâtive soit souvant faite, et que le système de chargement de classe dans sont ensemble soit relégé à l'analyse dynamique.
+Toutefois, il semblerait qu'une généralisation hâtive soit souvent faite, et que le système de chargement de classe dans son ensemble soit relégé à l'analyse dynamique.
-L'absence d'étude détaillé de ce mechanisme nous amène à notre seconde problématique: #pb2-text-fr
+L'absence d'étude détaillée de ce mecanisme nous amène à notre seconde problématique: #pb2-text-fr
 
-Un autre problème usuellement associé à l'analyse dynamique est la réflection.
+Un autre problème usuellement associé à l'analyse dynamique est la réflexion.
 Android permet à une application de manipuler les classes et méthodes sous forme d'objet.
-En utilisant cette fonctionnalité, il est donc possible d'appeler une méthode en utilisant son nom sous forme de chaine de caractère au lieu d'utiliser une instruction Dalvik avec une référence vers méthode.
+En utilisant cette fonctionnalité, il est donc possible d'appeler une méthode en utilisant son nom sous forme de chaine de caractère au lieu d'utiliser une instruction Dalvik avec une référence vers la méthode appelée.
-Ce cas est déjà compliqué à analyser statiquement quand la chaine de caractère est lisible dans l'application, mais il devient imposible quand elle ne l'ai pas (#eg la chaine est envoyé par un serveur externe lors de l'execution, ou elle est stocké chiffré est n'est déchiffré qu'au dernier moment).
+Ce cas est déjà compliqué à analyser statiquement quand la chaine de caractère est lisible dans l'application, mais il devient imposible quand elle ne l'est pas (#eg la chaine est envoyée par un serveur externe lors de l'exécution, ou elle est stockée chiffrée et n'est déchiffrée qu'au dernier moment).
-L'analyse dynamique permet de capturer à la fois le code chargé dynamiquement et les méthodes appelés par reflection.
+L'analyse dynamique permet de capturer à la fois le code chargé dynamiquement et les méthodes appelées par réflexion.
 Toutefois, obtenir ces instructions est insuffisant.
-Il n'existe pas de solutions standards pour transmettre ces données aux outils d'analysise statique, qui pourtant peuvent en avoir besoin pour analyser l'application dans sont entièreté.
+Il n'existe pas de solution standard pour transmettre ces données aux outils d'analyse statique, qui pourtant peuvent en avoir besoin pour analyser l'application dans son entièreté.
-Certaine contributions d'ingenierie inverse ont déjà proposé d'instrumenter (modifier) l'application pour y ajouter les résultats de leur analyse avant de l'analyser avec d'autres outils.
+Certaines contributions d'ingénierie inverse ont déjà proposé d'instrumenter (modifier) l'application pour y ajouter les résultats de leur analyse avant de l'analyser avec d'autres outils.
-Cette approche prométeuse motive notre troisième problématique: #pb3-text-fr
+Cette approche prometteuse motive notre troisième problématique: #pb3-text-fr
 
 #[
-== Evaluation de la réutilisabilité des outils d'analyse static pour Android
+== Evaluation de la réutilisabilité des outils d'analyse statique pour Android
 
 #import "../lib.typ": MWE
 #import "../3_rasta/X_var.typ": *
@@ -58,17 +60,17 @@ Cette approche prométeuse motive notre troisième problématique: #pb3-text-fr
 
 Dans ce chapitre, nous étudions la réutilisabilité d'outils d'analyse statique publiés entre 2011 et 2017.
 Le but de cette étude n'est pas de quantifier la précision des outils, car ces outils ont des objectifs finaux différents.
-Au contraire, dans ce chapitre nous allons considéré comme correct tout résultat renvoyé par les outils, et uniquement compter les occurences où les outils échouent a calculer un résultat quel qu'il soit.
+Au contraire, dans ce chapitre nous allons considérer comme correct tout résultat renvoyé par les outils, et uniquement compter les occurences où les outils échouent à calculer un résultat quel qu'il soit.
 
 Les questions auxquelles nous voulons répondre sont:
 
-/ QR1: Quels outils d'analyse statique pour Android vieux de plus de 5 ans peuvent encorent être utilisé aujourd'hui avec un effort résonnable?
+/ QR1: Quels outils d'analyse statique pour Android vieux de plus de 5 ans peuvent encore être utilisé aujourd'hui avec un effort raisonnable?
-/ QR2: Comment la réutilisabilité des outils évolue avec le temps, en particulier pour l'analyze d'applications publié avec plus de 5 ans d'éccart avec l'outil?
+/ QR2: Comment la réutilisabilité des outils évolue-t-elle avec le temps, en particulier pour l'analyse d'applications publiées avec plus de 5 ans d'écart avec l'outil?
-/ QR3: Est-ce-que la réutilisabilité des outils change quand on analyze une application bénine comparé a un maliciel?
+/ QR3: Est-ce que la réutilisabilité des outils change quand on analyse une application bénigne comparé à un maliciel?
 
 Nous basons notre étude sur revue de litérature systématique de Li #etal qui liste les contributions accompagnées d'outils sous licence libre.
 Nous avons retrouvé les outils en questions, listé dans le @tab:rasta-outils.
-Nous avons éliminé les outils utilisant de l'analyse dynamique en plus de l'analyse statique, et vérifié la présence des sources, de la documentation, et d'un optionnel exécutable si jamais les sources ne peuvent pas être compilé.
+Nous avons éliminé les outils utilisant de l'analyse dynamique en plus de l'analyse statique, et vérifié la présence des sources, de la documentation, et d'un optionnel exécutable si jamais les sources ne peuvent pas être compilées.
 
 #figure({
   show table: set text(size: 0.80em)
@@ -79,8 +81,8 @@ Nous avons éliminé les outils utilisant de l'analyse dynamique en plus de l'an
   show "Works on source files only": "Nécessite les fichiers sources"
   show "Authors ack. a partial doc": "Auteurs reconnaissent documentation insufisante"
   show "Binary obtained from authors": "Binaire obtenu des auteurs"
-  show "Related to Android hardening": "Dédié a la sécurisation d'Android"
+  show "Related to Android hardening": "Dédié à la sécurisation d'Android"
-  show "Not built with author’s help": "Ne compille pas même avec l'aide des auteurs"
+  show "Not built with author’s help": "Ne compile pas même avec l'aide des auteurs"
      
   let show_citekeys(keys) = [
   /*
@@ -139,15 +141,15 @@ Nous avons éliminé les outils utilisant de l'analyse dynamique en plus de l'an
   [
     *binaires, sources*: #nr: non pertinent, #ok: disponible, #bad: partiellement disponible, #ko: non fourni\
     *documentation*: #okk: excellente, #MWE, #ok: quelques incohérences, #bad: mauvaise qualité, #ko: non disponible\
-    *decision*: #ok: considéré; #bad: considéré mais pas compilé; #ko: sort du cadre de l'étude
+    *décision*: #ok: considéré; #bad: considéré mais pas compilé; #ko: sort du cadre de l'étude
   ]},
   caption: [Outils considérés: disponibilité et réutilisabilité],
 ) <tab:rasta-outils>
 
-Nous avons ensuite selectionné la version des outils à utiliser.
+Nous avons ensuite sélectionné la version des outils à utiliser.
-Certain outils ont évolué depuis leur publication, soit en étant maintenu par leurs auteurs, soit suite a un branchement par un autre développeur.
+Certains outils ont évolué depuis leur publication, soit en étant maintenus par leurs auteurs, soit suite à un branchement par un autre développeur.
 Nous avons décidé d'utiliser la dernière version stable en date de 2023 (date de l'étude).
-Le seul cas de branchement interescant que nous avont trouvé est celui d'IC3, que nous avons décidé d'inclure en plus d'IC3.
+Le seul cas de branchement interescant que nous avons trouvé est celui d'IC3, que nous avons décidé d'inclure en plus d'IC3.
 Le @tab:rasta-choix-sources résume cette étape.
 
 #figure({
@@ -178,7 +180,7 @@ Le @tab:rasta-choix-sources résume cette étape.
       table.cell(rowspan:2)[*Date Dernière \ Modification*],
       table.vline(end: 3),
       table.vline(start: 4),
-      table.cell(rowspan:2)[*Auteurs \ Contacté*],
+      table.cell(rowspan:2)[*Auteurs \ Contactés*],
       table.vline(end: 3),
       table.vline(start: 4),
       [*Environment*],
@@ -210,23 +212,23 @@ Le @tab:rasta-choix-sources résume cette étape.
     table.hline(),
   )
   [#ok: oui, #ko: non, UX.04: Ubuntu X.04]},
-  caption: [Outils selectionnés, branchements, version selectionnées et environment d'exécution],
+  caption: [Outils selectionnés, branchements, versions selectionnées et environnements d'exécution],
 ) <tab:rasta-choix-sources>
 
-Nous avons ensuite exécuté ces outils sur deux jeux d'applications: Drebin, un jeu de maliciels connus pour être vieux et biaisé, et Rasta, un jeu que nous avons échantilloné nous même pour réprésenter l'évolution des caractéristiques des applications entre 2010 et 2023, d'un total de #NBTOTALSTRING #APKs.
+Nous avons ensuite exécuté ces outils sur deux jeux d'applications: Drebin, un jeu de maliciels connus pour être vieux et biaisé, et Rasta, un jeu que nous avons échantilloné nous-mêmes pour réprésenter l'évolution des caractéristiques des applications entre 2010 et 2023, d'un total de #NBTOTALSTRING #APKs.
 
-Après avoir lancé les outils, nous avons collecté les différents résultats et traces d'execution.
+Après avoir lancé les outils, nous avons collecté les différents résultats et traces d'exécution.
-@fig:rasta-exit-drebin-fr et @fig:rasta-exit-fr montre les résultas des analyses sur les applications de Drebin et Rasta.
+@fig:rasta-exit-drebin-fr et @fig:rasta-exit-fr montrent les résultas des analyses sur les applications de Drebin et Rasta.
-L'analyse est considérée comme réussi (vert) si un résultat est obtenu, sinon elle a échoué (rouge).
+L'analyse est considérée comme réussie (vert) si un résultat est obtenu, sinon elle a échoué (rouge).
-Quand l'analyse met plus de une heure a finir, elle est avorté (bleue).
+Quand l'analyse met plus d'une heure à finir, elle est avortée (bleue).
-On peut voir que les outils ne s'en sorte pas trop mal sur Drebin, avec Results on the Drebin datasets 11 outils qui ont un taux de finition au dessus de 85%.
+On peut voir que les outils ont d'assez bon résultats sur Drebin, avec 11 outils qui ont un taux de finition au dessus de 85%.
 Sur Rasta par contre, #resultunusablenb outils (#resultunusable) ont un taux de finition en dessous de 50%.
-Les outils qui avaient des difficultés avec Drebin ont aussi de mauvais résultat sur Rasta, mais d'autre outils avec un résultats acceptable sur Drebin chutent avec Rasta.
+Les outils qui avaient des difficultés avec Drebin ont aussi de mauvais résultats sur Rasta, mais d'autre outils avec des résultats acceptables sur Drebin chutent avec Rasta.
 
-Ces résultats nous permetent de répondre à la notre première question *QR1*:
+Ces résultats nous permettent de répondre à notre première question *QR1*:
 
 Sur un jeu d'applications réscentes nous considérons que #resultunusable des outils sont utilisables.
-De plus pour les outils que nous avons peu lancer, #resultratio des analyses ont bien terminé correctement.
+De plus pour les outils que nous avons pu lancer, #resultratio des analyses ont bien terminé correctement.
 
 #figure(
   image(
@@ -294,22 +296,17 @@ De plus pour les outils que nous avons peu lancer, #resultratio des analyses ont
   caption: [Taux de finition pour le jeu d'application Rasta],
 ) <fig:rasta-exit-fr>
 
-Nous avons ensuite étudier l'évolution du taux de finition des outils au cour des ans.
+Nous avons ensuite étudié l'évolution du taux de finition des outils au cours des ans.
-Le @fig:rasta-exit-evolution-java-fr montre cette évolution pour les outils codé en Java.
+La @fig:rasta-exit-evolution-java-fr montre cette évolution pour les outils codés en Java.
-On peut noter une tendance général où le taux de finition diminu avec le temps.
+On peut noter une tendance générale où le taux de finition diminue avec le temps.
 
-Plusieurs facteurs peuvent être responsable.
+Plusieurs facteurs peuvent être responsables.
-Par exemple, la librairie standard d'Android et le format des applications à évolué avec les versions d'Android.
+Par exemple, la librairie standard d'Android et le format des applications ont évolué avec les versions d'Android.
 Un autre changement notable est la taille du code à octets des applications.
 Les applications les plus récentes ont notablement plus de code.
 
-Plusieurs facteurs peuvent être responsable.
+Pour déterminer le facteur qui influence le plus le taux de finitions, nous avons étudié des sous-ensembles de Rasta avec certains de ces paramètres fixés.
-Par exemple, la librairie standard d'Android et le format des applications à évolué avec les versions d'Android.
+Par exemple, nous avons tracé l'évolution du taux de finition en fonction de l'année de publication des applications sur l'ensemble des applications dont le code à octets fait entre 4.08 et 5.2 Mo.
-Un autre changement notable est la taille du code à octets des applications.
-Les applications les plus récentes ont notablement plus de code.
-
-Pour déterminer le facteur qui influence le plus le taux de finitions, selectionné des sous-ensembles de Rasta avec certains de ces paramètres fixés.
-Par exemple, nous avons tracé l'évolution du taux de finition en fonction de l'année de plublication des applications sur l'ensemble des applications dont le code à octets fait entre 4.08 et 5.2 Mo.
 
 #figure(
   image(
@@ -317,88 +314,87 @@ Par exemple, nous avons tracé l'évolution du taux de finition en fonction de l
     width: 90%,
     alt: ""
   ),
-  caption: [Taux de finition des outils basé sur Java au cour des ans],
+  caption: [Taux de finition des outils basé sur Java au cours des ans],
 ) <fig:rasta-exit-evolution-java-fr>
 
-Nous en avons conlus la réponse à notre question de recherche *QR2*:
+Nous en avons conlu la réponse à notre question de recherche *QR2*:
-Au cour du temps, le taux de finition des outils diminu, allant de 78% à 61% cinq ans plus tard, à 45% dix ans plus tard.
+Au cour du temps, le taux de finition des outils diminue, allant de 78% à 61% cinq ans plus tard, à 45% dix ans plus tard.
 Ce taux varie en fonction de la taille du code à octet, et, dans de moindre mesure, la version d'Android.
 
 
-Pour répondre à notre dernière recherche question, nous avons comparé le taux de finition entre les applications bénines et les maliciels.
+Pour répondre à notre dernière recherche question, nous avons comparé le taux de finition entre les applications bénignes et les maliciels.
-Les résultats semble indiquer que les maliciels sont plus facilement analysé.
+Les résultats semblent indiquer que les maliciels sont plus facilement analysés.
-Pour vérifier cette affirmation, nous avons comparé le taux de finition mais aussi la taille du code à octets des applications et effectivement, il semblerais que ce résultat soit vrai, y compris a taille égale.
+Pour vérifier cette affirmation, nous avons comparé le taux de finition mais aussi la taille du code à octets des applications et effectivement, il semblerait que ce résultat soit vrai, y compris à taille égale.
 
-Nous avons donc une réponse a notre *RQ3*: Les Maliciels cause moins d'erreures lors de leur analyse par des outils d'analyse statique.
+Nous avons donc une réponse à notre *RQ3*: Les maliciels causent moins d'erreurs lors de leur analyse par des outils d'analyse statique.
 
-Finalement, nous avons une réponde à notre première problématique:
+Finalement, nous avons une réponse à notre première problématique:
 
 Plus de la moitié des outils sélectionnés ne sont plus utilisables.
-Dans certains cas, c'est due à notre incapicibilité à les installer correctement, mais majoritairement, c'est due au failbe taux de finition des outils lors de l'analyse des applications.
+Dans certains cas, cela est dû à notre incapicité à les installer correctement, mais majoritairement, cela est dû au faible taux de finition des outils lors de l'analyse des applications.
-Nos résultats montre que les applications avec beaucoup de code sont plus difficile a analyser, et, en moindre mesure, la version d'Android ainsi que la malignité de l'application peut avoir un impact.
+Nos résultats montrent que les applications avec beaucoup de code sont plus difficiles à analyser, et, en moindre mesure, la version d'Android ainsi que la malignité de l'application peut avoir un impact.
 
 ] #[
 
-== Chargeurs de classes au milieu: Dérouter les analyseur static pour Android
+== Chargeurs de classes au milieu: Dérouter les analyseur statiques pour Android
 
 #import "../lib.typ": MWE
 #import "../4_class_loader/X_var.typ": *
 
-Dans ce chapitre, nous étudions comment Android gère le chargement de classe en présence de mutliple versions de la même classe.
+Dans ce chapitre, nous étudions comment Android gère le chargement de classe en présence de mutliples versions de la même classe.
 Nous modélisons l'algorithme de chargement de classe d'Android, et l'utilisons comme base pour une nouvelle famille de brouillage de code que nous appelons _masquage de classes_.
-Nous auditons ensuite des applications publiés en 2023 pour déterminer si cette technique de brouillage est actuellement utilisé.
+Nous auditons ensuite des applications publiés en 2023 pour déterminer si cette technique de brouillage est actuellement utilisée.
 
-Le chargement de classe est une fonctionnalité de Java qu'Android a hérité.
+Le chargement de classe est une fonctionnalité de Java dont Android a hérité.
-Les développeurs intéragissent avec elle le plus souvant au travers de classes héritant de `ClassLoader` pour charger dynamiquement du code.
+Les développeurs intéragissent avec elle le plus souvent au travers de classes héritant de `ClassLoader` pour charger dynamiquement du code.
-Toutefois, il est utilisé a chaque fois qu'un classe est utilisé dans le code.
+Toutefois, elle a un rôle bien plus général.
-A chaque fois qu'Android rencontre une nouvelle classe en exécutant une méthode, il va charger cette classe au traver du méchanisme de chargement de classe.
+#à-maj chaque fois qu'Android rencontre une nouvelle classe en exécutant une méthode, il va charger cette classe au travers du mécanisme de chargement de classe.
 
-L'interet de ce mechanisme est qu'il permet d'utiliser des classes provenant de différent sources.
+L'interet de ce mécanisme est qu'il permet d'utiliser des classes provenant de différentes sources.
-Pour cela, Android associe à chaque class un objet `ClassLoader`, celui qui a été utilisé pour charger cette classe.
+Pour cela, Android associe à chaque classe un objet `ClassLoader`, celui qui a été utilisé pour charger cette classe.
-Par la suite, Android va utilise ce `ClassLoader` pour charger toutes les classes référencées par cette première classe.
+Par la suite, Android utilise ce `ClassLoader` pour charger toutes les classes référencées par cette première classe.
-Pour permettre aux classes provenant de différent `ClassLoader` d'intéragire entre elles, les `ClassLoader` implémente un méchanisme de délégation.
+Pour permettre aux classes provenant de différents `ClassLoader` d'intéragir entre elles, les `ClassLoader` implémentent un mécanisme de délégation.
 Chaque `ClassLoader` a un "parent", un autre objet de type `ClassLoader`, auquel le `ClassLoader` va déléguer le chargement de classe.
-Si la classe n'est pas trouvé par le parent, alors le `ClassLoader` va la charger lui même.
+Si la classe n'est pas trouvée par le parent, alors le `ClassLoader` va la charger lui même.
-Bien que ce système de délégation est utilisé par toutes les classes héritant de `ClassLoader` dans la librairie standard d'Android (à l'execption de `DelegateLastClassLoader` qui délègue dans un ordre légèrement différent), ce comportement est spécifié par l'implémentation de chaque classes `ClassLoader`.
+Bien que ce système de délégation est utilisé par toutes les classes héritant de `ClassLoader` dans la librairie standard d'Android (à l'exception de `DelegateLastClassLoader` qui délègue dans un ordre légèrement différent), ce comportement est spécifié par l'implémentation de chaque classe `ClassLoader`.
-Une application peut très bien définir une nouvelle classes héritant de `ClassLoader` qui n'implémente pas ce processus.
+Une application peut très bien définir une nouvelle classe héritant de `ClassLoader` qui n'implémente pas ce processus.
-Toutefois, ce cas relève de l'analyse dynamique: un `ClassLoader` défini dans l'application ne peut pas être utilisé par Android sans executer du code de l'application pour l'instancier.
+Toutefois, ce cas relève de l'analyse dynamique: un `ClassLoader` défini dans l'application ne peut pas être utilisé par Android sans exécuter du code de l'application pour l'instancier.
-Dans ce chapitre, nous nous concentrons sur le comportement par défaut d'Android, aussi nous n'avons besoins d'analyser que les `ClassLoader` instancier par Android lui même pour lancer l'application.
+Dans ce chapitre, nous nous concentrons sur le comportement par défaut d'Android, aussi nous n'avons besoin d'analyser que les `ClassLoader` instanciés par Android lui même pour lancer l'application.
 
 Le premier `ClassLoader` utilisé par Android est `BootClassLoader`.
 Cette classe est une classe singleton, ce qui signifie qu'il ne peut y avoir qu'une seule instance de la classe par application.
-Elle est utilisé pour charger les classes de platforme.
+Elle est utilisée pour charger les classes de plateforme.
-Ces classes sont les classes implémentées par Android et qui peuvent être utilisées par une application sans qu'elles soient présent dans l'application.
+Ces classes sont les classes implémentées par Android et qui peuvent être utilisées par une application sans qu'elles ne soient présentes dans l'application.
-Elles peuvent être séparés en deux catégories, les classes du KDL (Kit de développement logiciel)  Android, et les classes de l'IPA cachée.
+Elles peuvent être séparées en deux catégories, les classes du KDL (Kit de Développement Logiciel)  Android, et les classes de l'IPA cachée.
 Les premières forment la librairie standard d'Android.
-Elles sont documentés et courament utilisé par les développeurs.
+Elles sont documentées et couramment utilisées par les développeurs.
-Les secondes sont des classes utilisé par Android en interne, mais que les applications ne sont pas supposés utiliser.
+Les secondes sont des classes utilisées par Android en interne, mais que les applications ne sont pas supposées utiliser.
-Elles ne sont pas documentés, et depuis quelques années Android commence a faire des efforts pour empécher les dévellopeurs de les utiliser.
+Elles ne sont pas documentées, et depuis quelques années Android commence a faire des efforts pour empêcher les dévelopeurs de les utiliser.
-Elles sont toutefois encore utilisées, et au moins jusqu'à présent les mesures d'Android ne suffisent pas à les rendre innaccessible.
+Elles sont toutefois encore utilisées, et, au moins jusqu'à présent, les mesures d'Android ne suffisent pas à les rendre innaccessibles.
 
-Ce `BootClassLoader` est utilisé comme le parent par défaut par tout les `ClassLoader` définits dans les classes platformes d'Android.
+Ce `BootClassLoader` est utilisé comme le parent par défaut par tous les `ClassLoader` définis dans les classes plateforme d'Android.
-Quand le parent d'un `ClassLoader` n'est pas définit (quand ca valeure est nulle), les `ClassLoader` vont déléguer au `BootClassLoader` à la place.
+Quand le parent d'un `ClassLoader` n'est pas défini (quand sa valeur est nulle), les `ClassLoader` vont déléguer au `BootClassLoader` à la place.
-L'autre type de `ClassLoader` utilisé par Android par défault est le `PathClassLoader`.
+L'autre type de `ClassLoader` utilisé par Android par défaut est le `PathClassLoader`.
-Cette classe est utilisé pour charger des classes stockés dans des fichiers.
+Cette classe est utilisée pour charger des classes stockées dans des fichiers.
-Android en définis deux par défaut, un `PathClassLoader` "système", et un `PathClassLoader` pour l'application.
+Android en définit deux par défaut, un `PathClassLoader` "système", et un `PathClassLoader` pour l'application.
-La documentation indique que le chargeur "système" est le le chargeur par défaut pour le processus principale.
+La documentation indique que le chargeur "système" est le chargeur par défaut pour le processus principal.
 Toutefois, il ne semble pas être utilisé en pratique.
-Le chargeur de l'application en revanche est utilisé pour les classes contenus dans l'application, c'est donc le chargeur utilisé par défaut pour toutes les classes codé par le développeur.
+Le chargeur de l'application en revanche est utilisé pour les classes contenues dans l'application, c'est donc le chargeur utilisé par défaut pour toutes les classes codées par le développeur.
 
-En plus des chargeurs de classes, il y a un dernier critère a considérer.
+En plus des chargeurs de classes, il y a un dernier critère à considérer.
 Les fichiers #DEX contenant le code à octets des applications ont une limite du nombre de méthodes qui peuvent être référencées.
-Pour y remédier, Android utilise a introduit un nouveau format d'application contenant plusieurs fichiers #DEX.
+Pour y remédier, Android a introduit un nouveau format d'application contenant plusieurs fichiers #DEX.
-Pour notre étude, le point notable de ces appplications est que si Android teste bien qu'un fichier #DEX ne contient qu'une seule implémentation de chaque classe.
+Pour notre étude, le point notable de ces appplications est que bien qu'Android teste qu'un fichier #DEX ne contient qu'une seule implémentation de chaque classe, ce test n'est fait que fichier par fichier: deux fichiers #DEX peuvent contenir une implémentation d'une même classe chacun.
-En revanche, ce test n'est fait que fichier par fichier: deux fichiers #DEX peuvent contenir une implementation d'une même classe chacun.
 Les fichiers #DEX de ces applications "multi-dex" sont nommés `classes.dex`, puis `classesX.dex` où `X` est un entier supérieur ou égale à 2.
-Pour savoir quelle implémentation est utilisé par Android, il faut donc savoir dans quel ordre les fichiers sont visités par les `PathClassLoader`.
+Pour savoir quelle implémentation est utilisée par Android, il faut donc savoir dans quel ordre les fichiers sont visités par les `PathClassLoader`.
 
-Finalement, après avoir étudier le code source d'Android, nous concluons que l'algorithme utilisé est le même que celui que nous avons décrit dans le pseudo code @lst:algo-cl.
+Finalement, après avoir étudié le code source d'Android, nous concluons que l'algorithme utilisé est le même que celui que nous avons décrit dans le pseudo code @lst:algo-cl.
 Cet algorithme a deux points notables.
-En premier lieux, les classes platformes ont toujours la priorité sur les autres classes.
+En premier lieu, les classes platformes ont toujours la priorité sur les autres classes.
-Cela peut sembler évidant pour les classes courantes comme  `String`, mais il faut se rappeler que les classes de l'IPA cachée ne sont pas documentées.
+Cela peut être intuité pour les classes courantes comme `String`, mais il faut se rappeler que les classes de l'IPA cachée ne sont pas documentées.
-Ensuite, les classes sont sélectionné parmis les fichiers #DEX dans un ordre non triviale, et s'arrête a la première implémentation trouvé.
+Ensuite, les classes sont sélectionnées parmis les fichiers #DEX dans un ordre non trivial, et s'arrête à la première implémentation trouvée.
-Le premier fichier testé est `classes.dex`, suivit de `classes2.dex`, puis `classes3.dex` et ainsi de suite, jusqu'à ce qu'un fichier `classesX.dex` n'existe pas.
+Le premier fichier testé est `classes.dex`, suivi de `classes2.dex`, puis `classes3.dex` et ainsi de suite, jusqu'à ce qu'un fichier `classesX.dex` n'existe pas.
-La limite au nombre de fichiers #DEX est très élevé ($2^64$ sur les téléphones actuels), tant que le fichier suivant existe et que la classe n'est pas trouvé, Android va continuer.
+La limite au nombre de fichiers #DEX est très élevée ($2^64$ sur les téléphones actuels), tant que le fichier suivant existe et que la classe n'est pas trouvée, Android va continuer.
 Aussi, le code contenu fichier `classes100.dex` peut être utilisé par Android, ou non, par exemple si `classes99.dex` n'existe pas.
 Plus surprenant, de code contenu dans un fichier `classes1.dex` ou `classes02.dex` ne serra pas utilisé.
 Lors de l'analyse statique d'applications, ces deux points peuvent mener à des complications que nous allons maintenant explorer.
@@ -426,33 +422,33 @@ Lors de l'analyse statique d'applications, ces deux points peuvent mener à des
     else:
       raise ClassNotFoundrror()
    ```,
-  caption: [Algorithme de chargement de class par défaut pour les applications Android],
+  caption: [Algorithme de chargement de classe par défaut pour les applications Android],
 ) <lst:algo-cl>
 
-A partir de cette algorithme, nous avons mis au point plusieur méthodes de brouillage de code que nous appelons _masquage de classe_: la classe utilisé est masqué par une autre implémentation fournis par le dévellopeur.
+A partir de cet algorithme, nous avons mis au point plusieurs méthodes de brouillage de code que nous appelons _masquage de classe_: la classe utilisée est masquée par une autre implémentation fournie par le développeur.
-Nous nous concentrons sur l'obfuscation statique, mais cette stratégie peut être étendu a une approche dynamiquement en utilsant différent chargeur de classes.
+Nous nous concentrons sur l'obfuscation statique, mais cette stratégie peut être étendue à une approche dynamiquement en utilsant différents chargeurs de classes.
 Nous proposons trois techniques dans cette catégorie:
 
 / Auto masquage: Ici, le développeur utilise le format multi-dex pour mettre plusieur implémentations différentes dans la même application.
-  L'objectif est d'exploiter les divergences entre l'algorithme de chargement de classes d'Android et la façon dont les outils d'analyse selection l'implémentation à utiliser.
+  L'objectif est d'exploiter les divergences entre l'algorithme de chargement de classes d'Android et la façon dont les outils d'analyse selectionnent l'implémentation à utiliser.
-  De cette façon, la classe utlisé par Android ne sera pas celle analysé.
+  De cette façon, la classe utlisée par Android ne sera pas celle analysée.
-/ Masquage de KDL: Cette fois, le déveloippeur inclus une implémentation pour une classe de du KDL dans l'application.
+/ Masquage de KDL: Cette fois, le développeur inclut une implémentation pour une classe du KDL dans l'application.
-  Un outils qui ne priorise pas les classes platformes, ou ne les connais pas, va alors utiliser une implémentation invalide de la classe pour son analyse.
+  Un outil qui ne priorise pas les classes plateformes, ou ne les connaît pas, va alors utiliser une implémentation invalide de la classe pour son analyse.
 / Masquage d'IPA Cachée: L'idée est la même que pour la technique précédente, mais cette fois pour une classe de l'IPA caché.
-  Nous distingons masquage de KDL et masquage d'IPA caché car les IPA cachés n'étant pas documenté, il est possible que des outils soient capable de résoudre la première technique mais pas la deuxième.
+  Nous distinguons masquage de KDL et masquage d'IPA caché car les IPA cachés n'étant pas documentés, il est possible que des outils soient capables de résoudre la première technique mais pas la deuxième.
 
-Nous avons vérifié l'impacte de ses techniques sur 4 outils d'analyse Android courant: Jadx, Apktool, Androguard et Flowdroid.
+Nous avons vérifié l'effet de ses techniques sur 4 outils d'analyse Android courants: Jadx, Apktool, Androguard et Flowdroid.
 Le @tab:cl-resultats résume nos conclusions.
-Jadx est un décompillateur d'application.
+Jadx est un décompilateur d'application.
-Lorsqu'il est utilisé pour décompiler une application usant d'auto-masquage, il va selectionner la mauvaise classe, mais indiquer en commentaire la liste des fichiers de code à octet contenant une implementation de la classe.
+Lorsqu'il est utilisé pour décompiler une application usant d'auto-masquage, il va sélectionner la mauvaise classe, mais indiquer en commentaire la liste des fichiers de code à octet contenant une implementation de la classe.
-Apktool et Androguard listent toutes les classes de l'application, il revient donc à l'analiste de choisir la bonne implémentation, et pour les analyses plus poussé d'Androguard, Androguard choisit la mauvaise classe.
+Apktool et Androguard listent toutes les classes de l'application, il revient donc à l'analyste de choisir la bonne implémentation, et pour les analyses plus poussées d'Androguard, Androguard choisit la mauvaise classe.
-Aucun de ses trois outils n'indiquent en aucune façon qu'une classes est déjà définit dans le KDL ou les IPA cachées.
+Aucun de ces trois outils n'indiquent en aucune façon qu'une classes est déjà définie dans le KDL ou les IPA cachés.
 Flowdroid en revanche est capable de détecter les flux de données passant par des classes du KDL, y compris en présence d'une réimplémentation dans l'application.
 Ce n'est par contre pas le cas pour les classes d'IPA cachées.
-Il est intérescant de noter est que Soot, la librairie sur laquelle est basé Flowdroid, à bien un algorithme qui priorise les fichers #DEX, et que cette algorithme est très proche de celuis d'Android.
+Il est intéressant de noter que Soot, la librairie sur laquelle est basé Flowdroid, a bien un algorithme qui priorise les fichers #DEX, et que cet algorithme est très proche de celui d'Android.
-Toutefois, les fichiers commancant par `classes` sont ensuite priorisé par ordre alpha-numérique.
+Toutefois, les fichiers commençant par `classes` sont ensuite priorisés par ordre alphabétique.
-Cela signifie que les classes contenuent dans `classses0.dex`, `classes02.dex` ou `classes10.dex` sont priorisé sur celles de `classes2.dex`.
+Cela signifie que les classes contenuent dans `classes0.dex`, `classes02.dex` ou `classes10.dex` sont priorisées sur celles de `classes2.dex`.
-Ce problème est hérité par Flowdroid, ce qui le rend sensible a la technique d'auto-masquage.
+Ce problème est hérité par Flowdroid, ce qui le rend sensible à la technique d'auto-masquage.
 
 #figure({
   table( 
@@ -481,19 +477,19 @@ Ce problème est hérité par Flowdroid, ce qui le rend sensible a la technique
     table.cell(colspan: 5, inset: 3pt)[],
     table.hline(),
   )
-  [#ok: Le masquage fonctionne \ #warn: Le masquage fonctionne, mais un avertissement est émis ou les plusieurs classes sont visibles \ #ko: Le masquage ne marche pas]
+  [#ok: Le masquage fonctionne \ #warn: Le masquage fonctionne, mais un avertissement est émis ou les différentes implémentations sont visibles \ #ko: Le masquage ne marche pas]
   },
   caption: [Résultats des techniques de masquage contre des outils d'analyse statique]
 ) <tab:cl-resultats>
 
 Pour savoir si ces techniques sont utilisées dans la nature, nous avont scanné #nbapk applications publiées entre janvier 2023 et 2024.
-Pour vérifier que les différentes implémentations sont bien distinctes, nous comparont la représentation smali du code à octets des méthodes.
+Pour vérifier que les différentes implémentations sont bien distinctes, nous comparons la représentation smali du code à octets des méthodes.
 Le @tab:cl-masquage résume ces résultats.
 Il est notable qu'un nombre important d'applications (#scan_only_shadow.at(1).ratioapp%) ont au moins un cas de masquage.
-En étudiant en détail, nous avons noté que la majorité des classes consernées sont des classes introduit entre la version minimal et la version cible d'Android pour l'application.
+En étudiant en détail, nous avons noté que la majorité des classes concernées sont des classes introduites entre la version minimale et la version cible d'Android pour l'application.
-Cela laisse entendre que ces classes ont été rajouté pour permettre a l'application de fonctionner avec les version d'Android où ces classes n'existe pas.
+Cela laisse entendre que ces classes ont été rajoutées pour permettre à l'application de fonctionner avec les versions d'Android où ces classes n'existent pas.
-Le taux élevé de code identique pour les cas d'auto masquage semble également pointé vers des erreures lors de la compilation de l'application.
+Le taux élevé de code identique pour les cas d'auto-masquage semble également pointer vers des erreurs lors de la compilation de l'application.
-De plus, l'analyse manuelle des cas où le smalli diffère montre que les différences vienne des détails lors de la compilation (par exemple, l'inversion de deux registre, ce qui n'as aucune impacte sur l'execution du code).
+De plus, l'analyse manuelle des cas où le smali diffère montre que les différences viennent de détails lors de la compilation (par exemple, l'inversion de deux registres, ce qui n'as aucun effet sur l'exécution du code).
 
 #figure({
   show table: set text(size: 0.80em)
@@ -524,7 +520,7 @@ De plus, l'analyse manuelle des cas où le smalli diffère montre que les diffé
 
       [],
       [], [*%*], [*% maliciel*],
-      [*Classes Masqués*], [*Médianne*], [*KDL*], [*Min KDL*],
+      [*Classes Masquées*], [*Médianne*], [*KDL*], [*Min KDL*],
 
     ),
     table.cell(colspan: 9, inset: 3pt)[],
@@ -556,13 +552,13 @@ De plus, l'analyse manuelle des cas où le smalli diffère montre que les diffé
     table.cell(colspan: 9, inset: 3pt)[],
     table.hline(),
   )},
-  caption: [Classes masqués comparées aux classes platform d'Android IPA 34 pour un jeu de #nbapk applications]
+  caption: [Classes masquées comparées aux classes platform d'Android IPA 34 pour un jeu de #nbapk applications]
 ) <tab:cl-masquage>
 
 Notre conclusion est que le masquage de classes n'est pas activement exploité pour le brouillage de code.
-En revenche, cette situation occure naturellement dans les applications.
+En revanche, cette situation se produit naturellement dans les applications.
 Il est donc important pour les outils d'analyses de modéliser correctement le processus de chargement de classes.
-Avec l'algorithme décrit par le @lst:algo-cl, cela réponde a notre seconde problématique.
+Avec l'algorithme décrit par le @lst:algo-cl, cela répond à notre seconde problématique.
 
 ] #[
 == L'Application de Thésée: Même après avoir ajouté les informations d'exécution, c'est toujours votre application
@@ -570,57 +566,56 @@ Avec l'algorithme décrit par le @lst:algo-cl, cela réponde a notre seconde pro
 #import "../5_theseus/X_var.typ": *
 
 Dans ce dernier chapitre, nous nous penchons sur la question de comment permettre aux outils d'analyse statique d'accéder à des résultats dynamiques.
-Des contributions précédentes ont encodé leur résulat dans l'application elle même pour transmétre leurs résultats à d'autres outils.
+Des contributions précédentes ont encodé leur résulat dans l'application elle-même pour transmettre leurs résultats à d'autres outils.
-Nous allons utiliser cette approche pour permétre à des applications d'analyse statique d'analyser le comportement d'application utilisant de la reflection ou du chargement de code dynamique.
+Nous allons utiliser cette approche pour permettre à des outils d'analyse statique d'analyser le comportement d'applications utilisant de la réflexion ou du chargement de code dynamique.
 
 Premièrement, il nous faut définir la transformation que nous voulons effectuer.
-Concernant la réflection, il y a 3 méthodes permettant d'appeler des méthodes arbitraire dans Android.
+Concernant la réflexion, il y a 3 méthodes permettant d'appeler des méthodes arbitraires dans Android.
 `Class.newInstance()` et `Constructor.newInstance()` permettent d'instancier un nouvel object et d'appeler l'un des ses constructeurs, tandis que `Method.invoke()` permet d'appeler une méthode.
-Les objects `Class`, `Constructor` ou `Method` utilisés pour appeler ces méthodes peuvent être obtenu de multiple façon différente.
+Les objects `Class`, `Constructor` ou `Method` utilisés pour appeler ces méthodes peuvent être obtenus de multiples façons différentes.
-Nous n'allons donc pas chercher à modifier le code obtenant ces objects.
+Nous n'allons donc pas chercher à modifier le code obtenant ces objets.
-A la place, nous allons nous concentrer sur l'appel des méthodes.
+#à-maj la place, nous allons nous concentrer sur l'appel des méthodes.
-A différent moment de l'exécution, un même site peut appeler différentes méthode.
+#à-maj différents moments de l'exécution, un même site peut appeler différentes méthodes.
-De plus, la collection des informations de reflection sera toujours au meilleur effort, il y a des situations où on ne peut jamais être certain d'avoir la liste complète des méthodes appelés.
+De plus, la collection des informations de réflexion sera toujours au meilleur effort: il y a des situations où on ne peut jamais être certain d'avoir la liste complète des méthodes appelées.
-Par exemple, on peut imaginer une application qui appel par réflection une méthode don le nom est obtenue depuis un serveur distant.
+Par exemple, on peut imaginer une application qui appelle par réflexion une méthode dont le nom est obtenu depuis un serveur distant.
-Dans ce cas, sans accès au code du serveur il est impossible d'avoir la liste exaustive des méthodes qui peuvent être utilisé.
+Dans ce cas, sans accès au code du serveur il est impossible d'avoir la liste exhaustive des méthodes qui peuvent être utilisées.
 Pour prendre en compte ces deux cas, nous allons remplacer les appels par des blocs conditionnels.
-Pour chaque méthode dont on sait qu'elle peut être appelé, nous testons si l'object `Method ` correspond a cette méthode en comparant son nom et sa signature.
+Pour chaque méthode dont on sait qu'elle peut être appelée, nous testons si l'object `Method ` correspond à cette méthode en comparant son nom et sa signature.
-Si c'est le cas, la méthode est appelé dans le bloc avec l'instruction Dalvik approrié.
+Si c'est le cas, la méthode est appelée dans le bloc avec l'instruction Dalvik appropriée.
-Si la méthode ne correspond à aucune méthodes connus, alors l'appel est fait par reflection.
+Si la méthode ne correspond à aucune méthode connue, alors l'appel est fait par réflexion.
 Ainsi, le comportement de l'application est conservé.
 
-Pour le chargement de code dynamique, nous avons conclus qu'il n'est pas nécessaire de modifier le code.
+Pour le chargement de code dynamique, nous avons conclu qu'il n'est pas nécessaire de modifier le code.
-A la place, nous pouvons directement ajouter a l'application le ficher #DEX en utilisant le format multi-dex.
+A la place, nous pouvons directement ajouter à l'application le ficher #DEX en utilisant le format multi-dex.
-Toutefois, si jamais certaines classes contenus dans le code que nous injecton sont déja présent dans l'application, nous renommons la classes et ses références de sorte a reproduire statiquement le comportement de l'algorithme de chargement de classe d'Android.
+Toutefois, si jamais certaines classes contenues dans le code que nous injectons sont déja présentes dans l'application, nous renommons la classes et ses références de sorte à reproduire statiquement le comportement de l'algorithme de chargement de classe d'Android.
-Cette approche a des limites, en particulier lors d'appel reflexifs, car il n'existe pas de solutions pour comparer les chargeurs de classes avec une valeur statique.
+Cette approche a des limites, en particulier lors d'appel réflexifs, car il n'existe pas de solutions pour comparer les chargeurs de classes avec une valeur statique.
-Si un même site d'appel reflexif appel deux méthodes avec des signatures et nom identiques mais associées à des classes provenant de chargeurs de classes différent, nous ne somme pas en messure de reproduire exactement le même comportement statiquement.
+Si un même site d'appel réflexif appelle deux méthodes avec des signatures et noms identiques mais associées à des classes provenant de chargeurs de classes différents, nous ne sommes pas en messure de reproduire exactement le même comportement statiquement.
-Toutefois, les deux l'appels aux méthodes apparaissent bien dans la nouvelle application, ce qui devrais permettre aux outils d'analyse statique de considérer les deux cas possible.
+Toutefois, les appels aux deux différentes méthodes apparaissent bien dans la nouvelle application, ce qui devrait permettre aux outils d'analyse statique de considérer les deux cas possible.
 
-Pour pouvois effectuer ces transformations, il nous faut certaines information.
+Pour pouvoir effectuer ces transformations, il nous faut certaines informations.
-Les noms, signature et chargeur de classes des méthodes appelés par reflections, ainsi la position exacte du site de l'appel reflexif, et le code à octets chargé dynamiquement.
+Les noms, signature et chargeur de classes des méthodes appelées par réflexion, ainsi que la position exacte du site de l'appel réflexif, et le code à octets chargé dynamiquement.
-Pour obtenir ces informations, nous utilison Frida, un outils permettant d'injectet des scripts dans les méthodes exécuter pendant l'exécution d'une application Android.
+Pour obtenir ces informations, nous utilisons Frida, un outil permettant d'injecter des scripts dans les méthodes appelées pendant l'exécution d'une application Android.
-Nous avons choisis d'injected nos scripts dans les méthodes de classes platformes d'Android.
+Pour la réflexion, nous avons bien entendu instrumenté `Class.newInstance()`, `Cconstructor.newInstance()` et `Method.invoke()`.
-Pour la reflection, nous avons bien entendu instrumenté `Class.newInstance()`, `Cconstructor.newInstance()` et `Method.invoke()`.
+Pour le chargement de code, le choix est un peu moins évident car il existe de multiples façons de charger du code à octets.
-Pour le chargement de code, le choix est un peu moins évidant, car il existe de multiples façon de charger du code à octets.
+Nous avons finalement choisi `DexFile.openInMemoryDexFileNative()` et `DexFile.openDexFileNative()`, des méthodes de l'IPA cachée.
-Nous avons finalement choisit `DexFile.openInMemoryDexFileNative()` et `DexFile.openDexFileNative()`, des méthodes de l'IPA cachée.
+Ces méthodes sont les dernières méthodes appelées dans l'environement Java avant de passer en native pour analyser et charger le code à octets.
-Ces méthodes sont les dernières méthodes appelé dans l'environement Java avant de passer en native pour charger analyser en charger le code à octets.
+Pour aider à l'exploration des applications, nous avons réutilisé une partie de GroddDroid, un outil dédié à l'exploration dynamique d'applications.
-Pour aider à l'exploration des applications, nous avons réutiliser une parti de GroddDroid, un outils dédier a l'exploration dynamique d'applications.
 
-Nous avons lancé notre analyse statique sur les #num(5000) applications de jeu d'application Rasta publiés en 2023.
+Nous avons lancé notre analyse statique sur les #num(5000) applications publiées en 2023 du jeu d'applications Rasta.
-Malheureusement, les résultats semble indiquer que notre environment d'exécution est insufisant et que beaucoup d'applications n'on pas été visité correctement.
+Malheureusement, les résultats semble indiquer que notre environnement d'exécution est insuffisant et que beaucoup d'applications n'ont pas été visitées correctement.
 Malgrés tout, nous avons collecté #nb_bytecode_collected fichiers de code à octets.
-Toutefois, une fois comparé, nous remarquons que parmis ces fichiers, il n'y a que #num(bytecode_hashes.len()) fichiers distincts.
+Toutefois, une fois comparé, nous remarquons que parmi ces fichiers, il n'y a que #num(bytecode_hashes.len()) fichiers distincts.
-L'inspection du contenu montre que ces fichiers sont principalement des librairies de code publicitaire ou analitiques.
+L'inspection du contenu montre que ces fichiers sont principalement des librairies de code publicitaire ou analytiques.
-Seul #num(nb_bytecode_collected - nb_google - nb_appsflyer - nb_facebook) fichiers parmis les #nb_bytecode_collected collectés ne proviennent ni de Google, ni de Facebook, ni de AppsFlyer.
+Seuls #num(nb_bytecode_collected - nb_google - nb_appsflyer - nb_facebook) fichiers parmi les #nb_bytecode_collected collectés ne proviennent ni de Google, ni de Facebook, ni de AppsFlyer.
-Ces fichiers restant contiennent du code spécifique aux applications les utilisants, principalement des applications exigeant un niveau important de sécurité comme des applications banquaire ou d'assurance santé.
+Ces fichiers restants contiennent du code spécifique aux applications les utilisant, principalement des applications exigeant un niveau important de sécurité comme des applications banquaires ou d'assurance santé.
 
-Nous avons ensuite relancé les outils de notre première contribution sur les applications modifiés pour comparer leur taux de finition comparé à taux sur les applications initials.
+Nous avons ensuite modifié les applications comme décrit précédemment, puis relancé les outils de notre première contribution sur les applications modifiées pour comparer leur taux de finition au taux sur les applications initiales.
 En fonction des outils, le taux de finition est soit inchangé, soit légèrement plus faible pour les applications modifiées (a l'exeption de Saaf #todo[expliquer saaf]
 )
 
-Pour vérifier que notre approche fonctionne, nous avons créé une petite application de test utilsant du chargement dynamique et des appels réflexifs.
+Pour vérifier que notre approche fonctionne, nous avons créé une petite application de test utilisant du chargement dynamique et des appels réflexifs.
 @fig:th-demo-avant montre la classe principale de l'application.
-On peut voir par exemple que que l'application utilise des chaines de caractères chiffrés pour stocker le noms des méthodes à appeler.
+On peut voir par exemple que l'application utilise des chaines de caractères chiffrées pour stocker le nom des méthodes à appeler.
 
 #figure(
   ```java
@@ -652,9 +647,9 @@ public class Main {
   caption: [Code de la classe principale de l'application calculé par Jadx, avant modification],
 )<fig:th-demo-avant>
 
-Après avoir lancer notre analyse statique et instrumenté l'application pour y ajouter les informations dynamique, Jadx montre maintenant le @fig:th-demo-apres.
+Après avoir lancé notre analyse statique et instrumenté l'application pour y ajouter les informations dynamique, Jadx montre maintenant le @fig:th-demo-apres.
 On peut voir que les méthodes `Malicious.get_data()` et `Malicious.send_data()` sont appelées.
-De plus, la classe `Malicious` qui n'était pas présente dans l'application originale est maintenant visible dans l'application modifié.
+De plus, la classe `Malicious` qui n'était pas présente dans l'application originale est maintenant visible dans l'application modifiée.
 
 #figure(
   ```java
@@ -676,12 +671,12 @@ De plus, la classe `Malicious` qui n'était pas présente dans l'application ori
     caption: [Code de `Main.main()` calculé par Jadx, après modifications],
 )<fig:th-demo-apres>
 
-Dans le code de `Malicious`, `get_data()` retourne des données d'une source d'information sensible, et `send_data()` exfiltre les données qui lui sont passé.
+Dans le code de `Malicious`, `get_data()` retourne des données d'une source d'information sensible, et `send_data()` exfiltre les données qui lui sont passées.
-Une fuite d'information devrais donc être détecté par Flowdroid.
+Une fuite d'information devrait donc être détecté par Flowdroid.
-Lancé sur l'application originale, Flowdroid calcul un graphe d'appel de méthodes contenant 43 arcs, et ne détecte aucune fuite.
+Lancé sur l'application originale, Flowdroid calcule un graphe d'appel de méthodes contenant 43 arcs, et ne détecte aucune fuite.
-En revanche, lancé sur l'application modifié, Flowdroid calcul cette fois un graphe de 76 arsc, et détecte bien la fuite de donné.
+En revanche, lancé sur l'application modifiée, Flowdroid calcule cette fois un graphe de 76 arsc, et détecte bien la fuite de données.
 
-Bien que nous n'aillons pas peu tester notre approche correctement à grande échelle du aux limites de notre environnement d'analyse statique, nous avons bien montré qu'il est possible de transmètre des informations dynamiques a des outils d'analyse statique pour améliorer leurs résultat.
+Bien que nous n'ayons pas pu tester notre approche correctement à grande échelle dû aux limites de notre environnement d'analyse statique, nous avons bien montré qu'il est possible de transmettre des informations dynamiques à des outils d'analyse statique pour améliorer leurs résultat.
 
 
 ] /*#[

corrections_resume_fr_v1.txt

@@ -0,0 +1,323 @@
+Titre : les inconvénients de l’analyse STATIQUE
+7 : toutes plateformes confondues
+11 : a été fait
+12 : leurs propres difficultés
+12 : par exemple
+13 : les applications sont distribuées
+13 : lui-même
+17 : peuvent être utilisés
+19 : très
+20 : grosses
+21 : développés
+22 : exemple
+24 : s’il existe
+27 : difficiles à utiliser
+27 : s’ils fonctionnent
+28 : construites
+29 : de vraies applications
+29 : cela pose
+29 : À quel point, avec un accent sur le A majuscule, mais ce n’est pas obligatoire
+30 : sont-ils utilisables
+33 : pendant son exécution
+33 : ses faiblesses (c’est rigolo tu as fait moitié-moitié, genre « je ne sais pas me décider entre ces et ses donc au moins y en aura un de bon)
+33 : certains problèmes
+34 : associés
+36 : prévus
+36 : a hérité
+37 : utilise
+38 : utilisé
+39 : disponible
+40 : initialement
+40 : à l’analyse dynamique
+40 : il semblerait
+41 : souvent
+42 : dans son ensemble
+42 : détaillée
+42 : mécanisme
+44 : est-ce qu’il
+48 : « une référence vers méthode » : c’est peut-être une expression informatique spécifique mais si ce n’est pas le cas il faudrait mettre un déterminant à méthode (la méthode, une méthode…)
+50 : quand elle ne l’est pas
+50 : e.g. est de l’anglais, en français ce serait plutôt par ex.
+50 : la chaine est envoyée
+51 : exécution
+51 : ou elle est stockée : orthographié ainsi c’est le « ou » de « ou bien » de la disjonction de cas, sinon il faut un accent : où
+51 : elle est stockée, chiffrée, et n’est déchiffrée qu’au dernier moment
+53 : les méthodes appelées
+54 : je mettrais plutôt : il n’existe pas de solution standard
+54 : analysise c’est un terme technique ou bien tu voulais dire analyse ?
+55 : son entièreté
+55 : Certaines
+56 : ingénierie
+58 : prometteuse
+58 : utiliser
+59 : réflexion
+59 : les informations collectées
+60 : analyse statique
+61 : analyse statique
+65 : considérer
+67 : échouent à calculer
+69 : encore
+70 : raisonnable
+71 : évolue-t-elle
+71 : analyse
+72 : publié : si c’est les applications, alors : publiées
+72 : d’écart
+73 : est-ce que
+73 : analyse
+73 : bénigne (sauf si c’est un terme spécifique)
+79 : compilées
+80 : sélectionné
+80 : certains outils
+81 : maintenus
+81 : suite à
+83 : que nous avons trouvé
+86 : nous-même (ou nous-mêmes, c’est assez fourbe, si tu utilises le « nous » de majesté pour parler uniquement de toi, alors c’est « nous-même », mais si tu utilises « nous » pour parler de toi et ton équipe, alors c’est « nous-mêmes »)
+89 : exécution
+90 : montrent
+91 : réussie
+92 : plus d’une heure à finir
+92 : avortée
+93 : ne s’en sortent
+93 : « pas trop mal » ce n’est pas très distingué, enfin c’est toi qui vois
+95 : résultats
+96 : d’autres outils avec un résultat acceptable
+97 : permettent
+97 : à la notre première question : il faut choisir !
+99 : « que nous avons pu lancer » ? « que nous avons peu lancé » ?
+Tableau 1 : Dédié à la sécurisation d'Android
+Tableau 1 : ne compile pas
+Tableau 1 : décision
+100 : étudié
+100 : au cours des ans
+100 : La Fig.3
+101 : codés
+101 : une tendance générale
+102 : diminue
+103 : responsables
+103 : exemple
+104 : ont évolué
+Tableau 2 : Auteurs contactés ou Auteur contacté mais pas un mélange des deux
+Tableau 2 : version sélectionnée et environnement d’exécution
+107-110 : répétition de 103-106
+111-112 : phrase douteuse, il manque un sujet et un verbe
+112 : exemple
+113 : publication
+115 : conclu
+116 : diminue
+120 : bénignes (sauf si c’est un terme technique spécifique)
+120 : semblent
+Fig.3 : au cours des ans
+121 : analysés
+122 : il semblerait
+123 : à taille égale
+124 : à notre
+124 : causent
+124 : erreurs
+126 : réponse
+127 : c’est dû
+128 : incapacité ?
+128 : dû
+128 : faible
+129 : montrent
+130 : difficiles
+132 : les analyseurs statiques (à moins que ce ne soit un terme technique issu de l’anglais)
+135 : multiples
+138 : utilisée
+139 : dont Android a hérité
+140 : souvent
+141 : à chaque fois
+141 : utilisée
+143 : au travers du mécanisme
+144 : mécanisme
+144 : différentes sources
+145 : classe ?
+146 : va utiliser / utilise
+148 : différents ClassLoader
+148 : d’interagir
+148 : implémentent
+148 : un mécanisme
+150 : si la classe n’est pas trouvée
+152 : exception
+154 : de chaque classe
+155 : une nouvelle classe
+157 : exécuter
+159 : besoin
+159 : instanciés
+163 : elle est utilisée
+163 : plateforme
+164 : sans qu’elles ne soient présentes
+165 : séparées
+167 : elles sont documentées et couramment utilisées
+168 : utilisées
+169 : supposées
+169 : documentées
+170 : empêcher
+170 : développeurs
+172 : inaccessibles
+173 : tous les ClassLoader définis / toutes les ClassLoader définies
+174 : plateforme
+174 : pas défini
+175 : quand sa valeur
+176 : défaut
+177 : utilisée
+177 : stockées
+177 : en définit deux
+179 : le chargeur par défaut (répétition de « le »)
+179 : le processus principal
+181 : les classes contenues
+182 : codées
+183 : à considérer
+185 : Android utilise a introduit : l’un ou l’autre, mais pas les deux
+187 : « le point est que si Android machin » : soit tu dis « le point est que Android machin », soit il manque la fin de la phrase (si Android machin, alors truc)
+189 : implémentation
+191 : utilisée
+193 : avoir étudié
+195 : en premier lieu
+196 : évident (et non, c’est pas évident, en tout cas pas pour moi)
+198 : sélectionnées
+198 : non trivial
+198 : à la première
+199 : suivi de
+201 : la limite est très élevée
+202 : que la classe n’est pas trouvée
+203 : par exemple
+208 : cet algorithme
+208 : plusieurs méthodes
+209 : la classe utilisée est masquée
+210 : une autre implémentation fournie par le développeur
+Code 1 : classe par défaut
+211 : cette stratégie peut être étendue
+211 : à une approche
+211 : différents
+216 : sélectionnent ?
+216-217 : la classe sélectionnée ne sera pas celle utilisée
+218 : le développeur
+218 : inclut
+219 : une classe du KDL ou une classe de KDL mais pas les deux en même temps
+219 : un outil
+219 : plateformes
+220 : ne les connaît pas
+222 : nous distinguons
+223 : n’étant pas documentés
+223 : capables
+225 : l’impact (et d’ailleurs, plutôt, l’effet ; en français un impact c’est un truc qui cogne)
+225 : outils d’analyse Android courants
+227 : décompilateur
+228 : sélectionner
+Tableau 3 : « un avertissement est émis ou les plusieurs classes sont visibles » : pas clair
+230 : l’analyste
+231 : les analyses plus poussées
+232 : aucun de ces trois outils
+232 : qu’une classe est déjà définie
+235 : intéressant
+235 : de noter que Soot ?
+236 : a bien
+237 : cet algorithme
+237 : celui d’Android
+237 : commençant
+238 : priorisés
+238 : contenues
+239 : classses0.dex : est-ce normal qu’il y ait trois s à classses ?
+239 : priorisées
+240 : à la technique
+243 : nous comparons
+246 : concernées
+246 : introduites
+246 : la version minimale
+247 : rajoutées
+247 : permettre à l’application
+248 : des versions
+248 : n’existent pas
+249 : pointer
+249 : erreurs
+Tableau 4 : classes masquées
+251 : ces différences viennent
+251 : par exemple
+252 : deux registres, ce qui n’a aucun impact sur l’exécution du code).
+254 : en revanche
+254 : cette situation se produit naturellement
+256 : cela répond à
+261 : l’application elle-même
+261 : transmettre
+262 : permettre
+263 : d’applications
+263, 266 : réflexion
+266 : des méthodes arbitraires
+270 : peuvent être obtenus
+270 : de multiples façons différentes
+271 : ces objets
+272 : à différents moments
+272 : différentes méthodes
+273 : « sera toujours au meilleur effort » : j’ai pas compris
+273 : réflexion
+274 : des méthodes appelées
+274 : par exemple
+275 : une application qui appelle par réflexion une méthode dont le nom est obtenu
+277 : exhaustive (mais celle-là je te pardonne)
+277 : qui peuvent être utilisées
+279 : qu’elle peut être appelée
+279 : correspond à cette méthode
+280 : la méthode est appelée
+281 : l’instruction appropriée
+281 : aucune méthode connue
+282 : réflexion
+283 : nous avons conclu
+284 : ajouter à l’application
+285 : certaines classes contenues
+286 : que nous injectons
+286 : sont déjà présentes
+287 : de sorte à reproduire
+290 : appelle deux méthodes
+291 : chargeurs de classes différents
+291 : nous ne sommes pas
+292 : les deux appels ?
+293 : ce qui devrait
+295 : pour pouvoir
+295 : certaines informations
+296 : des méthodes appelées
+296 : ainsi que
+298 : un outil
+298 : d’injecter
+298 : exécutées
+299 : Nous avons choisi d’injecter
+300 : plateformes, réflexion
+302 : un peu moins évident
+302 : de multiples façons
+303 : nous avons finalement choisi
+305 : appelées
+305-306 : « pour charger analyser en charger » : pas compris mais il y a un problème
+306 : nous avons réutilisé
+307 : une partie
+307 : un outil dédié à
+308 : publiés en 2023 : tu parles du jeu d’applications ou des applications ? Dans les deux cas l’accord est incorrect
+309 : environnement
+310 : insuffisant
+310 : visitées
+310 : malgré tout
+312 : parmi ces fichiers
+313 : analytique
+313 : seuls 13 fichiers
+314 : parmi
+315 : ces fichiers restants
+315 : les utilisant
+316 : bancaires
+318 : des applications modifiées
+319 : « comparer leur taux de finition comparé à taux » : pas compris
+319 : sur les applications initiales
+323 : utilisant
+324 : par exemple
+324 : que l’application (répétition de « que »)
+325 : chiffrés si ce sont les caractères qui sont chiffrés, chiffrées si ce sont les chaines
+325 : le nom
+326 : après avoir lancé
+330 : l’application modifiée
+332 : les données qui lui sont passées
+332 : devrait
+333 : calcule
+335 : l’application modifiée
+335 : calcule
+335 : la fuite de données
+336 : Bien que nous n’ayons pas pu tester ?
+336 : dû
+338 : transmettre
+338 : à des outils

lib.typ

@@ -39,14 +39,16 @@
 #let jm-note = note.with(stroke: purple + 1pt)
 #let jfl-note = note.with(stroke: green + 1pt)
 
+#let à-maj = "À"
+
 #let pb1 = link(<pb-1>)[*Pb1*]
 #let pb1-text = [_To what extent are previously published Android analysis tools still usable today, and what factors impact their reusability?_]
-#let pb1-text-fr = [_A quel point les outils d'analyse Android préalablement publiés sont utilisable aujourd'hui, et quels facteurs impactent leur réutilisabilité?_]
+#let pb1-text-fr = [_#à-maj quel point les outils d'analyse Android préalablement publiés sont-ils utilisables aujourd'hui, et quels facteurs impactent leur réutilisabilité?_]
 
 #let pb2 = link(<pb-2>)[*Pb2*]
 #let pb2-text = [_What is the default Android class loading algorithm, and does it impact static analysis?_]
-#let pb2-text-fr = [_Quel est l'algorithme de chargement de classe utilisé par défaut par Android, et est ce qu'il impacte l'analyse statique?_]
+#let pb2-text-fr = [_Quel est l'algorithme de chargement de classe utilisé par défaut par Android, et est-ce qu'il impacte l'analyse statique?_]
 
 #let pb3 = link(<pb-3>)[*Pb3*]
 #let pb3-text = [_Can we use instrumentation to provide dynamic code loading and reflection data collected dynamically to static analysis tools and improve their results?_]
-#let pb3-text-fr = [_Peut-on utliser l'instrumentation pour fournir le code chargé dynamiquement et les informations de réflection collecté dynamiquement aux outils d'analyse static pour améliorer leurs résultats?_]
+#let pb3-text-fr = [_Peut-on utiliser l'instrumentation pour fournir le code chargé dynamiquement et les informations de réflexion collectées dynamiquement aux outils d'analyse statique pour améliorer leurs résultats?_]

main.typ

@@ -52,7 +52,7 @@
 
 
 #show: matisse-thesis.with(
-  title-fr: [Rétro-Ingénierie d'applications Android: les inconvénients de l'analyse static], // malheurs -> inconvénients ?
+  title-fr: [Rétro-Ingénierie d'applications Android: les inconvénients de l'analyse statique], // malheurs -> inconvénients ?
   // Because "Android Skuldgerries and Other Headache Inducing Fuckeries" won't pass the vibe check
   title-en: [Android Application Reverse Engineering: the Woes of Static Analysis],
   author: "Jean-Marie MINEAU",

main_french.typ

@@ -3,7 +3,7 @@
 #import "jury.typ": jury-content
 
 #show: matisse-thesis.with(
-  title-fr: [Rétro-Ingénierie d'applications Android: les inconvénients de l'analyse static], // malheurs -> inconvénients ?
+  title-fr: [Rétro-Ingénierie d'applications Android: les inconvénients de l'analyse statique], // malheurs -> inconvénients ?
   title-en: [],
   author: "Jean-Marie MINEAU",
   affiliation: "IRISA",