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

ch4 related soa
All checks were successful
/ test_checkout (push) Successful in 1m21s
Details

Browse source
This commit is contained in:
Jean-Marie Mineau 2025-08-20 22:45:24 +02:00
parent 81f49f87d3
commit 3b9317b3c1
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
5 changed files with 65 additions and 46 deletions
Download patch file Download diff file Expand all files Collapse all files

21
2_background/5_platform_classes.typ Normal file
View file

@ -0,0 +1,21 @@
#import "../lib.typ": SDK, API, API, etal
== Platform Classes <sec:bg-platform>
In addition to the classes they include, Android applications have access to classes provided by Android.
Those classes are called _platform classes_.
They are devided between #SDK classes, and hidden #API.
The #SDK classes can be seen as the Android standard library.
They are documented by Google, and have a certain stability from version to version.
In case of breaking changes, the changed are listed by Google as well.
The list of #SDK classes is available at complite time in the form of a `android.jar` file to link against.
On the opposite, hidden #API are undocumented methods used internally by Android.
Still, they are loaded by the application and can be used by it.
Thus, they are 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.