wip

2_background/1_intro.typ

@@ -26,5 +26,5 @@ Some tools, however, encode their result in the form of a new augmented Android
 The idea being that any Android analysis tools must be able to handle an Android application in the first place, so they will have access to that new information.
 
 We will begin this chapter with a presentation of the bases of the Android ecosystem. 
-The reader already familiar with Android reverse engineering might want to skip to @sec:bg-probl, where we put our problem statements in perspective.
+The reader already familiar with Android reverse engineering might want to skip @sec:bg-android-bg and directly read @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 in @sec:bg-soa, and conclude this chapter in @sec:bg-conclusion.

2_background/2_1_android.typ

@@ -24,7 +24,7 @@ Depending on the application and compilation process, any kind of other files an
 #paragraph[*Signature*][
 Android applications are cryptographically signed to prove the authorship.
 Applications signed with the same key are considered developed by the same entity.
-This allows updating the applications securely, and applications can declare security permissions to restrict access to some feature to only applications with the same author.
+This allows updating the applications securely, and applications can declare security permissions to restrict access to some features to only applications with the same author.
 
 Android has several signature schemes coexisting:
 - The v1 signature scheme is the #JAR signing scheme, where the signature data is stored in the `META-INF/` folder.
@@ -69,7 +69,7 @@ An additional file, `resources.arsc`, in a custom binary format, contains a list
 
 #paragraph[*Compilation Process*][
 For the developer, the compilation process is handled by Android Studio and is mostly transparent.
-Behind the scenes, Android Studio rely on Gradle to orchestrate the different compilation steps:
+Behind the scenes, Android Studio relies on Gradle to orchestrate the different compilation steps:
 
 The sources #XML files like `AndroidManifest.xml` and the one in `res/` are compiled to binary #AXML by `aapt`, which also generates the resource table `resources.arsc` and a `R.java` file that defines for each resource variables named after the resource, set to the ID of the resource. 
 The `R.java` file allows the developer to refer to resources with readable names and avoid using the often automatically generated resource IDs, which can change from one version of the application to another.
@@ -136,7 +136,7 @@ This component can then respond with another intent.
 Applications must declare intent filters to indicate which intent can be sent to the application, and which classes receive the intents.
 Intents are central to Android applications and are not just used to access Android capabilities.
 For instance, activities and services are started by receiving intents, and it is not uncommon for an application to self-send intents to switch between activities.
-Intent can also be sent directly from Android to the application: when a user starts an application by tapping the app icon, Android will send an intent to the class of the application that defined the intent filter for the `android.intent.action.MAIN` intent.
+Intents can also be sent directly from Android to the application: when a user starts an application by tapping the app icon, Android will send an intent to the class of the application that defined the intent filter for the `android.intent.action.MAIN` intent.
 One interesting feature of the Binder is that intents do not need to explicitly name the targeted application and class: intents can be implicit and request an action without knowing the exact application that will perform it.
 An example of this behaviour is when an application wants to open a file: an `android.intent.action.VIEW` intent is sent with the file location and type, and Binder will find and start an application capable of viewing this file.
 ]

2_background/2_2_tools.typ

@@ -9,7 +9,7 @@ Usually, the first step while analysing an application is to look at its content
 Apktool and Jadx are common tools used to convert the content of an application into a readable format.
 Analysing an application this way, without running it, is called static analysis.
 For more advanced forms of static analysis, Androguard and Soot can be used as libraries to automate analyses.
-When static analysis became too complicated (#eg if the application uses obfuscation techniques), a reverse engineer might switch to dynamic analysis.
+When static analysis becomes too complicated (#eg if the application uses obfuscation techniques), a reverse engineer might switch to dynamic analysis.
 This time, the application is executed, and the analyst will scrutinise the behaviour of the application.
 Frida is a good option to help with this dynamic analysis. 
 It is a toolkit that can be used to intercept method calls and execute custom scripts while an application is running.
@@ -20,8 +20,7 @@ In practice, Android Studio is a source-code editor that wraps around the differ
 The #SDK tools and packages can be installed manually with the `sdkmanager` tool.
 Among the notable tools in the #SDK are:
 
-- `emulator`: an Android emulator. 
+- `emulator`: this tool allows running an emulated Android phone on a computer.
-  This tool allows running an emulated Android phone on a computer.
   Although very useful, Android emulator has several limitations. 
   For once, it cannot emulate another architecture.
   An x86_64 computer cannot emulate an ARM smartphone.
@@ -45,17 +44,15 @@ Among the notable tools in the #SDK are:
 #paragraph[*Apktool*][
 Apktool#footnote[https://apktool.org/] is a _reengineering tool_ for Android #APK files.
 It can be used to disassemble an application: it will extract the files from the #APK file, convert the binary #AXML to text #XML, and use smali/backsmali#footnote[https://github.com/JesusFreke/smali] to convert the #DEX files to smali, an assembler-like language that matches the Dalvik bytecode instructions.
-The main strength of Apktool is that after disassembling an application, its content can be edited and reassembled into a new #APK. #jfl-note[limites? ca marche toujours?]
+The main strength of Apktool is that after disassembling an application, its content can be edited and reassembled into a new #APK. 
 ]
 
 #paragraph[*Androguard*][
 Androguard#footnote[https://github.com/androguard/androguard]~@desnos:adnroguard:2011 is a Python library for parsing and disassembling #APK files.
 It can be used to automatically read Android manifests, resources, and bytecode.
 Contrary to Apktool, which generates text files, it can be used as a library to programmatically analyse the application.
+It can also perform additional analysis, like computing a call graph or control flow graph of the application (we will explain what those graphs are later in @sec:bg-static).
 However, contrary to Apktool, it cannot repackage a modified application.
-
-It can also perform additional analysis, like computing a call graph or control flow graph of the application. 
-We will explain what those graphs are later in @sec:bg-static.
 ]
 
 #paragraph[*Jadx*][

