30 lines
2.7 KiB
Typst
30 lines
2.7 KiB
Typst
#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.
|