41 lines
2.9 KiB
Typst
41 lines
2.9 KiB
Typst
#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>
|
|
|