wip

4_class_loader/3_obfuscation.typ

@@ -8,7 +8,7 @@ Then, in order to evaluate their efficiency, we reviewed some common Android rev
 We call this collision "*class shadowing*", because the attacker version of the class shadows the one that will be used at runtime. 
 To evaluate if such shadow attacks are working, we handcrafted  three applications implementing shadowing techniques to test their impact on static analysis tools. 
 Then, we manually inspected the output of the tools in order to check its consistency with what Android is really doing at runtime. 
-For example, for Apktool, we look at the output disassembled code, and for Flowdroid@Arzt2014a, we check that a flow between `Taint.source()` and `Taint.sink()` is correctly computed.
+For example, for Apktool, we look at the output disassembled code, and for Flowdroid~@Arzt2014a, we check that a flow between `Taint.source()` and `Taint.sink()` is correctly computed.
 
 
 /*
@@ -78,7 +78,7 @@ Such shadow attacks are more difficult to detect by a reverser, that may not kno
 )<lst:cl-testapp>
 
 
-We selected tools that are commonly used to unpack and reverse Android applications: Jadx#footnote[https://github.com/skylot/jadx], a decompiler for Android applications, Apktool#footnote[https://apktool.org/], a disassembler/repackager of applications, Androguard#footnote[https://github.com/androguard/androguard], one of the oldest Python package for manipulating Android applications, and Flowdroid@Arzt2014a that performs taint flow analysis. 
+We selected tools that are commonly used to unpack and reverse Android applications: Jadx#footnote[https://github.com/skylot/jadx], a decompiler for Android applications, Apktool#footnote[https://apktool.org/], a disassembler/repackager of applications, Androguard#footnote[https://github.com/androguard/androguard], one of the oldest Python package for manipulating Android applications, and Flowdroid~@Arzt2014a that performs taint flow analysis. 
 
 For evaluating the tools, we designed a single application that we can customize for different tests.
 @lst:cl-testapp shows the main body implementing:
@@ -204,11 +204,11 @@ Because of that, like for Apktool and Jadx, Androguard has no way to warn the re
 
 ==== Flowdroid
 
-Flowdroid@Arzt2014a is used to detect if an application can leak sensitive information. 
+Flowdroid~@Arzt2014a is used to detect if an application can leak sensitive information. 
 To do so, the analyst provides a list of source and sink methods. 
 The return value of a method marked as source is considered sensitive and the argument of a method marked as sink is considered to be leaked. 
 By analyzing the bytecode of an application, Flowdroid can detect if data emitted by source methods can be exfiltrated by a sink method. 
-Flowdroid is built on top of the Soot@Arzt2013 framework that handles, among other things, the class selection process. 
+Flowdroid is built on top of the Soot~@Arzt2013 framework that handles, among other things, the class selection process. 
 
 We found that when selecting the classes implementation in a multi-dex APK, Soot uses an algorithm close to what ART is performing: 
 Soot sorts the `.dex` bytecode file with a specified `prioritizer` (a comparison function that defines an order for #dexfiles) and selects the first implementation found when iterating over the sorted files. 
@@ -257,7 +257,7 @@ In this section, we compare shadow attacks with these techniques and we discuss
 
 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.
+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.
@@ -271,7 +271,7 @@ For example, by colliding a class of the SDK, a control flow analysis could be w
 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.
+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.