wip

2_background/3_analysis_techniques.typ

@@ -0,0 +1,41 @@
+#import "../lib.typ": todo, APK
+
+== Android Reverse Engineering Techniques <sec:bg-techniques>
+
+#todo[swap with tool section ?]
+
+In the past fifteen years, the research community released many tools to detect or analyze malicious behaviors in applications.
+Two main approaches can be distinguished: static and dynamic analysis@Li2017.
+Dynamic analysis requires to run the application in a controlled environment to observe runtime values and/or interactions with the operating system.
+For example, an Android emulator with a patched kernel can capture these interactions but the modifications to apply are not a trivial task.
+Such approach is limited by the required time to execute a limited part of the application with no guarantee on the obtained code coverage.
+For malware, dynamic analysis is also limited by evading techniques that may prevent the execution of malicious parts of the code.
+//As a consequence, a lot of efforts have been put in static approaches, which is the focus of this paper.
+
+=== Static Analysis <sec:bg-static>
+
+Static analysis tools are used to perform operations on an #APK file, like extracting its bytecode or information from the `AndroidManifest.xml` file.
+
+#todo[Explain controle flow graph, data flow graph, and link to tools?]
+
+A classic goal of a static analysis is to compute data flows to detect potential information leaks@weiAmandroidPreciseGeneral2014 @titzeAppareciumRevealingData2015 @bosuCollusiveDataLeak2017 @klieberAndroidTaintFlow2014 @DBLPconfndssGordonKPGNR15 @octeauCompositeConstantPropagation2015 @liIccTADetectingInterComponent2015 by analyzing the bytecode of an Android application.
+
+Static analysis tools for Android application must overcom many difficulties:
+/ the multiplicity of entry points: Each component of an application can be an entry point for the application
+/ the event driven architecture: Methods of in the applications can be called in many different order depending on external events
+/ the interleaving of native code and bytecode: Native code can be called from bytecode and vice versa, but tools often only handle one of those format
+/ the potential dynamic code loading: And application can run code that was not orriginally in the application
+/ the use of reflection: Methods can be called from their name as a string object, which is not necessary known statically
+/ the continual evolution of Android: each new version brings new features that an analysis tools must be aware of
+
+The tools can share the backend used to interact with the bytecode. 
+For example, Apktool is often called in a subprocess to extracte the bytecode. 
+Another example is Soot@Arzt2013, a Java framework that allows to manipulate the bytecode from an object representation of instructions. 
+The most known tool built on top of Soot is FlowDroid@Arzt2014a, which enables to compute information flows statically into the code. 
+
+=== Dynamic Analysis <sec:bg-dynamic>
+
+#todo[y a du boulot]
+
+=== Hybrid Analysis <sec:bg-hybrid>
+