This commit is contained in:
parent
f5145237ce
commit
2e52599a7c
7 changed files with 92 additions and 71 deletions
|
@ -3,7 +3,7 @@
|
|||
|
||||
== Android Reverse Engineering Techniques <sec:bg-techniques>
|
||||
|
||||
#todo[swap with tool section ?]
|
||||
//#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.
|
||||
|
@ -24,8 +24,8 @@ The most basic form of control-flow analysis is to build a call graph.
|
|||
A call graph is a graph where the nodes represent the methods in the application, and the edges reprensent calls from one method to another.
|
||||
@fig:bg-fizzbuzz-cg-cfg b) show the call graph of the code in @fig:bg-fizzbuzz-cg-cfg a).
|
||||
A more advance control-flow analysis consist in building the control-flow graph.
|
||||
This times instead of methods, the nodes represent instructions, and the edges indicate which instruction can follow which instruction.
|
||||
@fig:bg-fizzbuzz-cg-cfg c) represent the control-flow graph of @fig:bg-fizzbuzz-cg-cfg a), with code statement instead of bytecode instructions.
|
||||
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 statement instead of bytecode instructions.
|
||||
|
||||
#figure({
|
||||
set align(center)
|
||||
|
@ -115,29 +115,31 @@ This times instead of methods, the nodes represent instructions, and the edges i
|
|||
|
||||
Once the control-flow graph is computed, it can be used to compute data-flows.
|
||||
Data-flow analysis, also called taint-tracking, allows to follow the flow of information in the application.
|
||||
Be defining a list of methods and fields that can generate critical information (taint sources) and a list of method that can consume information (taint sink), taint-tracking allows to detect potential data leak (if a data flow link a taint source and a taint sink).
|
||||
For example, `TelephonyManager.getImei()` is return an unique, persistent, device identifier.
|
||||
This can be used to identify the user can cannot be changed if compromised.
|
||||
Be defining a list of methods and fields that can generate critical information (taint sources) and a list of methods that can consume information (taint sink), taint-tracking allows to detect potential data leaks (if a data flow link a taint source and a taint sink).
|
||||
For example, `TelephonyManager.getImei()` returns an unique, persistent, device identifier.
|
||||
This can be used to identify the user, and it cannot be changed if #jfl-note[compromised][replace by: this imei is dislaxd (illisible) \ jm: ???].
|
||||
This make `TelephonyManager.getImei()` a good candidate as a taint source.
|
||||
On the other hand, `UrlRequest.start()` send a request to an external server, making it a taint sink.
|
||||
If a data-flow is found linking `TelephonyManager.getImei()` to `UrlRequest.start()`, this means the application is potentially leaking a critical information to an external entity, a behavior that is probably not wanted by the user.
|
||||
Data-flow analysis is the subject of many contribution~@weiAmandroidPreciseGeneral2014 @titzeAppareciumRevealingData2015 @bosuCollusiveDataLeak2017 @klieberAndroidTaintFlow2014 @DBLPconfndssGordonKPGNR15 @octeauCompositeConstantPropagation2015 @liIccTADetectingInterComponent2015, the most notable source being Flowdroid~@Arzt2014a.
|
||||
Data-flow analysis is the subject of many contribution~@weiAmandroidPreciseGeneral2014 @titzeAppareciumRevealingData2015 @bosuCollusiveDataLeak2017 @klieberAndroidTaintFlow2014 @DBLPconfndssGordonKPGNR15 @octeauCompositeConstantPropagation2015 @liIccTADetectingInterComponent2015, the most notable tool being Flowdroid~@Arzt2014a.
|
||||
|
||||
#todo[Describe the different contributions in relations to the issues they tackle]
|
||||
|
||||
Static analysis is powerfull as it allows to detects unwanted behavior in an application even is the behavior does not manifest itself when running the application.
|
||||
Hovewer, static analysis tools must overcom many challenges when analysing Android applications:
|
||||
/ the Java object-oriented paradigm: A call to a method can in fact correspond to a call to any method overriding the original method in subclasses
|
||||
/ 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 Java object-oriented paradigm: A call to a method can in fact correspond to a call to any method overriding the original method in subclasses.
|
||||
/ 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 when event occur, in unknown order.
|
||||
/ 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: An application can run code that was not originally in the application.
|
||||
/ the use of reflection: Methods can be called from their name as a string object, which is difficult to identify statically.
|
||||
/ the continual evolution of Android: each new version of Android brings new features that an analysis tools must be aware of.
|
||||
For instance, the multi-dex feature presented in @sec:bg-android-code-format was introduced in Android #SDK 21.
|
||||
Tools unaware of this feature only analyse the `classes.dex` file an will ignore all other `classes<n>.dex` files.
|
||||
|
||||
The tools can share the backend used to interact with the bytecode.
|
||||
#jfl-note[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, and the Soot framework is a commonly used both to analyse bytecode and modify it.
|
||||
The most notable user of Soot is Flowdroid. #todo[formulation]
|
||||
The most notable user of Soot is Flowdroid. #todo[formulation]][mettre ca a avant]
|
||||
|
||||
=== Dynamic Analysis <sec:bg-dynamic>
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue