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

wip, again and again
Some checks failed
/ test_checkout (push) Failing after 1m45s
Details

Browse source
This commit is contained in:
Jean-Marie 'Histausse' Mineau 2025-09-25 03:27:04 +02:00
parent 471a176683
commit c34eb1b838
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
7 changed files with 43 additions and 61 deletions
Download patch file Download diff file Expand all files Collapse all files

22
2_background/3_problem_statements.typ
View file

@ -12,7 +12,7 @@ Depending on the situation, a reverse engineer might want to use those tools, or
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.
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.
@ -21,12 +21,18 @@ 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.
Our second problem statement #pb2 aims to anwser this question: #pb2-text
Circling back to known limitations of static analysis, dynamic code loading and reflection are often used to obfuscate applications.
Dynamic code loading allows to hide bytecode from static analysis with relativelly low effort.
The bytecode can downloaded at runtime, stored in the application encrypted, hidden inside other files, generated at runtime, etc.
In a way, reflection allows to do the same thing, but for specific method calls: instead of the actual call, static analysis will see a call to the generic `Method.invoke()` method.
By contrast, it is relatively easy to find those the name of the method called or to intercept dynamically loaded bytecode using dynamic tools like Frida.
The issue that arrise then is what to do with the collected data.
Simply having it greatly helps a manual analysis, but it cannot be used directly by tools that perform static analyses.
There is no standard representation for runtime information, and there is simply no way to give a list of reflection sites and the associated method calls for most tools.
This means that in most cases, when a reverse engineer wants to improve static analysis with dynamic analysis, they need to modify the static tools to receive the additionnal runtime data.
Doing so requires both time and knowledge of the internals of the tools used.
Our third problem statement, #pb3, explore an alternative aproach that modify the application instead of the tool: #pb3-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
]
We will now explore the current state of the art for relevent contributions related to our problem statements.