wip

4_class_loader/0_intro.typ

@@ -17,7 +17,7 @@ For such a task, some automated analysis is performed, but sometimes, a manual i
 A reverser is in charge of studying the application: they usually perform a static analysis and a dynamic analysis. 
 The reverser uses in the first phase static analysis tools in order to access and review the code of the application. 
 If this first phase is not accurately driven, for example if they fail to access a critical class, they may decide that a malicious application is safe. 
-Additionally, as stated by Li #etal@Li2017 in their conclusions, such a task is complexified by dynamic code loading, reflective calls, native code, and multi-threading which cannot be easily handled statically. 
+Additionally, as stated by Li #etal~@Li2017 in their conclusions, such a task is complexified by dynamic code loading, reflective calls, native code, and multi-threading which cannot be easily handled statically. 
 Nevertheless, even if we do not consider these aspects, determining statically how the regular class loading system of Android is working is a difficult task.
 
 Class loading occurs at runtime and is handled by the components of #ART, even when the application is partially or fully  compiled ahead of time. 
@@ -32,8 +32,8 @@ As a consequence, it is frequent to find inside applications some classes that c
 At runtime each smartphone runs a unique version of Android, but, as the application is deployed on multiple versions of Android, it is difficult to predict which classes will be loaded from the #Asdkc or from the APK file itself. 
 This complexity increases with the multi-#DEX format of recent #APK files that can contain several bytecode files. 
 
-Going back to the problem of a reverser studying a suspicious application statically, the reverser uses tools to disassemble the application@mauthe_large-scale_2021 and track the flows of data in the bytecode. 
-As an example, for a spyware potentially leaking personal information, the reverser can unpack the application with Apktool and, after manually locating a method that they suspect to read sensitive data (by reading the unpacked bytecode), they can compute with FlowDroid@Arzt2014a if there is a flow from this method to methods performing HTTP requests. 
+Going back to the problem of a reverser studying a suspicious application statically, the reverser uses tools to disassemble the application~@mauthe_large-scale_2021 and track the flows of data in the bytecode. 
+As an example, for a spyware potentially leaking personal information, the reverser can unpack the application with Apktool and, after manually locating a method that they suspect to read sensitive data (by reading the unpacked bytecode), they can compute with FlowDroid~@Arzt2014a if there is a flow from this method to methods performing HTTP requests. 
 During these steps, the reverser faces the problem of resolving statically, which class is loaded from the APK file and the #Asdkc. 
 If they, or the tools they use, choose the wrong version of the class, they may obtain wrong conclusions about the code. 
 Thus, the possibility of shadowing classes could be exploited by an attacker in order to obfuscate the code.
@@ -41,12 +41,12 @@ Thus, the possibility of shadowing classes could be exploited by an attacker in
 In this paper, we study how Android handles the loading of classes in the case of multiple versions of the same class. 
 Such collision 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 an obfuscated code. 
-Because this problem is already enough complex with the current operations performed by Android, we exclude the case where a developer recodes a specific class loader or replace a class loader by another one, as it is often the case for example in packed applications@Duan2018. 
+Because this problem is already enough complex with the current operations performed by Android, we exclude the case where a developer recodes a specific class loader or replace a class loader by another one, as it is often the case for example in packed applications~@Duan2018. 
 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. 
 The goal of such an attack is to confuse them during the reversing process: at runtime the real class will be loaded from another location of the APK file or from the #Asdk, instead of the shadow version. 
-This attack can be applied to regular classes of the #Asdk or to hidden classes of Android@he_systematic_2023 @li_accessing_2016. 
+This attack can be applied to regular classes of the #Asdk or to hidden classes of Android~@he_systematic_2023 @li_accessing_2016. 
 We show how these attacks can confuse the tools of the reverser when he performs a static analysis. 
-In order to evaluate if such attacks are already used in the wild, we analyzed #nbapk applications from 2023 that we extracted randomly from AndroZoo@allixAndroZooCollectingMillions2016. 
+In order to evaluate if such attacks are already used in the wild, we analyzed #nbapk applications from 2023 that we extracted randomly from AndroZoo~@allixAndroZooCollectingMillions2016. 
 Our main result is that  #shadowsdk of these applications contain shadow collisions against the #SDK and #shadowhidden against hidden classes. 
 Our investigations conclude that most of these collisions are not voluntary attacks, but we highlight one specific malware sample performing strong obfuscation revealed by our detection of one shadow attack.