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

update to last revision

Browse source
This commit is contained in:
Jean-Marie 'Histausse' Mineau 2025-07-15 23:36:21 +02:00
parent c272d62903
commit c64bff722b
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
3 changed files with 66 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

11
4_class_loader/1_related_work.typ
View file

@ -1,4 +1,4 @@
#import "../lib.typ": etal, paragraph
#import "../lib.typ": etal, paragraph, DEX
#import "X_var.typ": *
== State of the art <sec:cl-soa>
@ -23,7 +23,14 @@ 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).
In the first phase of an analysis where the used methods are static, the reverser can have the feeling that what he sees in the bytecode is what is loaded at runtime.
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.
]