#import "../lib.typ": etal, ie, ART, DEX, APK, SDK, eg
#import "X_var.typ": *

== Introduction

In this chapter, we study how Android handles the loading of classes in the case of multiple versions of the same class. 
Such collisions can exist inside the #APK file or between the #APK file and #Asdkc. 
We intend to understand if a reverser would be impacted during a static analysis when dealing with such obfuscated code. 
Because this problem is already complex enough with the current operations performed by Android, we exclude the case where the application uses class loaders dynamically (#eg dynamic code loading).
We present a new technique that "shadows" a class, #ie embeds a class in the #APK file and "presents" it to the reverser instead of the legitimate version. 
We show how these attacks can confuse the tools of the reverser when he performs a static analysis, and, in order to evaluate if such attacks are already used in the wild, we analysed #nbapk applications from 2023 that we extracted randomly from AndroZoo~@allixAndroZooCollectingMillions2016. 

The chapter is structured as follows. 
@sec:cl-loading investigates the internal mechanisms of class loading and presents how a reverser can be confused by these mechanisms. 
Then, in @sec:cl-obfuscation, we design obfuscation techniques and show their effect on static analysis tools. 
Next, @sec:cl-wild evaluates if these obfuscation techniques are used in the wild by scanning #nbapk APKs.
@sec:cl-conclusion extends on the possible countermeasures against those shadow attacks, how they interact with other obfuscation techniques, as well as the limitations of this work and avenues left to explore.
Finally, @sec:cl-conclusion concludes the chapter.
