small refactor

5_class_loader/6_conclusion.typ

@@ -0,0 +1,16 @@
+#import "X_var.typ": *
+
+== Conclusion <sec:cl-conclusion>
+
+This paper has presented three shadow attacks that allow malware developers to fool static analysis tools when reversing an Android application. 
+By including multiple classes with the same name or by using the same name as a class of the #Asdk, the developer can mislead a reverser or impact the result of a flow analysis, such as the ones of Androguard or Flowdroid.
+
+We explored if such shadow attacks are present in as dataset of #nbapk applications . 
+We found that on average, #shadowsdk of applications are shadowing the SDK, mainly for retro-compatibility purposes and library embedding. 
+More suspiciously, #shadowhidden of applications are shadowing a hidden class, which could lead to unexpected execution as these classes can appear/disappear with the evolution of Android internals. 
+Investigations for applications that defined classes multiple times suggest that the compilation process or the inclusion of different versions of the same library is the main explanation. 
+Finally, when investigating malware samples, we found a specific sample containing a shadow attack that would hide a part of the critical code from a reverser studying the application.
+
+Future work concerns the correctness of bytecode analysis. 
+For now, we rely on the Smali representation of the bytecode but the compilation process makes this comparison difficult.
+We intend to better parse the bytecode to summarize it and be able to have a more reliable comparison method.