small update of the french summary

0_preamble/french_summary.typ

@@ -29,13 +29,13 @@ Par exemple, Flowdroid a pour objectif de détecter les fuites d'informations: l
 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 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 pose la problématique #pb1-text-fr
+Cela pose la problématique suivante: #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 pendant son exécution.
 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évus pour être codé en Java, et donc Android a hérité de beaucoup de fonctionnalités de Java.
+Les applications Android sont initiallement prévues pour être codées en Java, Android a donc a hérité de nombreuses fonctionnalités de Java.
 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 disponible dans l'application initialement, ce problème est 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.
@@ -51,9 +51,6 @@ Il n'existe pas de solution standard pour transmettre ces données aux outils d'
 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 prometteuse motive notre troisième problématique: #pb3-text-fr
 
-
-#todo[Bouger le résumé a la fin fr à la fin?]
-
 #[
 == Evaluation de la réutilisabilité des outils d'analyse statique pour Android
 
@@ -67,7 +64,7 @@ Au contraire, dans ce chapitre nous allons considérer comme correct tout résul
 
 Les questions auxquelles nous voulons répondre sont:
 
-/ QR1: Quels outils d'analyse statique pour Android vieux de plus de 5 ans peuvent encore être utilisé aujourd'hui avec un effort raisonnable?
+/ QR1: Quels outils d'analyse statique pour Android vieux de plus de 5 ans peuvent encore être utilisés aujourd'hui avec un effort raisonnable?
 / 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 analyse une application bénigne comparé à un maliciel?
 
@@ -152,7 +149,7 @@ Nous avons éliminé les outils utilisant de l'analyse dynamique en plus de l'an
 Nous avons ensuite sélectionné la version des outils à utiliser.
 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 avons trouvé est celui d'IC3, que nous avons décidé d'inclure en plus d'IC3.
+Le seul cas de branchement intéressant que nous avons trouvé est celui d'IC3, que nous avons décidé d'inclure en plus de la version originale.
 Le @tab:rasta-choix-sources résume cette étape.
 
 #figure({
@@ -334,7 +331,7 @@ Nous avons donc une réponse à notre *RQ3*: Les maliciels causent moins d'erreu
 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, 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.
+Dans certains cas, cela est dû à notre incapacité à les installer correctement, mais majoritairement, cela est dû au faible taux de finition des outils lors de l'analyse des applications.
 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.
 
 ] #[
@@ -346,7 +343,7 @@ Nos résultats montrent que les applications avec beaucoup de code sont plus dif
 
 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ée.
+Nous analysons 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 dont Android a hérité.
 Les développeurs intéragissent avec elle le plus souvent au travers de classes héritant de `ClassLoader` pour charger dynamiquement du code.
@@ -440,7 +437,7 @@ Nous proposons trois techniques dans cette catégorie:
 / 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 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'effet de ses techniques sur 4 outils d'analyse Android courants: Jadx, Apktool, Androguard et Flowdroid.
+Nous avons vérifié l'effet de ses techniques sur 4 outils de rétro-ingénierie Android courants: Jadx, Apktool, Androguard et Flowdroid.
 Le @tab:cl-resultats résume nos conclusions.
 Jadx est un décompilateur d'application.
 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.
@@ -579,7 +576,7 @@ Les objects `Class`, `Constructor` ou `Method` utilisés pour appeler ces métho
 Nous n'allons donc pas chercher à modifier le code obtenant ces objets.
 #à-maj la place, nous allons nous concentrer sur l'appel des méthodes.
 #à-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 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.
+De plus, la collection des informations de réflexion ne sera jamais parfaite: 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 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 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.
@@ -612,6 +609,38 @@ L'inspection du contenu montre que ces fichiers sont principalement des librairi
 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 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é.
 
+La @tab:th-comparaison-graph-appel montre le nombre d'arc du graph d'appel de fonction de ces quelques applications qui charge du code dynamiquement spécifique à leurs usage.
+La colonne "Réflection Ajoutées" correspond au nombre d'appels reflectives ajouté a l'applications.
+Les autres arcs ajoutés sont soit des fonctions "colle" que nous avont ajouté a l'application pour choisir la bonne méthode à appeler reflectivement, soit des méthodes appelé par du code chargé dynamiquement auquel Androguard n'avais pas accès avant l'instrumentation.
+On peut voir que notre méthode permet effectivement à Androguard de calculer un plus grand graphe.
+
+#figure({
+  let nb_col = 5
+  table(
+    columns: (2fr, 1fr, 1fr, 1fr, 2fr),
+    align: center+horizon,
+    stroke: none,
+    table.hline(),
+    table.header(
+      //[SHA 256], [Original CG edges], [New CG edges], [Edges added], [Reflection edges added],
+      table.cell(rowspan: 2)[#APK SHA 256], table.cell(colspan: nb_col - 1)[Nombre d'arcs du graphe d'appel], [Avant], [Après], [Différences], [Réflection Ajoutées],
+    ),
+    table.hline(),
+    ..compared_callgraph.map(
+      //(e) => ([#lower(e.sha256).slice(0, 10)...], num(e.edges_before), num(e.edges_after), num(e.added), num(e.added_ref_only))
+      (e) => (
+        [#lower(e.sha256).slice(0, 10)...],
+        text(fill: luma(75), num(e.edges_before)),
+        text(fill: luma(75), num(e.edges_after)),
+        num(e.added),
+        num(e.added_ref_only)
+    )).flatten(),
+    //[#lower("5D2CD1D10ABE9B1E8D93C4C339A6B4E3D75895DE1FC49E248248B5F0B05EF1CE").slice(0, 10)...], table.cell(colspan: nb_col - 1)[_Instrumentation Crashed_],
+    table.hline(),
+  )},
+  caption: [Arcs ajoutés aux graphes d'appel de fonctions des applications instrumentées, calculé par Androguard]
+) <tab:th-comparaison-graph-appel>
+
 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.