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

in the end I ingored a lot of feedbacks, sory jfl
All checks were successful
/ test_checkout (push) Successful in 1m52s
Details

Browse source
This commit is contained in:
Jean-Marie 'Histausse' Mineau 2025-09-30 23:40:43 +02:00
parent 346151125e
commit a3fcff0c19
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
3 changed files with 25 additions and 20 deletions
Download patch file Download diff file Expand all files Collapse all files

12
2_background/4_2_classloader.typ
View file

@ -1,4 +1,4 @@
#import "../lib.typ": SDK, API, API, DEX, pb2, pb2-text, etal, APIs
#import "../lib.typ": SDK, API, API, DEX, pb2, pb2-text, etal, APIs, ie
#import "../lib.typ": todo
=== Android Class Loading <sec:bg-soa-cl>
@ -6,9 +6,9 @@
#pb2-text
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.
Because we focus on the _default_ class loading algorithm, we will not focus on dynamic code loading (#ie loading of additional bytecode while the application is already running).
However, class loading is used, without dynamic code loading, to load classes other than the one in the application: the platform classes.
In the second part of this subsection, we will look at the work that has been done related to those platform classes.
==== Class Loading <sec:bg-cl>
@ -45,15 +45,17 @@ Platform classes are divided between #SDK classes that are documented, and the o
#SDK classes are clearly listed and documented by Google, so they do not require as much attention as hidden #APIs.
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 of 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 #APIs for a reverse engineer.
#v(2em)
Class loading mechanisms have been studied carefully in the context of the Java language.
In conclusion, class loading mechanisms have been studied carefully in the context of the Java language.
However, the same cannot be said about Android, whose implementation diverges significantly from classic Java Virtual Machines.
Most work done on Android focuses on extending Android capabilities using class loading, or on analysing dynamically the code loading operations of an application.