This commit is contained in:
parent
ca4e7703e1
commit
5497988199
3 changed files with 15 additions and 15 deletions
|
|
@ -45,10 +45,10 @@ 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.
|
||||
In practice, there is not a lot of reason to do such a thing.
|
||||
In practice, there is not a lot of reasons 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.
|
||||
In any case, statically, because we remove neither the calls to the function that load the classes (like `ClassLoader.loadClass(..)`) nor the `try` / `catch` blocks, static analysis tools that can handle the original behaviour should still be able to access the old behaviour.
|
||||
In any case, because we remove neither the calls to the function that load the classes (like `ClassLoader.loadClass(..)`) nor the `try` / `catch` blocks, static analysis tools that can handle the original behaviour should still be able to access the old behaviour.
|
||||
]
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue