wip

1_introduction/main.typ

@@ -124,9 +124,11 @@ The contributions of this thesis are the following:
   This work was published in the Digital Threats journal~@classloaderinthemiddle.
 + We propose an approach to allow static analysis tools to analyse applications that perform dynamic code loading:
   We collect at runtime the bytecode dynamically loaded and the reflection calls information, and patch the #APK file to perform those operations statically.
-  Finally, we evaluate the impact this transformation has on the tools we containerised previously.#jfl-note[Dire 2 mots sur la méthode de patch qui a été reimplémentée pour être robuste? \ jm: j'ai pas eu le temps de comparer avec soot/droidRA, je trouve que sans xp ca fait trop trust me bro #emoji.cat.face.cry]
+  Finally, we evaluate the impact this transformation has on the tools we containerised previously.
-
++ We released under the GPL licence #todo[Still waiting for the INRIA to validate] the software we used in the experiments presented in this thesis. 
-#jfl-note[We release a buch of open source sofware to help the research community: rasta, androscalpel, theseus \ jm: rasta ok, androscalpel/theseus peut être mais j'attend tj le ok de l'inria]
+  For @sec:rasta, this includes the code used to test the output of each tool and the code to analyse the results of the experiment, in addition to the containers to run the tested tools.
+  We also released Androscalpel, a Rust crate to manipulate Dalvik bytecode, that we used to create Theseus, a set of scripts that implement the approach presented in @sec:th.
+  The complete list and location of the software we release are available in @sec:soft.
 
 == Outline
 

6_conclusion/1_contributions.typ

@@ -11,7 +11,7 @@ First, we explored the reusability of static analysis tools.
 Based on a systematic literature review by Li #etal, we identified 22 tools of interest, published between 2012 and 2017.
 To estimate the current usability of those tools, we tested their most recent version on a large dataset of #rasta.NBTOTALSTRING applications.
 We then counted the number of analyses that finished and returned a result.
-We established that #rasta.resultunusable of #rasta.nbtoolsselectedvariations tools are not reusable.
+We established that #rasta.resultunusable of #rasta.nbtoolsselectedvariations tools are not reusable, in particular when the applications are recent.
 We were not able to use two of them, even with the help of the authors, while 10 others failed to finish their analysis more than half the time.
 The study of the finishing rate of the tools for applications grouped by their characteristics showed that the greater bytecode size increases the chance of analysis failure.
 The same goes for min #SDK version to a lesser extent, and it appears that analyses of malware are less likely to encounter a fatal error than analyses of goodware.

6_conclusion/2_futur.typ

@@ -1,8 +1,25 @@
-#import "../lib.typ": todo
+#import "../lib.typ": todo, AOSP
 
 == Perspectives for Future Work
 
-#todo[What futur work]
+#todo[
+  Intro
+  In this section, we will discuss avenues of work raised by this thesis ?
+  The work presented in this thesis revealed avenues to improve ??. The following section will present those new avenues.
+]
+
+The main issue that appeared in all our work is an engineering one.
+The error we analysed in @sec:rasta showed that even something that should be basic, reading the content of an application, can be challenging.
+@sec:cl also showed that reproducing the exact behaviour of Android is more difficult than it seems.
+As long as those issues are not solved, we cannot build robust analysis tools.
+One avenue we believe should be investigated would be to reuse the code actually used by Android.
+This is possible thanks to #AOSP being open-source, and is already partially done by some Android build tools.
+However, this is not an easy solution.
+Dynamic analysis relying on patched versions of the #AOSP showed that it is difficult to maintain over time software relying on the Android source.
+Doing this would require limiting the modifications to the actual source code of Android to lower the changes needed at each update of Android.
+Another obstacle to overcome is to decouple the compilation of the tool from the rest of #AOSP: it is a massive dependence that needs a lot of resources to build.
+Having such a dependency would be a barrier to entry, preventing others from modifying or improving the tool.
+
 
 #todo[
   Ideas:
