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

keep refactoring
All checks were successful
/ test_checkout (push) Successful in 1m48s
Details

Browse source
This commit is contained in:
Jean-Marie Mineau 2025-09-24 17:19:23 +02:00
parent d1dba30426
commit 471a176683
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
16 changed files with 181 additions and 149 deletions
Download patch file Download diff file Expand all files Collapse all files

25
2_background/3_problem_statements.typ
View file

@ -1,8 +1,29 @@
#import "../lib.typ": pb1, pb1-text, pb2, pb2-text, pb3, pb3-text, ART
#import "../lib.typ": todo
== PB <sec:bg-probl>
== Problems of the Reverse Engineer <sec:bg-probl>
In this section, we will develop some issues encontered by reverse engineer, and link them to our problem statements.
In the previous section, we listed some limitations to static analysis.
Some limitations have been known for some time now, and many contributions have been made to been made to overcome them.
Those contribution often introduce new tools that implements solutions to those different issues.
Depending on the situation, a reverse engineer might want to use those tools, or build another tool on top of one.
Unfortunately, they can be hard to use.
And like we said previously, the fast evolution of Android can be a significant obstacle.
The combinaison of those two point can lead a reverse engineer to spend a lot of time trying to use a tool without realising that tools does not work anymore.
Our first problem statement #pb1 focuses on this issue: #pb1-text.
Determining which tools are still usable today is a first step, but finding out what reasons make a tool stop working might help writing more resilient tools in the futur.
We also presented dynamic code loading an obstacle for static analysis.
Code loading is achieved using class loader objects, causing class loaders to be generally associated with dynamic code loading.
However, class loading plays a much more important role in the #ART.
Class loading originate from the Java ecosystem, and was ported to Android so that developers could keep writting application in Java.
Despit that, Android made a lot of change to the original Java classes, and did not document those changes.
Between static analysis general oversight of class loading, relegating it to dynamic analysis, and the lake of documentation of the actual behaviour of the #ART, the question of the impact of the class loading algorithm on static analysis can be ask.
Our secon problem statement #pb2 tries to anwser this question: #pb2-text.
#todo[title for @sec:bg-probl]
#todo[
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