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

erf, not good, but it's something at least
All checks were successful
/ test_checkout (push) Successful in 1m47s
Details

Browse source
This commit is contained in:
Jean-Marie 'Histausse' Mineau 2025-09-25 16:49:27 +02:00
parent c34eb1b838
commit fede0bd9b2
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
5 changed files with 42 additions and 36 deletions
Download patch file Download diff file Expand all files Collapse all files

46
2_background/4_2_classloader.typ
View file

@ -1,23 +1,17 @@
#import "../lib.typ": SDK, API, API, DEX, pb2, pb2-text, etal
#import "../lib.typ": todo
== Android Class Loading <sec:bg-soa-cl>
=== Android Class Loading <sec:bg-soa-cl>
#todo[Refactor]
#pb2-text
=== Platform Classes <sec:bg-soa-platform>
This subsection is mainly dedicated to class loading in Java and Android.
Because we focus on the _default_ class loading algorithm, we will not focus on dynamic code loading.
However, class loading is used to load classes other than the one in the application, without dynamic code loading.
In the second part of this subsection we will look at the work that has been done related to those classes, the platform classes.
As we said earlier, hidden #API are undocumented methods that can be used by an application, thus making them a potential blind spot when analysing an application.
However, not a lot a research has been done on the subject.
Li #etal did an empirical study of the usage and evolution of hidden #API~@li_accessing_2016.
They found that hidden #API are added and removed in every release of Android, and that they are used both by benign and malicious applications.
More recently, He #etal~@he_systematic_2023 did a systematic study of hidden service #API related to security.
They studied how the hidden #API can be used to bypass Android security restrictions and found that although Google countermeasures are effective, they need to be implemented inside the system services and not the hidden #API due to the lack of in-app privilege isolation: the framework code is in the same process as the user code, meaning any restriction in the framework can be bypassed by the user.
Unfortunately those two contributions do not explore further the consequences of the use of hidden #API for a reverse engineer.
==== Class Loading <sec:bg-cl>
=== Class Loading <sec:bg-cl>
Another rarely considered element of Android is its class loading mechanism.
Class loading is a fundamental element of Java, it define which classes are loaded from where.
In Android, this is often associated to dynamic code loading, as the `ClassLoader` objects are used to load code at runtime.
However, class loading also intervenes to load platform classes or classes from the application itself, and thus require some attention when analysing an application.
@ -41,17 +35,27 @@ They also combine the loading with code generation from ciphered assets or 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.
Those contributions interact with the class loading mechanism of Android to collect the #DEX structures at the right moment.
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.
Some classes however are not load from the application, nor dynamically load by the application.
Those classes are platform classes, and appart from dynamic code loaded, they are the main reason class loading is needed by Android.
We will now look at the literature related to them.
==== Platform Classes <sec:bg-soa-platform>
Platform classes are divided between #SDK classes that are documented, and the other classes, often refered to as hidden #API.
#SDK classes are clearly listed and documented by Google, so they do not require as much attention as hidden #API.
As we said earlier, hidden #API are undocumented methods that can be used by an application, thus making them a potential blind spot when analysing an application.
However, not a lot a research has been done on the subject.
Li #etal did an empirical study of the usage and evolution of hidden #API~@li_accessing_2016.
They found that hidden #API are added and removed in every release of Android, and that they are used both by benign and malicious applications.
More recently, He #etal~@he_systematic_2023 did a systematic study of hidden service #API related to security.
They studied how the hidden #API can be used to bypass Android security restrictions and found that although Google countermeasures are effective, they need to be implemented inside the system services and not the hidden #API due to the lack of in-app privilege isolation: the framework code is in the same process as the user code, meaning any restriction in the framework can be bypassed by the user.
Unfortunately those two contributions do not explore further the consequences of the use of hidden #API for a reverse engineer.
#v(2em)
Class loading mechanisms have been studies carefully in the context of the Java language.
However, the same cannot be said about Android, whose implementation significantly from classic Java Virtual Machine.
However, the same cannot be said about Android, whose implementation diverge significantly from classic Java Virtual Machine.
Most work done on Android focus on extending Android capabilities using class loading, or on analysing dynamically the code loading operations of an application.
This leaves open the question of the actual default class loading behavior of Android, leading us to #pb2:
#pb2-text
In @sec:cl, we will model the behaviour of Android when loaded classes used by an application that do not use dynamic code loading, and check if this behaviour mach the behaviour of common analysis tools.
We will also take some times to if the state of the art related to hidden #API is up to date with the current Android versions.