#import "../lib.typ": API, ie, todo

== Introduction

In order to understand the challenges of reverse engineering Android applications, we first need to understand some key concepts and specificities of Android.
In particular, the format in which applications are distributed, as well as the runtime environment that runs those applications, is very specific to Android.
To handle those specificities, a reverse engineer must have appropriate tools.
Some of those tools are used recurrently, either by the reverse engineer themself, or as a basis for other more complex tools that implement more advanced analysis techniques.

Among those techniques, the ones that do not require running the application are called static analysis.
Over time, many of those tools have been released.
To compare those different tools, different benchmarks have been proposed, highlighting different strengths and weaknesses of each tool.

Unfortunately, static analysis has its limits.
One such limit is that it cannot analyse what is not inside the application.
Platform classes are classes that are present directly on the smartphone, and not in the application.
Some of those classes are well known and taken into account by analysis tools, but the rest of those classes, often called _hidden #API;_, are not.
In addition to platform classes, classes that are loaded dynamically (#ie at runtime) are also not always available to static analysis.
This led static analysis tools to disregard the class loading process altogether, leaving the subject relatively unexplored.

When static analysis fails, for instance, because of dynamic class loading, the reverse engineer will fall back on dynamic analysis.
Dynamic analysis is the counterpart of static analysis: it is based on the analysis of the execution of the application.
Depending on the context, the reverse engineer will then alternate between different techniques, using previous results to improve the next iteration.
Regrettably, analysis tools mostly return results in an ad hoc format, making it difficult to make other tools aware of the retrieved information.
Some tools, however, encode their result in the form of a new augmented Android application.
The idea being that any Android analysis tools must be able to handle an Android application in the first place, so they will have access to that new information.

We will begin this chapter with a presentation of the bases of the Android ecosystem. 
The reader already familiar with Android reverse engineering might want to skip @sec:bg-android-bg and directly read @sec:bg-probl, where we put our problem statements in perspective.
We will then examine the state of the art related to those problem statements in @sec:bg-soa, and conclude this chapter in @sec:bg-conclusion.
