This commit is contained in:
parent
8b5885ae55
commit
cc4ecf28fe
9 changed files with 92 additions and 69 deletions
58
5_theseus/2_overview.typ
Normal file
58
5_theseus/2_overview.typ
Normal file
|
@ -0,0 +1,58 @@
|
|||
#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 objectif 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 use static analysis to compute the values of string and from that the methods used by reflection, we chose to dynamic analysis.
|
||||
This allows us to collect informations that are simply not available statically (#eg a string send from a remote command and control server).
|
||||
The tradeoff beeing 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 summarize our process.
|
||||
We first take an application that we analyse dynamically.
|
||||
To improve code coverage, either an reverse engineer or an automated runner will interact with the application.
|
||||
During this analysis, we use Frida to capture dynamic informations like the name of the methods called using reflection and bytecode loaded at runtime.
|
||||
This analysis described in @sec:th-dyn.
|
||||
|
||||
The data collected by this analysis is then combined to application, transforming the application into another one that can then be analyzed 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.
|
Loading…
Add table
Add a link
Reference in a new issue