ch4 related soa

2_background/6_classloading.typ

@@ -0,0 +1,41 @@
+#import "../lib.typ": DEX, pb2, pb2-text, etal
+
+== Class Loading <sec:bg-cl>
+
+Another rarely considered element of Android is its class loading mechanism.
+Class loading is a fundamental element of Java, it define which classes are loaded from where.
+In Android, this is often associated to dynamic code loading, as the `ClassLoader` objects are used to load code at runtime.
+However, class loading also intervenes to load platform classes or classes from the application itself, and thus require some attention when analysing an application.
+
+Class loading mechanisms have been studied in the general context of the Java language. 
+Gong~@gong_secure_1998 describes the JDK 1.2 class loading architecture and capabilities. 
+One of the main advantages of class loading is the type safety property that prevents type spoofing. 
+As explained by Liang and Bracha~@liang_dynamic_1998, by capturing events at runtime (new loaders, new class) and maintaining constraints on the multiple loaders and their delegation hierarchy, authors can avoid confusion when loading a spoofed class. 
+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 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. 
+
+Regarding reverse engineering, class loading mechanisms are frequently used by packers for hiding all or parts of the code of an application~@Duan2018. 
+For example, packers exploits the class loading capability of Android to load new code. 
+They also combine the loading with code generation from ciphered assets or code modification from native code calls~@liao2016automated to increase the difficulty of recovery of the code. 
+Because parts of the original code will be only available at runtime, deobfuscation approaches propose techniques that track #DEX structures when manipulated by the application~@zhang2015dexhunter @xue2017adaptive @wong2018tackling. 
+Those contributions interact with the class loading mechanism of Android to collect the #DEX structures at the right moment.
+
+Deobfuscating an application is the first problem the reverse engineer has to solve. 
+Nevertheless, even, if all classes of the code are recovered by the reverse engineer, understanding what are the classes that are really loaded by Android brings an additional problem. 
+The reverse engineer can have the feeling that what he sees in the bytecode is what is loaded at runtime, whereas the system can choose alternative implementations of a class.
+
+#v(2em)
+
+Class loading mechanisms have been studies carefully in the context of the Java language.
+However, the same cannot be said about Android, whose implementation significantly from classic Java Virtual Machine.
+Most work done on Android focus on extending Android capabilities using class loading, or on analysing dynamically the code loading operations of an application.
+This leaves open the question of the actual default class loading behavior of Android, leading us to #pb2:
+
+#pb2-text
+