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

add collision resolution
Some checks failed
/ test_checkout (push) Failing after 38s
Details

Browse source
This commit is contained in:
Jean-Marie Mineau 2025-07-04 17:58:57 +02:00
parent 37492d223d
commit caa1e005e4
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
3 changed files with 52 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

26
5_theseus/1_static_transformation.typ
View file

@ -1,5 +1,11 @@
#import "../lib.typ": todo, APK, DEX, JAR, OAT, eg
/*
* Parler de dex lego et du papier qui encode les resultats d'anger en jimple
*
*
*/
== Code Transformation <sec:th-trans>
#todo[Define code loading and reflection somewhere]
@ -129,8 +135,6 @@ In those cases, the parameters could be used directly whithout the detour inside
=== Code loading <sec:th-trans-cl>
#todo[custom class loaders]
An application can dynamically import code from several format like #DEX, #APK, #JAR or #OAT, either stored in memory or in a file.
Because it is an internal, platform dependant format, we elected to ignore the #OAT format.
Practically, #JAR and #APK files are zip files containing #DEX files.
@ -148,6 +152,24 @@ Specifically, to call dynamically loaded code, an application needs to use refle
=== Class Collisions <sec:th-class-collision>
We saw in @sec:cl-obfuscation that having several classes with the same name in the same application can be problematic.
In @sec:th-trans-cl, we are adding code from another source.
By doing so, we augment the probability of having class collisions.
When loaded dynamically, the classes are in a different classloader, and the class resolution is resolved at runtime like we saw in @sec:cl-loading.
We decided to restrain our scope to the use of class loader from the Android SDK.
In the abscence of class collision, those class loader behave seamlessly and adding the classes to application maintains the behavior.
When we detect a collision, we rename one of the classes colliding before injecting it to the application.
To avoid breaking the application, we then need to rename all references to this specific class, an be carefull not to modify references to the other class.
To do so, we regroup each classes by the classloaders defining them, then, for each colliding class name and each classloader, we check the actual class used by the classloader.
If the class has been renamed, we rename all reference to this class in the classes defined by this classloader.
To find the class used by a classloader, we reproduce the behavior of the different classloaders of the Android SDK.
This is an important step: remember that the delegation process can lead to situation where the class defined by a classloader is not the class that will be loaded when querying the classloader.
#todo[renamin algo]
=== Pitfalls
#todo[interupting try blocks: catch block might expect temporary registers to still stored the saved value]
#todo[diferenciating the classloaders]
#todo[changing classloader with class collision]