ch4 related soa

2_background/5_platform_classes.typ

@@ -0,0 +1,21 @@
+#import "../lib.typ": SDK, API, API, etal
+
+== Platform Classes <sec:bg-platform>
+
+In addition to the classes they include, Android applications have access to classes provided by Android.
+Those classes are called _platform classes_.
+They are devided between #SDK classes, and hidden #API.
+The #SDK classes can be seen as the Android standard library.
+They are documented by Google, and have a certain stability from version to version.
+In case of breaking changes, the changed are listed by Google as well.
+The list of #SDK classes is available at complite time in the form of a `android.jar` file to link against.
+
+On the opposite, hidden #API are undocumented methods used internally by Android.
+Still, they are loaded by the application and can be used by it.
+Thus, they are a potential blind spot when analysing an application.
+However, not a lot a research has been done on the subject.
+Li #etal did an empirical study of the usage and evolution of hidden #API~@li_accessing_2016.
+They found that hidden #API are added and removed in every release of Android, and that they are used both by benign and malicious applications.
+More recently, He #etal~@he_systematic_2023 did a systematic study of hidden service #API related to security.
+They studied how the hidden #API can be used to bypass Android security restrictions and found that although Google countermeasures are effective, they need to be implemented inside the system services and not the hidden #API due to the lack of in-app privilege isolation: the framework code is in the same process as the user code, meaning any restriction in the framework can be bypassed by the user.
+Unfortunately those two contributions do not explore further the consequences of the use of hidden #API for a reverse engineer.

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
+

2_background/X_dynamic_analysis.typ

@@ -1,6 +1,6 @@
 #import "../lib.typ": todo, APK, etal, ART, SDK, eg, jm-note, jfl-note
 
-=== Dynamic Analysis <sec:bg-dynamic>
+== Dynamic Analysis <sec:bg-dynamic>
 
 #todo[include properly]
 

2_background/_chapter_4_soa.typ

@@ -1,44 +0,0 @@
-#import "../lib.typ": etal, paragraph, DEX, todo
-
-=== SOA CLASS CHAP 4 <sec:cl-soa>
-
-#todo[include in CHAP 2 properly]
-#todo[Split Class Loading and Hidden API in subsection]
-
-#paragraph([Class loading])[
-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. 
-The problem to be solved consists in locating secondary #DEX files that can be unciphered just before being loaded. 
-Dynamic hook mechanisms should be used to intercept the bytecode at load time. 
-These techniques can be of some help for the reverser, but they require to instrument the source code of AOSP or the application itself. 
-The engineering cost is high and anti-debugging techniques can slow down the process. 
-Thus, a reverser always starts by studying statically an application using static analysis tools~@Li2017, and will eventually go to dynamic analysis~@Egele2012 if further costly extra analysis is needed (for example, if they spot the use of a custom class loader). 
-Performing a static analysis of an application can be time consuming if the programmer uses obfuscation techniques such as native code, packing techniques, value encryption, or reflection. 
-Such techniques can partially hide the Java bytecode from a static analysis investigation as they modify it at runtime. 
-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. All those contributions are directly related to the class loading mechanism of Android.
-
-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.
-Our goal is to show that tools mentioned in the literature~@Li2017 can suffer from attacks exploiting confusion inside regular class loading mechanisms of Android.
-]
-
-#paragraph([Hidden APIs])[
-Li #etal did an empirical study of the usage and evolution of hidden APIs~@li_accessing_2016. 
-They found that hidden APIs are added and removed in every release of Android, and that they are used both by benign and malicious applications. 
-More recently, He #etal~@he_systematic_2023 did a systematic study of hidden service API related to security. 
-They studied how the hidden API can be used to bypass Android security restrictions and found that although Google countermeasures are effective, they need to be implemented inside the system services and not the hidden API due to the lack of in-app privilege isolation: the framework code is in the same process as the user code, meaning any restriction in the framework can be bypassed by the user.
-]

2_background/main.typ

@@ -9,7 +9,8 @@
 #include("2_tools.typ")
 #include("3_static_analysis.typ")
 #include("4_datasets_and_benchmarking.typ")
-#include("_chapter_4_soa.typ")
+#include("5_platform_classes.typ")
+#include("6_classloading.typ")
 #include("X_dynamic_analysis.typ")
 
 /*