Jean-Marie 'Histausse' Mineau
c34eb1b838
Some checks failed
/ test_checkout (push) Failing after 1m45s
33 lines
2.8 KiB
Typst
33 lines
2.8 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 wich application are distributed, as well as the runtime environment that runs those application, are very specific to Android.
|
|
To handle those specificities, a reverse engineer must appropriate tools.
|
|
Some of those tools are used recurrently, either by the reverse engineer themself, or as basis for other more complexe tools that implement more advance analysis techniques.
|
|
|
|
Among those techniques, the ones that do not require to run the application are called static analysis.
|
|
Over the time, many of those tools have been released.
|
|
To compare those different tools, different benchmarks have been proposed, highlighting different strenght and weeknesses of each tools.
|
|
|
|
Unfortunately static analysis has its limits.
|
|
One such limit is that it cannot analysis 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 relativelly unexplored.
|
|
|
|
When static analysis fails, for instance because of dynamic class loading, the reverse engineer will fallback dynamic analysis.
|
|
Dynamic analysis is the counterpart of static analysis: the analysis is based on the analysis of the excecution 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 beeing that any Android analysis tools must be able to handle an Android application in the first place, so it will have access to those new information.
|
|
|
|
We will begin this chapter by a presentation of the bases of the Android ecosystem.
|
|
The reader already familliar with Android reverse engineering might want to skip to @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 @sec:bg-soa, and conclude this chapter in @sec:bg-conclusion.
|
|
|
|
#todo[synthese a la fin de chaque section soa des problemes]
|
|
#todo[Problematique avant soa]
|