intro

1_introduction/main.typ

@@ -1,4 +1,4 @@
-#import "../lib.typ": todo, epigraph, eg, APK, jm-note
+#import "../lib.typ": todo, epigraph, eg, APK, API, highlight, jm-note,
 
 = Introduction <sec:intro>
 
@@ -19,31 +19,78 @@ For example, an applications cannot access the contact list without requesting t
 Android keep improving its security version from version, be it by improving the sandboxing (#eg starting with Android 10, application can no longer access the clipboard if they are not focused) or safer default (#eg since Android 9, by default, all network connection must use TLS).
 // Android Bouncer, ca marche pas tres bien quand même ect ect (stralker ware?)
 
+In the spirit of _defence in depth_, Google develloped a _Bouncer_ service that scan applications in the store for malicious software#footnote[https://googlemobile.blogspot.com/2012/02/android-and-security.html].
+Although its operating is kept secret, it seems that the Bouncer is both comparing the applications with known malware code and running the applications in Google's cloud infrastructure to detect hidden behavior.
+Despite Google's efforts, malicious applications are still found in the Play Store~@adjibi_devil_2022.
+Also, it is not uncommmon for people in abusive situation to have their abuser install on their phone a stalkerware (spying application) found outside of the Play Store~@stateofstalkerware.
 
-/*
-*
-*
-*
-* Android securité explique a ma grand-mere
-* expliquer gentillement, montrer tout les angles de la securité: renforcer l'OS, detecter les malware, reverse
-*
-* c'est quoi le reverse?
-* arriver sur le probleme que les cas qui marchent pas sont souvant ignoré (chiffrer, tableau?) et fait a la main dans les cas
-* cause, pourquoi?
-* est ce qu'on peut essayer de reparer?
-*
-*
-* plan: chapitre, résumé un peu long des chapitres.
-*/
-#todo[developper "De tout temps les hommes "]
+For this reasons, it is important to be able to analyse an application and understand was it does.
+This process is called reverse engineering.
+A lot of work has been done to reverse engineering computer software, but Android applications come with specific challenges that need to be address.
+For instance, Android application have a distributed in a specific file format, the #APK format, and the code of the application is mainly compile into an Android specific bytecode: Dalvik.
+An Android reverse engineer will need tools that can read those Android specific formats.
+A first test in the process of reverse engineering an application would be to simply read the content of the application and the code in it.
+Tools like apktool can be used to convert the binary files of an application in a human readable format.
+Other tools like Jadx can go farther and try to generate Java code from the bytecode in the application.
+Because Android applications tend to be massive, it can be quite tedious to understand what it doest juste from reading its bytecode.
+To help, many tools/approches have been developed~@Li2017 @sutter_dynamic_2024.
+For example, Flowdroid~@Arzt2014a aims to detect information leak: given a set of methods that can generate private information, and a set of methods that send information to the outside, Flowdroid will detect if private information is send to the outside.
+Once again, those kind of tools need to target Android specifically.
+Android run its applications code differently very than a computer would run software.
+One example would be entry points: computer software usually have one starting point, when Android applications have many, that Android will chose depending on the situation.
+Unfortunately, those tools are hard to use, and even when the work on small example application, it is not uncommon for them to fail to run on real-live applications~@reaves_droid_2016.
+This is worrying.
+Android applications are becoming more complexe every years and tools that cannot handle this complexity only fail more often.
+This leads us to our first problem statement:
+// Chiffrer les contrib avec des xp qui ignore les app qui font crasher les outils?
 
-#todo[Introduire problématique:]
+#highlight(breakable: false)[
+  *Pb 1*: _To what extent are previously published Android analysis tools still usable today, and what factors impact their reusability?_
+  
+  Many tools have been published to analyse Android applications, but the Android ecosystem is fast evolving.
+  Tools developed 5 years ago might not be usable anymore.
+  We will endeavor to identify which tools are still usable today, and for the others, what causes them to no longer be an option.
+]
 
-#todo[1) résulats trop bons sur des datasets faciles]
+Another issue is that Android application developpers sometime use various techniques to slow down reverse engineering.
+This process called obfuscation.
+Malware developpers do that to hide malicious behavior and avoid detection, but the use of obfuscation is not a proof that and application is malicious.
+Indeed, legitimate applications developpers can also use obfuscation to protect their intellectual property. // burrkkk
+Thus, developpers and reverse engineers are playing a game of cats and mouse, constantly inventing new technique to hide or reveal the behavior of an application.
 
