wip conclusion

6_conclusion/1_contributions.typ

@@ -0,0 +1,36 @@
+#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 reusabiliy 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 established that #resultunusable of #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.
+
+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.
+
+
+/*
+* 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
+*
+*/
+
+

6_conclusion/2_futur.typ

@@ -0,0 +1,16 @@
+#import "../lib.typ": todo
+
+== Perspectives for Future Work
+
+#todo[What futur work]
+
+#todo[
+  Ideas:
+  - Standard Lib to interact with dalvik (dev by google?), with *STABLE* API and *ROBUST*: Today there is Apktool, Soot and Androguard
+    Apktool don't have a documented API, and by default do a lot of things that might work or not
+    Soot defaults are baaaadddd, maybe the new version?
+    Androguard is not bad, but not write capabilities (yet, it's a wip, maybe one day?)
+    Robust default, close to Android: the java zip parser is often targeted, there is something to be done here
+]
+
+// future work plus haut niveau: reprandre les plus important et/ou des plus large: eg: quide web-base? flutter? wasm ?