normalization and move french to the end
All checks were successful
/ test_checkout (push) Successful in 1m51s

This commit is contained in:
Jean-Marie 'Histausse' Mineau 2025-09-29 20:15:36 +02:00
parent 4e38131df5
commit c3a27f8711
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
7 changed files with 57 additions and 53 deletions

View file

@ -14,7 +14,7 @@ We discuss this option in @sec:th-grod.
=== Collecting Bytecode Dynamically Loaded <sec:th-fr-dcl>
Initially, we considered instrumenting the constructor methods of the classloaders of the Android #SDK.
Initially, we considered instrumenting the constructor methods of the class loaders of the Android #SDK.
However, this is a significant number of methods to instrument, and looking at older applications, we realised that we missed the `DexFile` class.
`DexFile` is now deprecated but still usable class that can be used to load bytecode dynamically.
We initially missed this class because it is neither a `ClassLoader` class nor an #SDK class (anymore).
@ -24,7 +24,7 @@ As a reference, in 2015, DexHunter~@zhang2015dexhunter already noticed `DexFile.
`DefineClass(..)` is still a good function to instrument, but it is a C++ native method that does not have a Java interface, making it harder to work with using Frida, and we want to avoid patching the source code of the #ART like DexHunter did.
For this reason, we decided to hook `DexFile.openInMemoryDexFilesNative(..)` and `DexFile.openDexFileNative(..)` instead.
Those methods take as argument a list of Android code files, either in the form of in-memory byte arrays or file paths, and a reference to the classloader associated with the code.
Instrumenting those methods allows us to collect all the code files loaded by the #ART and associate them with their classloaders.
Instrumenting those methods allows us to collect all the code files loaded by the #ART and associate them with their class loaders.
=== Collecting Reflection Data <sec:th-fr-ref>