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

pass chapter 5
Some checks failed
/ test_checkout (push) Failing after 21s
Details

Browse source
This commit is contained in:
Jean-Marie 'Histausse' Mineau 2025-09-30 03:05:07 +02:00
parent f309dd55b8
commit d7df45b206
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
8 changed files with 64 additions and 56 deletions
Download patch file Download diff file Expand all files Collapse all files

8
5_theseus/6_limits.typ
View file

@ -9,7 +9,9 @@ In this section, we will present those issues and potential avenues of improveme
=== Bytecode Transformation
#paragraph[Custom Class Loaders][
The first obvious limitation of our bytecode transformation is that we do not know what custom class loaders do, so we cannot accurately reproduce statically their behaviour.
The first obvious limitation of our bytecode transformation is that we do not know what custom class loaders (class loaders implemented by the application developer, as opposed to the class loaders in the #SDK) do, so we cannot accurately reproduce statically their behaviour.
For instance, we can imagine a class loader that loads all classes whose name starts with an `A` from one #DEX file, and all classes whose name starts with a `B` from another.
If both #DEX files have colliding classes, our implementation will not select the right classes.
We elected to fallback to the behaviour of the `BaseDexClassLoader`, which is the highest Android-specific class loader in the inheritance hierarchy, and whose behaviour is shared by all class loaders except `DelegateLastClassLoader`.
The current implementation of the #ART enforces some restrictions on the class loader's behaviour to optimise the runtime performance by caching classes.
This gives us some guarantees that custom class loaders will keep some coherence with the classic class loaders.
@ -42,7 +44,7 @@ This leads to potential invalid runtime behaviour, as the first method that matc
#paragraph[`ClassNotFoundException` may not be raised][
In the very specific situation where the original application tries to access a class from dynamically loaded bytecode without actually accessing this bytecode (#eg by using the wrong class loader), the patched application behaviour will differ.
The original application should raise a `ClassNotFoundException`, but in the patched application, the class will be accessible and the exception will not be raised.
The original application should raise a `ClassNotFoundException`, but in the patched application, the class will be accessible, and the exception will not be raised.
In practice, there is not a lot of reason to do such a thing.
One could be to check if the #APK has been tampered with, but there are easier ways to do this, like checking the application signature.
Another would be to check if the class is already available, and if not, load it dynamically, in which case it does not matter, as code loaded dynamically is already present.
@ -55,7 +57,7 @@ In any case, statically, because we remove neither the calls to the function tha
#paragraph[Anti Evasion][
Our dynamic analysis does not perform any kind of anti-evasive technique.
Any application implementing even basic evasion will detect our environment and will probably not load malicious bytecode.
Running the dynamic analysis in an appropriate sandbox such as DroidDungeon should improve the results significantly.
Running the dynamic analysis in an appropriate sandbox, such as DroidDungeon~@ruggia_unmasking_2024, should improve the results significantly.
]
#paragraph[Code Coverage][