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

fix 'typos' (yesss, they are definitely typos)
All checks were successful
/ test_checkout (push) Successful in 1m49s
Details

Browse source
This commit is contained in:
Jean-Marie 'Histausse' Mineau 2025-09-26 04:21:05 +02:00
parent fede0bd9b2
commit 0d87fae9da
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
11 changed files with 302 additions and 304 deletions
Download patch file Download diff file Expand all files Collapse all files

35
2_background/1_intro.typ
View file

@ -3,31 +3,28 @@
== 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.
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 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.
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 analysis what is not inside the application.
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 relativelly unexplored.
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 fallback dynamic analysis.
Dynamic analysis is the counterpart of static analysis: the analysis is based on the analysis of the excecution of the application.
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 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.
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 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]
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 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 in @sec:bg-soa, and conclude this chapter in @sec:bg-conclusion.