Jean-Marie 'Histausse' Mineau
6a43784496
All checks were successful
/ test_checkout (push) Successful in 1m43s
36 lines
3 KiB
Typst
36 lines
3 KiB
Typst
#import "../lib.typ": todo, AOSP, eg
|
|
|
|
== Perspectives for Future Work
|
|
|
|
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 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.
|
|
One avenue we believe should be investigated would be to reuse the code actually used by Android.
|
|
This is possible thanks to #AOSP being open-source, and is already partially done by some Android build tools.
|
|
However, this is not an easy solution.
|
|
Dynamic analysis relying on patched versions of the #AOSP showed that it is difficult to maintain over time software relying on the Android source.
|
|
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.
|
|
|
|
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?]
|
|
|
|
// Futur work: mon unique pov pour le futur: what need to be done
|
|
|
|
|
|
#todo[
|
|
jfl: des pistes pour custom class loader
|
|
jm: oui mais deja données dans ch 4 et c'est quand meme assez spécifique est pas trop le point general de la these
|
|
]
|