43 lines
3.7 KiB
Typst
43 lines
3.7 KiB
Typst
#import "../lib.typ": etal, SDK, todo
|
|
|
|
#import "../3_rasta/X_var.typ" as rasta
|
|
#import "../4_class_loader/X_var.typ" as cl
|
|
|
|
== Contributions of this Thesis
|
|
|
|
In this thesis, we presented the following contributions.
|
|
|
|
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, 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.
|
|
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 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 improves the result of analysis tools, allowing them to compute more comprehensive call graphs of the applications, or to detect new data flows.
|
|
|
|
/*
|
|
*
|
|
* Take aways depuis l'intro
|
|
* puis résumé des contributions majeurs, un paragraphe par contrib
|
|
*
|
|
*/
|
|
|
|
|