Jean-Marie 'Histausse' Mineau
d1dba30426
Some checks failed
/ test_checkout (push) Failing after 20s
47 lines
3.4 KiB
Typst
47 lines
3.4 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[bien dédier des sections/sous section aux 3 problemes]
|
|
#todo[synthese a la fin de chaque section soa des problemes]
|
|
#todo[Problematique avant soa]
|
|
|
|
|
|
#todo[
|
|
plan:
|
|
|
|
- 2.1 intro
|
|
- 2.2 bases d'Android et RE (completer un peu pour souligner les besoins qui menes au pbs)
|
|
- 2.3 Problématiques du RE (reprendre l'intro avec ce qui a été dit dans 2.2)
|
|
apktool et androguard sont réutilisé, ca fait supposé qu'il y a peut être un peu de réutilisation
|
|
on peut charger des classes, et dans le code d'android, on vois qu'en fait le classes loading est beaucoup plus important que ca
|
|
c'est connus que cl + statique + ref = nono, tout les outils présentes leurs solutions d'une certaine facons
|
|
- 2.4 State of the Art
|
|
]
|