#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.
