Jean-Marie 'Histausse' Mineau
f23390279c
Some checks failed
/ test_checkout (push) Failing after 22s
18 lines
1.7 KiB
Typst
18 lines
1.7 KiB
Typst
#import "../lib.typ": etal, ie, ART, DEX, APK, SDK, eg
|
|
#import "X_var.typ": *
|
|
|
|
== Introduction
|
|
|
|
In this chapter, we study how Android handles the loading of classes in the case of multiple versions of the same class.
|
|
Such collisions can exist inside the #APK file or between the #APK file and #Asdkc.
|
|
We intend to understand if a reverser would be impacted during a static analysis when dealing with such obfuscated code.
|
|
Because this problem is already complex enough with the current operations performed by Android, we exclude the case where the application uses class loaders dynamically (#eg dynamic code loading).
|
|
We present a new technique that "shadows" a class, #ie embeds a class in the #APK file and "presents" it to the reverser instead of the legitimate version.
|
|
We show how these attacks can confuse the tools of the reverser when he performs a static analysis, and, 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.
|
|
|
|
The chapter is structured as follows.
|
|
@sec:cl-loading investigates the internal mechanisms of class loading and presents how a reverser can be confused by these mechanisms.
|
|
Then, in @sec:cl-obfuscation, we design obfuscation techniques and show their effect on static analysis tools.
|
|
Next, @sec:cl-wild evaluates if these obfuscation techniques are used in the wild by scanning #nbapk APKs.
|
|
@sec:cl-conclusion extends on the possible countermeasures against those shadow attacks, how they interact with other obfuscation techniques, as well as the limitations of this work and avenues left to explore.
|
|
Finally, @sec:cl-conclusion concludes the chapter.
|