2_background/2_3_static_analysis.typ

@@ -20,7 +20,6 @@ A more advanced control-flow analysis consists of building the control-flow grap
 This time, instead of methods, the nodes represent instructions, and the edges indicate which instruction can follow which instruction.
 @fig:bg-fizzbuzz-cg-cfg c) represents the control-flow graph of @fig:bg-fizzbuzz-cg-cfg a), with code statements instead of bytecode instructions.
 
-#todo[Add alt text for @fig:bg-fizzbuzz-cg and @fig:bg-fizzbuzz-cfg]
 
 #figure({
   set align(center)
@@ -57,7 +56,7 @@ This time, instead of methods, the nodes represent instructions, and the edges i
       }
       ```,
       width: 40%,
-      alt: "",
+      alt: "An oriented graph with arrows going from \"fizzBuzz(int)\" to \"Buzzer.fizzBuzz()\", \"Buzzer.fizz()\", \"String.valueOf(int)\", and \"Log.e(String, String)\"",
     ),
     supplement: none,
     kind: "bg-fizzbuzz-cg-cfg subfig",
@@ -99,7 +98,16 @@ This time, instead of methods, the nodes represent instructions, and the edges i
         "l9": `Log.e("fizzbuzz", String.valueOf(i));`,
       ),
       width: 50%,
-      alt: "",
+      alt: (
+        "An oriented graph. ",
+        "The node at the top is labelled `for (int i = 1; i <= n; i++) {`. Arrows go from it to the node below, labelled `if (i % 3 == 0 && i % 5 == 0) {`. ",
+        "Two arrows start from this node, one to `Buzzer.fizzBuzz();`, one to `} else if (i % 3 == 0) {`. ",
+        "An arrow goes from `Buzzer.fizzBuzz();` to the `for` node at the top. ",
+        "Two arrows go from the `else if i % 5 = 0` node, one to `} else if (i % 5 == 0) {` and one to `Buzzer.fizz();`. ",
+        "An arrow goes from `Buzzer.fizz();` to the `for` node at the top. ",
+        "Two arrows go from the `else if i % 5 = 0`, one to `Buzzer.buzz();`, and one to `Log.e(\"fizzbuzz\", String.valueOf(i));`. ",
+        "Arrows go from both those nodes, back to the `for` node at the top."
+      ).join(),
     ),
     supplement: none,
     kind: "bg-fizzbuzz-cg-cfg subfig",

2_background/3_problem_statements.typ

@@ -30,7 +30,7 @@ In a way, reflection can do the same thing, but for specific method calls: inste
 By contrast, it is relatively easy to find the name of the method called or to intercept dynamically loaded bytecode using dynamic tools like Frida.
 The issue that arises then is what to do with the collected data.
 Simply having it greatly helps a manual analysis, but it cannot be used directly by tools that perform static analyses.
-There is no standard representation for runtime information, and there is simply no way to give a list of reflection sites and the associated method calls for most tools.
+There is no standard representation for runtime information, and there is simply no way to give a list of reflection sites and the associated method calls as a new input for most static analysis tools.
 This means that in most cases, when a reverse engineer wants to improve static analysis with dynamic analysis, they need to modify the static tools to receive the additional runtime data.
 Doing so requires both time and knowledge of the internals of the tools used.
 Our third problem statement, #pb3, explores an alternative approach that modifies the application instead of the tool: #pb3-text

2_background/4_1_rasta.typ

@@ -14,7 +14,7 @@ They analysed 92 publications and classified them by goal, method used to solve
 In particular, they listed 27 approaches with an open-source implementation available.
 
 Interestingly, a lot of the tools listed rely on common tools to interact with Android applications/#DEX bytecode.
-Reccuring examples of such support tools are Appktool (#eg Amandroid~@weiAmandroidPreciseGeneral2014, Blueseal~@shenInformationFlowsPermission2014, SAAF~@hoffmannSlicingDroidsProgram2013), Androguard (#eg Adagio~@gasconStructuralDetectionAndroid2013, Appareciumn~@titzeAppareciumRevealingData2015, Mallodroid~@fahlWhyEveMallory2012) or Soot (#eg Blueseal~@shenInformationFlowsPermission2014, DroidSafe~@DBLPconfndssGordonKPGNR15, Flowdroid~@Arzt2014a).
+Reccuring examples of such support tools are Apktool (#eg Amandroid~@weiAmandroidPreciseGeneral2014, Blueseal~@shenInformationFlowsPermission2014, SAAF~@hoffmannSlicingDroidsProgram2013), Androguard (#eg Adagio~@gasconStructuralDetectionAndroid2013, Appareciumn~@titzeAppareciumRevealingData2015, Mallodroid~@fahlWhyEveMallory2012) or Soot (#eg Blueseal~@shenInformationFlowsPermission2014, DroidSafe~@DBLPconfndssGordonKPGNR15, Flowdroid~@Arzt2014a).
 This strengthens our idea that being able to reuse previous tools is important.
 Those tools are built incrementally, on top of each other.