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

typos in ch 3
All checks were successful
/ test_checkout (push) Successful in 1m58s
Details

Browse source
This commit is contained in:
Jean-Marie 'Histausse' Mineau 2025-09-29 16:36:54 +02:00
parent 2df810c3bd
commit 4e38131df5
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
5 changed files with 65 additions and 65 deletions
Download patch file Download diff file Expand all files Collapse all files

24
3_rasta/9_conclusion.typ
View file

@ -5,21 +5,21 @@
== Conclusion <sec:rasta-conclusion>
Since the release of Android, many tools have been published in order to analyse Android application.
In @sec:bg, we went through contributions benchmarking and comparing some of those tools.
Those contributions suggested that analysing real-world applications might be more of a challenged than expected.
Since the release of Android, many tools have been published in order to analyse Android applications.
In @sec:bg, we went through contributions that benchmark and compare some of those tools.
Those contributions suggested that analysing real-world applications might be more challenging than expected.
This led us to question the reusability of those tools (#pb1).
This chapter has assessed the suggested results of the literature~@luoTaintBenchAutomaticRealworld2022 @pauckAndroidTaintAnalysis2018 @reaves_droid_2016 about the reliability of static analysis tools for Android applications.
With a dataset of #NBTOTALSTRING applications we established that #resultunusable of #nbtoolsselectedvariations tools are not reusable.
2 of those where due to the fact that whe did not managed to use the tools, even with the help of the author.
We consider the 10 other tools the be unusable due to the fact that they fail to finish their analysis more than 50% of the time..
With a dataset of #NBTOTALSTRING applications, we established that #resultunusable of #nbtoolsselectedvariations tools are not reusable.
2 of those were due to the fact that we did not manage to use the tools, even with the help of the author.
We consider the 10 other tools to be unusable due to the fact that they fail to finish their analysis more than 50% of the time..
In total, the analysis success rate of the tools that we could run for the entire dataset is #resultratio.
The characteristics that have the most influence on the success rate is the bytecode size and min #SDK version.
Finally, we showed that malware #APKs generate less fatal errors than goodware when analysed.
The characteristics that have the most influence on the success rate are the bytecode size and the min #SDK version.
Finally, we showed that malware #APKs generate fewer fatal errors than goodware when analysed.
Following Reaves #etal recommendations~@reaves_droid_2016, we publish the Docker and Singularity images we built to run our experiments alongside the Docker files.
This will allow the research community to use directly the tools without the build and installation penalty.
This will allow the research community to use the tools directly without the build and installation penalty.
#v(2em)
@ -27,8 +27,8 @@ This will allow the research community to use directly the tools without the bui
#pb1: #pb1-text
#v(0.75em)
More than half the tools we selected were not usable.
In some cases, it was due to our inability to setup the tool correctly.
In some cases, it was due to our inability to set up the tool correctly.
Mostly, it was due to the high failure rate when analysing real-world applications.
Results show that large applications cause more crashes, as does applications with higher min #SDK target.
Goodware also appear to generate more analysis failure than malware.
Results show that large applications cause more crashes, as do applications with a higher min #SDK target.
Goodware also appear to generate more analysis failures than malware.
])))