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

frida
Some checks failed
/ test_checkout (push) Failing after 44s
Details

Browse source
This commit is contained in:
Jean-Marie 'Histausse' Mineau 2025-07-11 19:27:03 +02:00
parent 9e074cf483
commit c272d62903
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
3 changed files with 15 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

2
0_preamble/notations.typ
View file

@ -1,4 +1,5 @@
#let ADB = link(<acr-adb>)[ADB] #let ADB = link(<acr-adb>)[ADB]
#let API = link(<acr-api>)[API]
#let APK = link(<acr-apk>)[APK] #let APK = link(<acr-apk>)[APK]
#let ART = link(<acr-art>)[ART] #let ART = link(<acr-art>)[ART]
#let AXML = link(<acr-axml>)[AXML] #let AXML = link(<acr-axml>)[AXML]
@ -18,6 +19,7 @@
[Acronyms], [Meanings], [Acronyms], [Meanings],
), ),
ADB, [Android Debug Bridge, a tool to connect to an Android emulator of smartphone to run commands, start applications, send events and perform other operations for testing and debuging purpose <acr-adb>], ADB, [Android Debug Bridge, a tool to connect to an Android emulator of smartphone to run commands, start applications, send events and perform other operations for testing and debuging purpose <acr-adb>],
API, [Application Programming Interface, in the Android echosystem, it is a set of classes with known method signatures that can be called by an application to interact with the Android framework <acr-api>],
APK, [Android Package, the file format used to install application on Android. The APK format is an extention of the #JAR format <acr-apk>], APK, [Android Package, the file format used to install application on Android. The APK format is an extention of the #JAR format <acr-apk>],
ART, [Android RunTime, the runtime environement that execute an Android application. The ART is the successor of the older Dalvik Virtual Machine <acr-art>], ART, [Android RunTime, the runtime environement that execute an Android application. The ART is the successor of the older Dalvik Virtual Machine <acr-art>],
AXML, [Android #XML. The specific flavor of #XML used by Android. The main specificity of AXML is that it can be compile in a binary version inside an APK <acr-axml>], AXML, [Android #XML. The specific flavor of #XML used by Android. The main specificity of AXML is that it can be compile in a binary version inside an APK <acr-axml>],

8
2_background/X_android.typ
View file

@ -1,4 +1,4 @@
#import "../lib.typ": todo, APK, JAR, AXML, ART, SDK, JNI, NDK, DEX, XML #import "../lib.typ": todo, APK, JAR, AXML, ART, SDK, JNI, NDK, DEX, XML, API
== Android <sec:bg-android> == Android <sec:bg-android>
@ -76,7 +76,7 @@ The `R.java` file allows the developer to refere to ressources with readable nam
The source code is then compile. The source code is then compile.
The most common programming langages used for Android application are Java and Kotlin. The most common programming langages used for Android application are Java and Kotlin.
Both are first compiled to java bytecode in `.class` files using the langage compiler. Both are first compiled to java bytecode in `.class` files using the langage compiler.
To allow access to the Android API, the `.class` are linked during the compilation to an `android.jar` file that contains classes with the same signatures as the one in the Android API for the targeted SDK. To allow access to the Android #API, the `.class` are linked during the compilation to an `android.jar` file that contains classes with the same signatures as the one in the Android #API for the targeted SDK.
The `.class` files are the converted to #DEX files using `d8`. The `.class` files are the converted to #DEX files using `d8`.
During those steeps, both the original langage compiler and `d8` can perform optimizations on the classes. During those steeps, both the original langage compiler and `d8` can perform optimizations on the classes.
@ -120,9 +120,9 @@ In the course of a componant live cicle, the system will call specifics methods
Those methods are to be overrident by the classes defined in the application if they are specific action to be perfomed. Those methods are to be overrident by the classes defined in the application if they are specific action to be perfomed.
For instance, an activitymight compute some values in `onCreate()`, called when the activity is created, save the value of those variable to the file system in `onStop()`, called when the acitivity stop being visible to the user, and recover the saved values in `onRestart()`, called when the user navigate back to the activity. For instance, an activitymight compute some values in `onCreate()`, called when the activity is created, save the value of those variable to the file system in `onStop()`, called when the acitivity stop being visible to the user, and recover the saved values in `onRestart()`, called when the user navigate back to the activity.
In addition to the componants declared in the manifest that act as entry points, the Android API heavily relies on callbacks. In addition to the componants declared in the manifest that act as entry points, the Android #API heavily relies on callbacks.
The most obvious cases are for the user interface, for example a button will call a callback method defined by the application when clicked. The most obvious cases are for the user interface, for example a button will call a callback method defined by the application when clicked.
Other part of the API also rely on non-linear execution, for example when an application send an itent (see @sec:bg-sandbox), the intent sent in responce is transmitted to back to the application by calling another method. Other part of the #API also rely on non-linear execution, for example when an application send an itent (see @sec:bg-sandbox), the intent sent in responce is transmitted to back to the application by calling another method.
==== Application Isolation and Interprocess Communication <sec:bg-sandbox> ==== Application Isolation and Interprocess Communication <sec:bg-sandbox>

11
2_background/X_tools.typ
View file

@ -1,4 +1,4 @@
#import "../lib.typ": todo, APK, IDE, SDK, DEX, ADB, ART, eg, XML, AXML #import "../lib.typ": todo, APK, IDE, SDK, DEX, ADB, ART, eg, XML, AXML, API
== Android Reverse Engineering Tools <sec:bg-tools> == Android Reverse Engineering Tools <sec:bg-tools>
@ -69,6 +69,13 @@ Compared to Soot, it has a modernize interface and architecture, but it is not y
=== Frida <sec:bg-frida> === Frida <sec:bg-frida>
Fidra#footnote[https://frida.re/] is a dynamic intrumentation toolki. Fidra#footnote[https://frida.re/] is a dynamic intrumentation toolkit.
It allows the reverse engineer to inject and run javascript code inside a running application.
To instrument an application, the frida server must be running as root on the phone, or the frida librairy must be injected inside the #APK file before installing it.
Frida defines a javascript wrapper arround the Java Native Interface (JNI) used by native code to interact with Java classes and the Android i#API.
In addition to allowing interaction with Java objects from the application and the Android API, this wrapper provide the option to replace a method implementation by a javascript function (that itself can call the original method implementation if needed).
This make Frida a powerfull tool capable of collecting runtime informations or modifying the behavior of an application as needed.
The main drawback of using Frida is that it is a known tools easily detected by applications.
Malware might implement countermeasures that avoid running malicious payload in presence of Frida.