conclusion easy part done

This commit is contained in:
Jean-Marie 'Histausse' Mineau 2025-09-23 17:07:10 +02:00
parent 3f3f03c97d
commit d9650d0775
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
2 changed files with 21 additions and 13 deletions

View file

@ -7,26 +7,33 @@
In this thesis, we presented the following contributions.
First, we explored the reusabiliy of static analysis tools.
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 analysis the finished and return a result.
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 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 of the times.
The study of the succes rate of the tools for applications grouped by their caracteristics showed that the greater bytecode size increase the chance of analysis failure.
The same goes for min #SDK version to a lesser extent, and it appears that analyses of malwares are less likely to encounter a fatal error than analyses of goodware.
In the process of testing the tools, we built docker images of working setup for the tools.
We released those images in the hope to help future researcher that would want to use those tools.
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.
During the testing process, we built Docker images of working setups for the tools.
We released those images in the hope of helping future researchers who would want to use those tools.
Our second contributions models the default class loading behaviour of Android and introduced a class of obfuscation based on it: shadow attacks.
We showed that, by including multiple classes with the same name in an application, or including classes with the same name as classes in the android #SDK, and application can mislead a reverse engineer or impact the results of analysis tools.
We scanned a dataset of rescent applications and found that although those situations appear in wild, shadow attacks do no seam to be actually used.
Instead, we believe that classes from the #SDK are added either for retro-compatibility or due to the developper being unaware that a library was already present in the Android #SDK, and the few cases were classes are present multiple times in the application look like mistakes during the compilation of the application.
Still, #cl.shadowsdk of the applications we tested were shadowing classes from targeted #SDK version.
Our second contribution models the default class loading behaviour of Android and introduces a class of obfuscation based on it: shadow attacks.
We showed that, by including multiple classes with the same name in an application, or including classes with the same name as classes in the Android #SDK, an application can mislead a reverse engineer or impact the results of analysis tools.
We scanned a dataset of recent applications and found that although those situations appear in the wild, shadow attacks do not seem to be actually used.
Instead, we believe that classes from the #SDK are added either for retro-compatibility or due to the developer being unaware that a library was already present in the Android #SDK, and the few cases where classes are present multiple times in the application appear to be mistakes during the compilation of the application.
Still, #cl.shadowsdk of the applications we tested were shadowing classes from the targeted #SDK version.
Lastly, we proposed a solution to reuse any static analysis tool on an application that uses dynamic code loading or reflection.
To do so, we collect the relevant information dynamically, then instrument the application to encode the dynamic information inside a valid application mimicking the dynamic behaviour of the original one.
This new application can then be analysed normally by any tool that accepts an application as input.
We tested our method on a subset of recent applications from the dataset of our first contribution.
The results of our dynamic analysis suggest that we failed to correctly explore many applications, hinting at weaknesses in our experimental setup.
Nonetheless, we did obtain some dynamic data, allowing us to pursue our experiment.
We compared the finishing rate of tools on the original application and the instrumented application using the same experiment as in our first contribution, and found that, in general, the instrumentation only slightly reduces the finishing rate of analysis tools.
We also confirmed that the instrumentation does improve the result of analysis tools, allowing them to compute more comprehensive call graphs of the applications, or to detect new data flows.
/*
* Futur work: mon unique pov pour le futur: what need to be done
*
* Take aways depuis l'intro
* puis résumé des contributions majeurs, un paragraphe par contrib

View file

@ -13,4 +13,5 @@
Robust default, close to Android: the java zip parser is often targeted, there is something to be done here
]
// 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 ?