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

rasta

Browse source
This commit is contained in:
Jean-Marie Mineau 2025-08-17 00:10:58 +02:00
parent fe6dbb1d22
commit e794c037e8
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
10 changed files with 377 additions and 52 deletions
Download patch file Download diff file Expand all files Collapse all files

20
1_introduction/main.typ
View file

@ -1,4 +1,4 @@
#import "../lib.typ": todo, epigraph, eg, APK, API, highlight, jm-note,
#import "../lib.typ": todo, epigraph, eg, APK, API, highlight-block, jm-note,
= Introduction <sec:intro>
@ -44,13 +44,13 @@ Android applications are becoming more complexe every years and tools that canno
This leads us to our first problem statement:
// Chiffrer les contrib avec des xp qui ignore les app qui font crasher les outils?
#highlight(breakable: false)[
*Pb 1*: _To what extent are previously published Android analysis tools still usable today, and what factors impact their reusability?_
#highlight-block(breakable: false)[
*Pb1*: _To what extent are previously published Android analysis tools still usable today, and what factors impact their reusability?_
Many tools have been published to analyse Android applications, but the Android ecosystem is fast evolving.
Tools developed 5 years ago might not be usable anymore.
We will endeavor to identify which tools are still usable today, and for the others, what causes them to no longer be an option.
]
] <pb-1>
Another issue is that Android application developpers sometime use various techniques to slow down reverse engineering.
This process called obfuscation.
@ -69,13 +69,13 @@ However, class loading is not limited to dynamic code loading.
In fact, the Android Runtime is constantly performing class loading to load classes from the application of from the Android platform itself.
This blind spot in static analysis tools raises our second problem statement:
#highlight(breakable: false)[
*Pb 2*: _What is the default Android class loading algorithm, and does it impact static analysis?_
#highlight-block(breakable: false)[
*Pb2*: _What is the default Android class loading algorithm, and does it impact static analysis?_
Class loading is an operation often ignored in static analysis.
The exact algorithm used is not well known and might not be accurately modeled by static analysis tools.
If it is the case, discrepancies between the model of the tools and the one used by Android could be used as a base for new obfuscation techniques.
]
] <pb-2>
Reflection is another common obfuscation technique against static analysis.
Instead of directly invoking methods, the generic `Method.invoke()` #API is used, and the method is retrieved from its name in the form of a character string.
@ -83,14 +83,14 @@ Finding the value of this string can be quite difficult to determine statically,
A reverse engineer can obtain the relevant information with dynamic analysing, but there is no standard way to make static analysis tools aware of it.
This lead us to our last problem statement:
#highlight(breakable: false)[
*Pb 3*: _Can we provide dynamic code loading and reflection data collected dynamically to any static analysis tools to improve their results?_
#highlight-block(breakable: false)[
*Pb3*: _Can we provide dynamic code loading and reflection data collected dynamically to any static analysis tools to improve their results?_
Dynamic code loading and reflection are problems most suited for dynamic analysis.
However, static analysis tools do not have access to collected data.
Encoding this information inside valid applications could be a way to make it universally available to any static analysis tool.
#todo[say something about the impact that can have on tools?]
]
] <pb-3>
#[
#set heading(numbering: none, outlined: false, bookmarked: false)