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

typos
All checks were successful
/ test_checkout (push) Successful in 1m46s
Details

Browse source
This commit is contained in:
Jean-Marie 'Histausse' Mineau 2025-10-06 02:36:40 +02:00
parent 4176428343
commit 2d5cb2459e
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
1 changed files with 4 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

8
6_conclusion/2_futur.typ
View file

@ -10,16 +10,16 @@ The error we analysed in @sec:rasta showed that even something that should be ba
@sec:cl also showed that reproducing the exact behaviour of Android is more difficult than it seems (in our specific case, it was the class loading algorithm, but we can expect other features to have similar edge cases). @sec:cl also showed that reproducing the exact behaviour of Android is more difficult than it seems (in our specific case, it was the class loading algorithm, but we can expect other features to have similar edge cases).
As long as those issues are not solved, we cannot build robust analysis tools. 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. One avenue we believe should be investigated would be to reuse the code actually used by Android.
For instance, the parsing of #DEX, #APK and ressource files could be done using the same code as the #ART. For instance, the parsing of #DEX, #APK, and resource files could be done using the same code as the #ART.
This is possible thanks to #AOSP being open-source, and is already partially done by some Android build tools. 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. However, this is not an easy solution.
Dynamic analysis relying on patched versions of the #AOSP showed that it is difficult to maintain this kind of software time. Dynamic analysis relying on patched versions of the #AOSP showed that it is difficult to maintain this kind of software over time.
Doing this would require limiting the modifications to the actual source code of Android to lower the changes needed at each update of Android. Doing this would require limiting the modifications to the actual source code of Android to minimise the changes needed at each Android update.
Another obstacle to overcome is to decouple the compilation of the tool from the rest of #AOSP: it is a massive dependency that needs a lot of resources to build. Another obstacle to overcome is to decouple the compilation of the tool from the rest of #AOSP: it is a massive dependency 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. 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. 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, to test the capacity of a tool to handle real-life applications. An orthogonal solution to this problem is to create a new benchmark to test the capacity of a tool to handle real-life applications.
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). 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).
We suggest using a similar method to what we did in @sec:rasta to keep the benchmark independent from the tested tools. 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. Instead of checking the correctness of the tools, this benchmark should test if the tool is able to finish its analysis.