these-android-re/thesis
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

fix 'typos' (yesss, they are definitely typos)
All checks were successful
/ test_checkout (push) Successful in 1m49s
Details

Browse source
This commit is contained in:
Jean-Marie 'Histausse' Mineau 2025-09-26 04:21:05 +02:00
parent fede0bd9b2
commit 0d87fae9da
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
11 changed files with 302 additions and 304 deletions
Download patch file Download diff file Expand all files Collapse all files

38
2_background/2_3_static_analysis.typ
View file

@ -4,21 +4,21 @@
=== Static Analysis <sec:bg-static>
Static analysis program examine an #APK file without executing it to extract information from it.
A static analysis program examines an #APK file without executing it to extract information from it.
Basic static analysis can include extracting information from the `AndroidManifest.xml` file or decompiling bytecode to Java code with tools like Apktool or Jadx.
Unfortunately, simply reading the bytecode does not scale.
To do so, a human analyst is needed, making it complicated to analyse a large number of applications, and even for single applications, the size and complexity of some applications can quickly overwhelm the reverse engineer.
Control flow analysis is often used to mitigate this issue.
The idea is to extract the behaviour, the flow, of the application from the bytecode, and to represent it as a graph.
A graph representation is easier to work with than a list of instructions, and can be used for further analysis.
A graph representation is easier to work with than a list of instructions and can be used for further analysis.
Depending on the level of precision required, different types of graphs can be computed.
The most basic of those graph is the 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.
The most basic of those graphs is the call graph.
A call graph is a graph where the nodes represent the methods in the application, and the edges represent 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.
A more advanced control-flow analysis consists of building the control-flow graph.
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.
@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]
@ -111,26 +111,26 @@ This time, instead of methods, the nodes represent instructions, and the edges i
)<fig:bg-fizzbuzz-cg-cfg>
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 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.
Data-flow analysis, also called taint-tracking, is used to follow the flow of information in the application.
By defining a list of methods and fields that can generate critical information (taint sources) and a list of methods that can consume information (taint sinks), taint-tracking detects potential data leaks (if a data flow links a taint source and a taint sink).
For example, `TelephonyManager.getImei()` returns a unique, persistent, device identifier.
This can be used to identify the user, and it cannot be changed if compromised.
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.
This makes `TelephonyManager.getImei()` a good candidate as a taint source.
On the other hand, `UrlRequest.start()` sends 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 critical information to an external entity, a behaviour that is probably not wanted by the user.
Static analysis is powerful 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.
Static analysis is powerful as it can detect unwanted behaviour in an application, even if the behaviour does not manifest itself when running the application.
However, static analysis tools must overcome 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 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 event-driven architecture: Methods in the applications can be called when events occur, in an 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 formats.
/ 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.
/ the continual evolution of Android: each new version of Android brings new features that analysis tools must be aware of.
For instance, the multi-dex feature presented in @sec:bg-android-apk 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.
Tools unaware of this feature only analyse the `classes.dex` file and will ignore all other `classes<n>.dex` files.
#todo[Ca serait bien de souligner Dyn Code Load et Reflection]