rerefactor bg

2_background/1_intro.typ

@@ -0,0 +1,47 @@
+#import "../lib.typ": API, ie, todo
+
+== Introduction
+
+In order to understand the challenges of reverse engineering Android applications, we first need to understand some key concepts and specificities of Android.
+In particular, the format in wich application are distributed, as well as the runtime environment that runs those application, are very specific to Android.
+To handle those specificities, a reverse engineer must appropriate tools.
+Some of those tools are used recurrently, either by the reverse engineer themself, or as basis for other more complexe tools that implement more advance analysis techniques.
+
+Among those techniques, the ones that do not require to run the application are called static analysis.
+Over the time, many of those tools have been released.
+To compare those different tools, different benchmarks have been proposed, highlighting different strenght and weeknesses of each tools.
+
+Unfortunately static analysis has its limits.
+One such limit is that it cannot analysis what is not inside the application.
+Platform classes are classes that are present directly on the smartphone, and not in the application.
+Some of those classes are well known and taken into account by analysis tools, but the rest of those classes, often called _hidden #API;_, are not.
+In addition to platform classes, classes that are loaded dynamically (#ie at runtime) are also not always available to static analysis.
+This led static analysis tools to disregard the class loading process altogether, leaving the subject relativelly unexplored.
+
+When static analysis fails, for instance because of dynamic class loading, the reverse engineer will fallback dynamic analysis.
+Dynamic analysis is the counterpart of static analysis: the analysis is based on the analysis of the excecution of the application.
+Depending on the context, the reverse engineer will then alternate between different techniques, using previous results to improve the next iteration.
+Regrettably, analysis tools mostly return results in an ad hoc format, making it difficult to make other tools aware of the retrieved information.
+Some tools however encode their result in the form of a new augmented Android application.
+The idea beeing that any Android analysis tools must be able to handle an Android application in the first place, so it will have access to those new information.
+
+We will begin this chapter by a presentation of the bases of the Android ecosystem. 
+The reader already familliar with Android reverse engineering might want to skip to @sec:bg-probl where we put our problem statements in perspective.
+We will then examine the state of the art related to those problem statements @sec:bg-soa, and conclude this chapter in @sec:bg-conclusion.
+
+#todo[bien dédier des sections/sous section aux 3 problemes]
+#todo[synthese a la fin de chaque section soa des problemes]
+#todo[Problematique avant soa]
+
+
+#todo[
+  plan:
+
+  - 2.1 intro
+  - 2.2 bases d'Android et RE (completer un peu pour souligner les besoins qui menes au pbs)
+  - 2.3 Problématiques du RE (reprendre l'intro avec ce qui a été dit dans 2.2)
+          apktool et androguard sont réutilisé, ca fait supposé qu'il y a peut être un peu de réutilisation
+          on peut charger des classes, et dans le code d'android, on vois qu'en fait le classes loading est beaucoup plus important que ca
+          c'est connus que cl + statique + ref = nono, tout les outils présentes leurs solutions d'une certaine facons
+  - 2.4 State of the Art
+]