@@ -13,5 +30,12 @@
     Robust default, close to Android: the java zip parser is often targeted, there is something to be done here
 ]
 
+#todo[web-base? flutter? wasm?]
+
 // Futur work: mon unique pov pour le futur: what need to be done
-// future work plus haut niveau: reprandre les plus important et/ou des plus large: eg: quide web-base? flutter? wasm ?
+
+
+#todo[
+  jfl: des pistes pour custom class loader
+  jm: oui mais deja données dans ch 4 et c'est quand meme assez spécifique est pas trop le point general de la these
+]

X_appendices/released_software.typ

@@ -1,6 +1,6 @@
 #import "../lib.typ": etal
 
-= Released Software
+= Released Software <sec:soft>
 
 In @sec:rasta, we mentioned that we had some difficulties finding some software listed by Li #etal following the disappearance of the original websites hosting it.
 To limit the risk of having the same issue, we hosted the different pieces of software we released for this thesis in several locations.

abstract.typ

@@ -13,20 +13,16 @@
   First, we pursue a community effort that identified contributions between 2011 and 2017 about static analysis of Android applications, and we propose a method to evaluate the reusability of the associated tools.
   An extensive analysis of the execution failures of those tools shows that #resultunusable of them are no longer usable.
   Then, we model the mechanism that loads the classes used by an application and present an obfuscation method based on the discrepancies between this model and the one used by analysis tools like Androguard and Flowdroid.
-  Finally, we propose an approach consisting of encoding the result of a dynamic analysis inside a new valid application to allow existing tools to analyse applications that rely on dynamic code loading.
+  Finally, we propose an approach that consists of encoding the result of a dynamic analysis within a new valid application, allowing existing tools to analyse applications that rely on dynamic code loading.
-
 ]
 
 #let abstract-fr = [
   La place croissante des téléphones mobiles dans notre vie quotidienne en font une cible de choix pour les acteurs malveillants.
   Cette menace rend l'analyse d'application cruciale pour déterminer s'il s'agit ou non d'un maliciel et de son impact sur l'utilisateur s'il s'agit bien d'une application malveillante.
-  
 
   Cette thèse explore les difficultés liées à l'ingénierie inverse d'applications Android.
   Dans un premier temps, elle reprend un effort de la communauté qui a identifié les contributions entre 2011 et 2017 portant sur l'analyse statique d'applications mobiles et propose une méthode pour évaluer la réutilisabilité des outils associés.
   Une étude poussée des échecs lors de l'exécution de ces outils montre que #resultunusable d'entre eux ne sont plus utilisables.
   Elle modélise ensuite le processus de chargement des classes utilisées par une application et présente une méthode de brouillage basée sur les différences entre ce modèle et celui utilisé par des outils d'analyses tels que Androguard ou Flowdroid.
   Enfin, elle propose une approche consistant à encoder les résultats d'une analyse dynamique dans une nouvelle application valide pour permettre aux outils existants d'analyser des applications faisant usage de chargement de code dynamique.
-
-    
 ]

main.typ

@@ -78,7 +78,7 @@
   keywords-fr: keywords-fr,
   abstract-en: abstract-en,
   abstract-fr: abstract-fr,
-  //abstract-font-size: 10pt,
+  abstract-font-size: 10pt,
   draft: draft,
   show_cover: show_cover,
   show_body: show_body,
@@ -133,10 +133,12 @@
 
 
 #{
-  set heading(numbering: none, outlined: true, bookmarked: true)
+  counter(heading).update(0)
-  set figure(outlined: false)
+  set heading(numbering: "A.1", outlined: false, bookmarked: true)
+  show heading.where(level: 1): set heading(supplement: [Appendix])
   //set page(numbering: "i")
   //counter(page).update(0)
+  set figure(outlined: false)
 
   pagebreak(to: "odd")
   {