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

some work on rasta

Browse source
This commit is contained in:
Jean-Marie Mineau 2025-08-07 00:06:29 +02:00
parent 2e52599a7c
commit 4ad17d2484
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
5 changed files with 56 additions and 13 deletions
Download patch file Download diff file Expand all files Collapse all files

17
3_rasta/1_related_work.typ
View file

@ -1,4 +1,4 @@
#import "../lib.typ": etal, eg, ie
#import "../lib.typ": etal, eg, ie, jfl-note
#import "X_var.typ": *
== Related Work <sec:rasta-soa>
@ -9,16 +9,25 @@
// For example, taint analysis datasets should provide the source and expected sink of a taint.
// In some cases, the datasets are provided with additional software for automatizing part of the analysis.
// Thus,
We review in this section the past existing contributions related to static analysis tools reusability.
#jfl-note[We review in this section the past existing contributions related to static analysis tools reusability.][lier a chap 2]
Several papers have reviewed Android analysis tools produced by researchers.
Li #etal~@Li2017 published a systematic literature review for Android static analysis before May 2015.
They analyzed 92 publications and classified them by goal, method used to solve the problem and underlying technical solution for handling the bytecode when performing the static analysis.
In particular, they listed 27 approaches with an open-source implementation available.
Nevertheless, experiments to evaluate the reusability of the pointed out software were not performed.
We believe that the effort of reviewing the literature for making a comprehensive overview of available approaches should be pushed further: an existing published approach with a software that cannot be used for technical reasons endanger both the reproducibility and reusability of research.
#jfl-note[We believe that the effort of reviewing the literature for making a comprehensive overview of available approaches should be pushed further: an existing published approach with a software that cannot be used for technical reasons endanger both the reproducibility and reusability of research.][A mettre avant?]
Works that perform benchmaks of tools follow a similar method.
They select a set of tools with similar goals.
Usually, those contribusions are comparing existing tools to their own, but some contributions do not introduce a new tool and focus on surveying the state of the art for some technique.
As we saw in @sec:bg-datasets, the need for a ground truth to compare the results of the tools leads to test datasets to often be handcrafted.
Some studdy will select a few real-world applications instead, a manually reverse engineer those application to get the ground truth.
Once the tools and test dataset are selected, the tools are run on the application dataset, and the results of the tools are compared to the ground truth to determine the accuracy of each tools.
Several factors are the considered to compare the results of the tools.
It can be the number of false positive, false negative, or even the time it took to finish the analysis.
Occasionally, the number of application a tool simply failled to analyse are also compared.
As we saw in @sec:bg-datasets that the need for a ground truth to test analysis tools leads test datasets to often be handcrafted.
The few datasets composed of real-world application confirmed that some tools such as Amandroid~@weiAmandroidPreciseGeneral2014 and Flowdroid~@Arzt2014a are less efficient on real-world applications~@bosuCollusiveDataLeak2017 @luoTaintBenchAutomaticRealworld2022.
Unfortunatly, those real-world applications datasets are rather small, and a larger number of applications would be more suitable for our goal, #ie evaluating the reusability of a variety of static analysis tools.