wip

4_class_loader/0_intro.typ

@@ -46,7 +46,7 @@ We present a new technique that "shadows" a class #ie  embeds a class in the APK
 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. 
 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 analysed #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.
 

4_class_loader/1_related_work.typ

@@ -12,7 +12,7 @@ This behavior is now implemented in modern Java virtual machines.
 Later Tazawa and Hagiya~@tozawa_formalization_2002 proposed a formalization of the Java Virtual Machine supporting dynamic class loading in order to ensure type safety. 
 Those works ensure strong safety for the Java Virtual Machine, in particular when linking new classes at runtime. 
 Although Android has a similar mechanism, the implementation is not shared with the JVM of Oracle.
-Additionally, in this paper, we do not focus on spoofing classes at runtime, but on confusion that occurs when using a static analyzer used by a reverser that tries to understand the code loading process offline.
+Additionally, in this paper, we do not focus on spoofing classes at runtime, but on confusion that occurs when using a static analyser used by a reverser that tries to understand the code loading process offline.
 
 Contributions about Android class loading focus on using the capabilities of class loading to extend Android features or to prevent reverse engineering of Android applications. 
 For instance, Zhou #etal~@zhou_dynamic_2022 extend the class loading mechanism of Android to support regular Java bytecode and Kritz and Maly~@kriz_provisioning_2015 propose a new class loader to automatically load modules of an application without user interactions. 

4_class_loader/3_obfuscation.typ

@@ -251,10 +251,10 @@ As discussed earlier in the paper, the documentation can lack some classes.
 Consequently, the most reliable source is the smartphone itself.
 It should be noted that none of these methods can be generalized for all possible versions of Android, as the exact list will depend on the exact targeted device, possibly modified by the manufacturer.
 Thus, to conter Shadow attaks, the static analysis tools that we evaluated need to embed multiple lists of platform classes, one for each Android version.
-Then, the best heuristic would be to use the list of platform classes that is closest to the target SDK of the analyzed application.
+Then, the best heuristic would be to use the list of platform classes that is closest to the target SDK of the analysed application.
 
-Some tools like Flowdroid would require additional countermeasures: to compute the exact flow of data, Flowdroid also needs to analyze the code of platform classes.
-For the SDK classes, Flowdroid has already analyzed them, but the hidden classes have not.
+Some tools like Flowdroid would require additional countermeasures: to compute the exact flow of data, Flowdroid also needs to analyse the code of platform classes.
+For the SDK classes, Flowdroid has already analysed them, but the hidden classes have not.
 In addition to the data flow in hidden classes, Flowdroid needs a list of data sources and sinks from those classes.
 %Other analysis tools may require additional data from platform classes, which may be too difficult to obtain.
 
@@ -287,7 +287,7 @@ Second, the attacker could use a packer to unpack code at runtime in a first pha
 The reverse engineer would have to perform a dynamic analysis, for example uising a tool such as Dexhunter~@zhang2015dexhunter, to recover new DEX files that are loaded by a custom class loader.
 Then, the reverse engineer would go back to a new static analysis and could have the problem of solving shadow attacks, for example, if a class is defined multiple times in the loaded DEX files.
 
-Because the interaction between shadow attacks and other obfuscations techniques often rely on a loading mechanism implemented by the developer, investigating these cases require to analyze the Java bytecode that is handling the loading. 
+Because the interaction between shadow attacks and other obfuscations techniques often rely on a loading mechanism implemented by the developer, investigating these cases require to analyse the Java bytecode that is handling the loading. 
 This problem is left as future work.
 
 

4_class_loader/5_ttv.typ

@@ -1,6 +1,6 @@
 == Threat to Validity <sec:cl-ttv>
 
-During the analysis of the ART internals, we made the hypothesis that its different operating modes are equivalent: we analyzed the loading process for classes stored as non-optimized `.dex` format, and not for the pre-compiled `.oat`. 
+During the analysis of the ART internals, we made the hypothesis that its different operating modes are equivalent: we analysed the loading process for classes stored as non-optimized `.dex` format, and not for the pre-compiled `.oat`. 
 It is a reasonable hypothesis to suppose that the two implementations have been produced from the same algorithm using two compilation workflows.
 Similarly, we assumed that the platform classes stored in `boot.art` are the same as the ones in `BOOTCLASSPATH`.
 We confirm empirically our hypothesis on an Android Emulator, but we may have missed some edge cases.

4_class_loader/main.typ

@@ -1,9 +1,20 @@
-#import "../lib.typ": todo, epigraph
+#import "../lib.typ": epigraph, ART, APK, ie, highlight-block
+#import "X_var.typ": nbapk
 
-= Class Loaders in the Middle: Confusing Android Static Analyzers <sec:cl>
+= Class Loaders in the Middle: Confusing Android Static Analysers <sec:cl>
 
 #epigraph("Esmerelda Weatherwax, Wyrd Sisters, Terry Pratchett")[Things that try to look like things often do look more like things than things.]
 
+#align(center, highlight-block(inset: 15pt, width: 75%, block(align(left)[
+  The dynamic linking and loading of the different classes by the #ART is a complex task that can eventually be exploited by an attacker.
+  In particular, if the developer adds a class whose name collides with the name of a class of the Android operating system or another class in the application, they may confuse a reverse engineer in charge of studying such an application.
+  In this chapter, we explore the consequences of those collisions.
+  We highlight three attacks that we call shadow attacks because the class implementation that a reverser would find shadows a second implementation with a higher priority.
+  In particular, we show that a static analysis tools used by a reverser choose the shadow implementation for most of the evaluated tools, and outputs a wrong result.
+  In a dataset of #nbapk applications, we also investigate whether shadow attacks are used in the wild and show that, most of the time, there is no malicious behavior behind them.
+])))
+
+
 #include("0_intro.typ")
 #include("1_related_work.typ")
 #include("2_classloading.typ")