these-ammii/thesis
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

finish bg section
All checks were successful
/ test_checkout (push) Successful in 1m26s
Details

Browse source
This commit is contained in:
Jean-Marie Mineau 2025-08-27 00:35:07 +02:00
parent 19286eba61
commit eb35d092ac
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
10 changed files with 170 additions and 43 deletions
Download patch file Download diff file Expand all files Collapse all files

29
2_background/0_intro.typ
View file

@ -1,3 +1,28 @@
#import "../lib.typ": todo
#import "../lib.typ": API, ie, todo
#todo[Intro: on parle de reverse des app, donc on parle des apps, techniques de reverse, outils, dataset, et justifier de pourquoi on en parle]
== 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.
In this section, explore in more details those different aspects of Android reverse engineering.