-#todo[2) facile a pieger: shadow attacks]
+They are two types of reverse engineering: static and dynamic.
+Static analysis consists of examining the application without running it, while dynamic analysis studdy the action of the application durring its run.
+Both methods have their drawbacks, and techniques will often capitalyse on the drawbacks of one of those methods.
+For instance, an application can try to detect if it is running in a sandbox environment and not act maliciously if it is the case.
+Similarly, an application can dynamicaly load bytecode at runtime, and this bytecode will not be available during a static analysis.
+Dynamic code loading rely on Java classes called `ClassLoader` that are central components of the Android runtime environment.
+Because dynamic code loading is such a difficult probleme for static analysis, dynamic class loading is often ignore when doing static analysis.
+However, class loading is not limited to dynamic code loading. 
+In fact, the Android Runtime is constantly performing class loading to load classes from the application of from the Android platform itself.
+This blind spot in static analysis tools raises our second problem statement:
 
-#todo[3) savent pas gerer le chargement dyn et reflection]
+#highlight(breakable: false)[
+  *Pb 2*: _What is the default Android class loading algorithm, and does it impact static analysis?_
+
+  Class loading is an operation often ignored in static analysis.
+  The exact algorithm used is not well known and might not be accurately modeled by static analysis tools.
+  If it is the case, discrepancies between the model of the tools and the one used by Android could be used as a base for new obfuscation techniques.
+]
+
+Reflection is another common obfuscation technique against static analysis.
+Instead of directly invoking methods, the generic `Method.invoke()` #API is used, and the method is retrieved from its name in the form of a character string.
+Finding the value of this string can be quite difficult to determine statically, so it is once again an issue more suitable for dynamic analysis.
+A reverse engineer can obtain the relevant information with dynamic analysing, but there is no standard way to make static analysis tools aware of it.
+This lead us to our last problem statement:
+
+#highlight(breakable: false)[
+  *Pb 3*: _Can we provide dynamic code loading and reflection data collected dynamically to any static analysis tools to improve their results?_
+
+  Dynamic code loading and reflection are problems most suited for dynamic analysis.
+  However, static analysis tools do not have access to collected data.
+  Encoding this information inside valid applications could be a way to make it universally available to any static analysis tool.
+  #todo[say something about the impact that can have on tools?]
+]
 
 #[
 #set heading(numbering: none, outlined: false, bookmarked: false)

2_background/3_analysis_techniques.typ

@@ -164,10 +164,7 @@ GroddDroid~@abraham_grodddroid_2015 has the same approach but detect statically
 Unfortuntely, exploring the application entirely is not always possible, as some applications will try to detect is they are in a sandbox environnement (#eg if they are in an emmulator, or if Frida is present in memory) and will refuse to run some sections of code if this is the case.
 Ruggia #etal~@ruggia_unmasking_2024 make a list of evasion techniques.
 They propose a new sandbox, DroidDungeon, that contrary to other sandboxes like DroidScope@droidscope180237 or CopperDroid@Tam2015, strongly emphasizes on resiliance against evasion mechanism.
+
 #todo[RealDroid sandbox bases on modified ART?]
 #todo[force execution?]
-
-=== Hybrid Analysis <sec:bg-hybrid>
-#todo[merge with other section?]
-
-- #todo[DyDroid, audit of Dynamic Code Loading~@qu_dydroid_2017]
+#todo[DyDroid, audit of Dynamic Code Loading~@qu_dydroid_2017]

bibliography.bib

@@ -29,8 +29,14 @@
 	keywords = {Android, static analysis, class loading, code obfuscation}
 }
 
-
-
+@conference{stateofstalkerware,
+	author = {Eva Galperin},
+	title = {The State of the Stalkerware},
+	year = {2020},
+	address = {San Francisco, CA},
+	publisher = {USENIX Association},
+	month = jan
+}
 
 @inproceedings{weiAmandroidPreciseGeneral2014,
 	title = {Amandroid: {{A Precise}} and {{General Inter-component Data Flow Analysis Framework}} for {{Security Vetting}} of {{Android Apps}}},