review

6_conclusion/2_futur.typ

@@ -1,4 +1,5 @@
-#import "../lib.typ": todo, AOSP, eg
+#import "../lib.typ": AOSP, eg, DEX, APK, ART
+#import "../lib.typ": todo, jfl-note
 
 == Perspectives for Future Work
 
@@ -6,20 +7,20 @@ In this section, we present what, in light of this thesis, we believe to be wort
 
 The main issue that appeared in all our work appears to be 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.
+@sec:cl also showed that reproducing the exact behaviour of Android is more difficult than it seems (in our specific case, it was the class loading algorithm, but we can expect other features to have similar edge cases).
 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.
+For instance, the parsing of #DEX, #APK and ressource files could be done using the same code as the #ART.
 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.
+Dynamic analysis relying on patched versions of the #AOSP showed that it is difficult to maintain this kind of software time.
 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.
+Another obstacle to overcome is to decouple the compilation of the tool from the rest of #AOSP: it is a massive dependency 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.
 Should those issues be solved, directly using the code from #AOSP would allow such a tool to keep up with each new version of Android and limit invalid assumptions about Android behaviour.
 
-An orthogonal solution to this problem is to create a new benchmark.
+An orthogonal solution to this problem is to create a new benchmark, to test the capacity of a tool to handle real-life applications.
 Benchmarks are usually targeted at some specific technique (#eg taint tracking), and accordingly, test for issues specific to the targeted technique (#eg accurately tracking data that passes through an array).
-This one should test the capacity of a tool to handle real-life applications.
 We suggest using a similar method to what we did in @sec:rasta to keep the benchmark independent from the tested tools.
 Instead of checking the correctness of the tools, this benchmark should test if the tool is able to finish its analysis.
 Applications in this benchmark could either be real-life applications that proved difficult to analyse (for instance, applications that crashed many of the tested tools in @sec:rasta), or hand-crafted applications reproducing corner cases or anti-reverse techniques encountered while analysing obfuscated applications (for instance, an application with gibberish binary file names inside `META-INF/` that can crash Jadx zip reader).
@@ -30,7 +31,13 @@ The main challenge with such a benchmark is that it would need frequent updates
 // Futur work: mon unique pov pour le futur: what need to be done
 
 
-#todo[
+#jfl-note[
   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
 ]
+
+#jfl-note[
+  Une perspective pour le reverser?
+  qu'est ce qu'il aimerait avoir?
+  Benchmarker a vec des humains reverser, la vitesse de reverse de good/mal avec différent outils?
+]

X_appendices/released_software.typ

@@ -44,10 +44,14 @@ The container images used to run the different tools are available on Zenodo at
 
 The list of applications we scanned in @sec:cl, as well as the lists of platform classes, fields and, methods we extracted from the emulators for Android #SDKs 32, 33, and 34, are stored on Zenodo at https://doi.org/10.5281/zenodo.15846481.
 
+#jfl-note[Et le dataset utilsé pour évaluer les outils?]
+
 == Theseus
 
 The scripts we used for dynamic analysis and the code implementing the transformations described in @sec:th are available at the following locations:
 
+#jfl-note[Ajouter les licences]
+
 - https://gitlab.inria.fr/pirat/android/android-of-theseus
 - https://git.mineau.eu/these-android-re/android_of_theseus
 - https://github.com/histausse/android_of_theseus
@@ -59,3 +63,6 @@ Androscalpel can be found at the following locations:
 - https://git.mineau.eu/these-android-re/androscalpel
 - https://github.com/histausse/androscalpel
 
+#jfl-note[
+  Et le dataset?
+]