thesis/2_background/3_problem_statements.typ
Jean-Marie Mineau 471a176683
All checks were successful
/ test_checkout (push) Successful in 1m48s
keep refactoring
2025-09-24 17:19:23 +02:00

32 lines
2.4 KiB
Typst

#import "../lib.typ": pb1, pb1-text, pb2, pb2-text, pb3, pb3-text, ART
#import "../lib.typ": todo
== 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[
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
]