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

wip
All checks were successful
/ test_checkout (push) Successful in 1m53s
Details

Browse source
This commit is contained in:
Jean-Marie Mineau 2025-09-30 20:50:14 +02:00
parent 072c4f48c4
commit 346151125e
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
6 changed files with 21 additions and 16 deletions
Download patch file Download diff file Expand all files Collapse all files

2
2_background/3_problem_statements.typ
View file

@ -30,7 +30,7 @@ In a way, reflection can do the same thing, but for specific method calls: inste
By contrast, it is relatively easy to find the name of the method called or to intercept dynamically loaded bytecode using dynamic tools like Frida.
The issue that arises then is what to do with the collected data.
Simply having it greatly helps a manual analysis, but it cannot be used directly by tools that perform static analyses.
There is no standard representation for runtime information, and there is simply no way to give a list of reflection sites and the associated method calls for most tools.
There is no standard representation for runtime information, and there is simply no way to give a list of reflection sites and the associated method calls as a new input for most static analysis tools.
This means that in most cases, when a reverse engineer wants to improve static analysis with dynamic analysis, they need to modify the static tools to receive the additional runtime data.
Doing so requires both time and knowledge of the internals of the tools used.
Our third problem statement, #pb3, explores an alternative approach that modifies the application instead of the tool: #pb3-text