#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 same approach as a few contributions we presented in @sec:bg, such as DroidRA~@li_droidra_2016, and use instrumentation.
As a reminder, DroidRA is a tool that uses COAL to compute reflection data statically, then instruments the application to directly call the methods.
Contrary to DroidRA, 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 here is 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.