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

wip
All checks were successful
/ test_checkout (push) Successful in 1m45s
Details

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

2
6_conclusion/1_contributions.typ
View file

@ -11,7 +11,7 @@ First, we explored the reusability of static analysis tools.
Based on a systematic literature review by Li #etal, we identified 22 tools of interest, published between 2012 and 2017.
To estimate the current usability of those tools, we tested their most recent version on a large dataset of #rasta.NBTOTALSTRING applications.
We then counted the number of analyses that finished and returned a result.
We established that #rasta.resultunusable of #rasta.nbtoolsselectedvariations tools are not reusable.
We established that #rasta.resultunusable of #rasta.nbtoolsselectedvariations tools are not reusable, in particular when the applications are recent.
We were not able to use two of them, even with the help of the authors, while 10 others failed to finish their analysis more than half the time.
The study of the finishing rate of the tools for applications grouped by their characteristics showed that the greater bytecode size increases the chance of analysis failure.
The same goes for min #SDK version to a lesser extent, and it appears that analyses of malware are less likely to encounter a fatal error than analyses of goodware.

30
6_conclusion/2_futur.typ
View file

@ -1,8 +1,25 @@
#import "../lib.typ": todo
#import "../lib.typ": todo, AOSP
== Perspectives for Future Work
#todo[What futur 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.
]
The main issue that appeared in all our work is an 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.
#todo[
Ideas:
@ -13,5 +30,12 @@
Robust default, close to Android: the java zip parser is often targeted, there is something to be done here
]
#todo[web-base? flutter? wasm?]
// Futur work: mon unique pov pour le futur: what need to be done
// future work plus haut niveau: reprandre les plus important et/ou des plus large: eg: quide web-base? flutter? wasm ?
#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
]