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

finished, maybe, yes?
All checks were successful
/ test_checkout (push) Successful in 1m43s
Details

Browse source
This commit is contained in:
Jean-Marie 'Histausse' Mineau 2025-10-03 04:36:10 +02:00
parent 63f34abca6
commit 6a43784496
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
3 changed files with 38 additions and 22 deletions
Download patch file Download diff file Expand all files Collapse all files

27
6_conclusion/2_futur.typ
View file

@ -1,14 +1,10 @@
#import "../lib.typ": todo, AOSP
#import "../lib.typ": todo, AOSP, eg
== Perspectives for Future Work
#todo[
Intro
In this section, we will discuss avenues of work raised by this thesis ?
The work presented in this thesis revealed avenues to improve ??. The following section will present those new avenues.
]
In this section, we present what, in light of this thesis, we believe to be worthwhile avenues of work to improve the Android reverse engineering ecosystem.
The main issue that appeared in all our work is an engineering one.
The main issue that appeared in all our work appears to be engineering one.
The error we analysed in @sec:rasta showed that even something that should be basic, reading the content of an application, can be challenging.
@sec:cl also showed that reproducing the exact behaviour of Android is more difficult than it seems.
As long as those issues are not solved, we cannot build robust analysis tools.
@ -19,16 +15,15 @@ Dynamic analysis relying on patched versions of the #AOSP showed that it is diff
Doing this would require limiting the modifications to the actual source code of Android to lower the changes needed at each update of Android.
Another obstacle to overcome is to decouple the compilation of the tool from the rest of #AOSP: it is a massive dependence that needs a lot of resources to build.
Having such a dependency would be a barrier to entry, preventing others from modifying or improving the tool.
Should those issues be solved, directly using the code from #AOSP would allow such a tool to keep up with each new version of Android and limit invalid assumptions about Android behaviour.
#todo[
Ideas:
- Standard Lib to interact with dalvik (dev by google?), with *STABLE* API and *ROBUST*: Today there is Apktool, Soot and Androguard
Apktool don't have a documented API, and by default do a lot of things that might work or not
Soot defaults are baaaadddd, maybe the new version?
Androguard is not bad, but not write capabilities (yet, it's a wip, maybe one day?)
Robust default, close to Android: the java zip parser is often targeted, there is something to be done here
]
An orthogonal solution to this problem is to create a new benchmark.
Benchmarks are usually targeted at some specific technique (#eg taint tracking), and accordingly, test for issues specific to the targeted technique (#eg accurately tracking data that passes through an array).
This one should test the capacity of a tool to handle real-life applications.
We suggest using a similar method to what we did in @sec:rasta to keep the benchmark independent from the tested tools.
Instead of checking the correctness of the tools, this benchmark should test if the tool is able to finish its analysis.
Applications in this benchmark could either be real-life applications that proved difficult to analyse (for instance, applications that crashed many of the tested tools in @sec:rasta), or hand-crafted applications reproducing corner cases or anti-reverse techniques encountered while analysing obfuscated applications (for instance, an application with gibberish binary file names inside `META-INF/` that can crash Jadx zip reader).
The main challenge with such a benchmark is that it would need frequent updates to follow Android evolutions, and be diverse enough to encompass a large spectrum of possible issues.
#todo[web-base? flutter? wasm?]