Jean-Marie 'Histausse' Mineau
10df431972
All checks were successful
/ test_checkout (push) Successful in 1m42s
58 lines
2.8 KiB
Typst
58 lines
2.8 KiB
Typst
#import "../lib.typ": todo, APK, DEX, JAR, OAT, SDK, eg, ART, jm-note, jfl-note
|
|
#import "@preview/diagraph:0.3.5": raw-render
|
|
|
|
== Overview <sec:th-overview>
|
|
|
|
Our objective is to make available some dynamic information to any analysis tool able to analyse an Android #APK.
|
|
To do so, we elected to follow the path of a few contributions we presented in @sec:bg, such as DroidRA~@li_droidra_2016, and use instrumentation.
|
|
Contrary to DroidRA, which uses static analysis to compute the values of strings and, from that, the methods used by reflection, we chose to use dynamic analysis.
|
|
This allows us to collect information that is simply not available statically (#eg a string sent from a remote command and control server).
|
|
The tradeoff being the lack of exhaustiveness: dynamic analysis is known to have code coverage issues.
|
|
|
|
#figure(
|
|
raw-render(
|
|
```
|
|
digraph {
|
|
rankdir=LR
|
|
|
|
splines="ortho"
|
|
|
|
|
|
APK [shape=parallelogram]
|
|
"Automated Runner"
|
|
"Reverse Engineer"
|
|
"Dynamic Analysis" [shape=box]
|
|
"Runtime Information" [shape=parallelogram]
|
|
Transformation [shape=box]
|
|
"APK'" [shape=parallelogram]
|
|
|
|
APK:c -> "Dynamic Analysis"
|
|
"Automated Runner" -> "Dynamic Analysis" [style="dashed"]
|
|
"Reverse Engineer" -> "Dynamic Analysis" [style="dashed"]
|
|
"Dynamic Analysis" -> "Runtime Information"
|
|
APK -> Transformation
|
|
"Runtime Information" -> Transformation
|
|
Transformation -> "APK'"
|
|
}
|
|
```,
|
|
width: 100%,
|
|
alt: (
|
|
"A diagram showing the process to transform an application.",
|
|
"Dotted arrows go from a \"Automated Runner\" and from \"Reverse Engineer\" to a box labeled \"Dynamic Analysis\", as well as plain arrow from \"APK\" to \"Dynamic Analysis\".",
|
|
"An arrow goes from \"Dynamic Analysis\" to \"Runtime Information\", then from \"Runtime Information\" to a box labeled \"Transformation\".",
|
|
"Another arrow goes from \"APK\" to \"Transformation\".",
|
|
"Finally, an arrow goes from \"Transformation\" to \"APK'\"."
|
|
).join(),
|
|
),
|
|
caption: [Process to add runtime information to an #APK],
|
|
) <fig:th-process>
|
|
|
|
@fig:th-process summarises our process.
|
|
We first take an application that we analyse dynamically.
|
|
To improve code coverage, either a reverse engineer or an automated runner will interact with the application.
|
|
During this analysis, we use Frida to capture dynamic information like the names of the methods called using reflection and bytecode loaded at runtime.
|
|
This analysis is described in @sec:th-dyn.
|
|
|
|
The data collected by this analysis is then combined with the application, transforming the application into another one that can then be analysed further.
|
|
We present the details of this transformation in @sec:th-trans.
|
|
Since the transformation drives the data we need to collect, we have decided to place this section first in this chapter.
|