these-ammii/thesis
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

wip
All checks were successful
/ test_checkout (push) Successful in 1m21s
Details

Browse source
This commit is contained in:
Jean-Marie Mineau 2025-08-19 23:27:25 +02:00
parent 5a71a9d5dd
commit 81f49f87d3
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
16 changed files with 267 additions and 202 deletions
Download patch file Download diff file Expand all files Collapse all files

18
4_class_loader/6_conclusion.typ
View file

@ -1,16 +1,24 @@
#import "../lib.typ": SDK, pb2, pb2-text, highlight-block, ie
#import "X_var.typ": *
== Conclusion <sec:cl-conclusion>
This paper has presented three shadow attacks that allow malware developers to fool static analysis tools when reversing an Android application.
This chapter has presented three shadow attacks that allow malware developers to fool static analysis tools when reversing an Android application.
By including multiple classes with the same name or by using the same name as a class of the #Asdk, the developer can mislead a reverser or impact the result of a flow analysis, such as the ones of Androguard or Flowdroid.
We explored if such shadow attacks are present in as dataset of #nbapk applications .
We found that on average, #shadowsdk of applications are shadowing the SDK, mainly for retro-compatibility purposes and library embedding.
We found that on average, #shadowsdk of applications are shadowing the #SDK, mainly for retro-compatibility purposes and library embedding.
More suspiciously, #shadowhidden of applications are shadowing a hidden class, which could lead to unexpected execution as these classes can appear/disappear with the evolution of Android internals.
Investigations for applications that defined classes multiple times suggest that the compilation process or the inclusion of different versions of the same library is the main explanation.
Finally, when investigating malware samples, we found a specific sample containing a shadow attack that would hide a part of the critical code from a reverser studying the application.
Future work concerns the correctness of bytecode analysis.
For now, we rely on the Smali representation of the bytecode but the compilation process makes this comparison difficult.
We intend to better parse the bytecode to summarize it and be able to have a more reliable comparison method.
#v(1.5em)
#align(center, highlight-block(inset: 15pt, width: 75%, breakable: false, block(align(left)[
#pb2: #pb2-text
#v(0.75em)
@lst:cl-loading-alg model the class loading algorithm: platform classes have priority over classes stored in `classes.dex` which have priority over `classes<n>.dex` (where $n in [| 2, +infinity [| $ and $forall i in [| 2, n [|, exists $ `classes<i>.dex`) which has priority over `classes<n+1>.dex`.
Failing to implement this model (#ie by ignoring some platform classes or by sorting the `classes<n>.dex` alphabetically instead of numerically) can cause static analysis tools to compute an incorrect representation of the analyzed application.
])))