update to last revision

4_class_loader/3_obfuscation.typ

@@ -99,7 +99,7 @@ Again, the shadowing implementation discards the data.
 We found that these static analysis tools do not consider the class loading mechanism, either because the tools only look at the content of the application file (#eg a disassembler) or because they consider class loading to be a dynamic feature and thus out of their scope. 
 In @tab:cl-results, we report on the types of shadowing that can be tricked each tool. 
 A plain circle is a shadow attack that leads to a wrong result. 
-A white circle indicates a tool emitting warnings or that eventually displays the two versions of the class. 
+A white circle indicates a tool emitting warnings or that displays the two versions of the class. 
 A cross is a tool not impacted by a shadow attack.
 We explain in more detail in the following the results for each considered tool.
 
@@ -223,6 +223,61 @@ Flowdroid gives priority to the classes from the SDK over the classes implemente
 Unfortunately, `android.jar` only contains classes from the #Asdk, meaning that using #hidec breaks the flow tracking. 
 Solving this issue would require finding the bytecode of all the platform classes of the Android version targeted and as we said previously it requires extracting this information from the emulator.
 
+=== Countermeasures <sec:cl-countermeasures>
+
+Countermeasures against shadow attacks depend on each tool and its objectives.
+The first important recommendation is to implement the class selection algorithm according to the algorithm described in Listing @lst:cl-loading-alg.
+It should solve any case of self-shadowing, except for tools like Apktool, which do not have to select a class for computing the result but show the whole application's content.
+For those tools, a clear warning should be added, pointing out that multiple implementations have been found and displaying the one that will be used at runtime.
+
+Countermeasures against SDK shadow and Hidden shadow attacks are more complex to handle: it requires the list of platform classes on the target smartphone.
+The list of SDK classes can be extracted easily from android.jar, but hidden classes need to be obtained by another means.
+They could be listed directly from the AOSP tree of the Android source code, or obtained from Android documentation, or extracted from the phone itself.
+The first approach requires statically analyzing the source code, which can be difficult to achieve as several programming languages are used, and the code base is large andd fragmented.
+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.
+
+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.
+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.
+
+We believe that analysis tools can handle shadow attacks to some degree.
+The implementation of the solution will differ depending on the nature tool and may not always require the same implementation effort.
+
+=== Relation with obfuscation techniques <sec:cl-cross-obf>
+
+As described in the state of the art, reverse engineers face other techniques of obfuscation such as packers or native code.
+These techniques rely on custom class loaders that load new parts of the application from ciphered assets or from the network.
+The reverse engineers have to study the application dynamically, to recover new classes, and eventually go back to a static phase to understand the behavior of the application.
+In this section, we compare shadow attacks with these techniques and we discuss how they interact with them.
+
+Advanced obfuscation techniques relying on packers have a higher impact on the difficulty of performing a static analysis compared to shadow attacks.
+Most of the time, the reverse engineer cannot deobfuscate the application without performing a dynamic analysis.
+For this reasons, approaches have been designed to assist the capture of the bytecode that is loaded dynamically, after the precise time where the deobfuscation methods have been executed@zhang2015dexhunter @xue2017adaptive @wong2018tackling.
+On the contrary, a shadow attack can be easily defeated by implementing our algorithm in the static analysis tool, as discussed earlier in @sec:cl-countermeasures.
+Nevertheless, shadow attacks are stealthier than packers or native code. 
+Packers can be easily spotted by artifacts left behind in the application or by detecting classes implementing a custom class loading mechanism.
+On the contrary, an extra class implementing a shadow attack, that would not be executed, could contain voluntarily few code, compared to the executed class of Android.
+Such attack would be more discrete than a packer that adds in the application a lot of possibly native code
+
+Combining regular obfuscation techniques with shadow attacks can be achieved in two ways.
+
+First, the attacker could hide the code of a packer or a native call by using a shadow attack.
+For example, by colliding a class of the SDK, a control flow analysis could be wrongly computed, leading to consider that part of the code is dead, which would mislead the reverse engineer about the use of this part that contains a packer.
+At runtime, this code would be triggered, unpacking new code.
+
+Second, the attacker could use a packer to unpack code at runtime in a first phase.
+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. 
+This problem is left as future work.
+
+
 //\medskip
 
 We have seen that tools can be impacted by shadow attacks. In the next section, we will investigate if these attacks are used in the wild.