fw

6_conclusion/2_futur.typ

@@ -1,4 +1,4 @@
-#import "../lib.typ": AOSP, eg, DEX, APK, ART
+#import "../lib.typ": AOSP, eg, DEX, APK, ART, API
 #import "../lib.typ": todo, jfl-note
 
 == Perspectives for Future Work
@@ -26,18 +26,17 @@ Instead of checking the correctness of the tools, this benchmark should test if
 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).
 The main challenge with such a benchmark is that it would need frequent updates to follow Android evolutions, and be diverse enough to encompass a large spectrum of possible issues.
 
-#todo[web-base? flutter? wasm?]
+Lastly, our experience with dynamic analysis led us to believe that there is a need for a new protocol and/or #API for automatic testing.
+Currently, except for intrusive methods like instrumentations, interacting with an application is done through a mix of #ADB and UI Automator.
+Unfortunately, those tools give very poor feedback.
+Information about the execution is mostly found in the Android logs, lost among other system events, and it is difficult to filter the events related to the application without losing critical data.
+For instance, exception logs are usually linked to the application in the Android logs, but some exceptions originating from the #ART (and not the code of the application itself) are logged as system errors.
+Similarly, an application can fail to install, or successfully install but later be quarantined or uninstalled by the Android operating system, without clear feedback.
+Another issue is that more and more, Android will require interactions with the system (for instance, with a security permission pop-up), and those interactions are not handled by UI Automator.
+Similarly, when an application opens another one for a specific task (opening a document, for example), what is happening is unclear from the standpoint of UI Atomator.
+We think that an #API or protocol that merges and delivers in a structured way all those informations, and allows access to the relevant component (such as a system popup) would be beneficial both for automated testing and dynamic analysis.
 
-// Futur work: mon unique pov pour le futur: what need to be done
+Integrating such a protocol into Android would open interesting perspectives.
+For instance, we could imagine Google requiring applications requesting critical permissions to provide test inputs with a high code coverage (maybe even 100% of coverage).
+Those test inputs can then be used to analyse the application dynamically.
 
-
-#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

@@ -11,13 +11,14 @@ This appendix lists the software we released as well as the different places the
 
 The code used in @sec:rasta is available at those locations:
 
-- The research team Gitlab: https://gitlab.inria.fr/pirat/android/rasta
-- The author's personal git: https://git.mineau.eu/these-android-re/rasta
-- Github: https://github.com/histausse/rasta
-- Zenodo: https://doi.org/10.5281/zenodo.10137904
+- https://gitlab.inria.fr/pirat/android/rasta
+- https://git.mineau.eu/these-android-re/rasta
+- https://github.com/histausse/rasta
+- https://doi.org/10.5281/zenodo.10137904
 
 The exact version of the code used in @sec:rasta is tagged as `icsr2024` in the git repositories and corresponds to the one stored in Zenodo.
-The results of our experiment are also available in the Zenodo archive.
+
+The results of our experiment and the list of applications in the dataset are also available in the Zenodo archive#footnote[https://doi.org/10.5281/zenodo.10137904].
 
 The container images used to run the different tools are available on Zenodo at https://doi.org/10.5281/zenodo.10980349 as Singularity images, and on Dockerhub under the names:
 
@@ -64,6 +65,4 @@ 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?
-]
+The dataset, results of the dynamic analysis and results of benchmark before and after the instrumentations with Theseus are available on Zenodo (link to appear)