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

fix typos up to ch 3
All checks were successful
/ test_checkout (push) Successful in 50s
Details

Browse source
This commit is contained in:
Jean-Marie 'Histausse' Mineau 2025-12-21 13:37:29 +01:00
parent d34e403ca5
commit 3b5df50248
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
16 changed files with 1629 additions and 248 deletions
Download patch file Download diff file Expand all files Collapse all files

4
2_background/4_3_theseus.typ
View file

@ -46,7 +46,7 @@ It resulted that dynamic code loading was mostly related to mobile advertisement
Similarly, StaDynA~@zhauniarovichStaDynAAddressingProblem2015 is a framework that generates a call graph statically, then uses dynamic analysis to analyse dynamic code loading and reflection calls to complete this call graph.
The issue with those approaches is that they are only compatible with their own subsequent analysis.
For instance, StaDynA only provide the call graph, and cannot be used as is to improve the capacity of Flowdroid.
For instance, StaDynA only provides the call graph, and cannot be used as is to improve the capacity of Flowdroid.
This is unfortunate: the reverse engineer's next step will depend on the context.
Not being able to reuse the result of a previous analysis with any ad hoc tools greatly limits their options.
AppSpear has an interesting solution to this issue: the code it intercepts is repackaged inside a new #APK file that Android analysis tools should be able to analyse.
@ -74,7 +74,7 @@ Samhi #etal~@samhi_jucify_2022 followed this direction to unify the analysis of
Their tool, JuCify, uses Angr~@angrPeople to generate the call graph of the native code, and uses heuristics to encode this call graph into Jimple that can then be added to the Jimple generated by Soot from the bytecode of the application.
Like IccTa, they use Flowdroid to analyse this new augmented representation of the application, but it should be usable by any analysis tools relying on Soot.
Finally, DroidRA~@li_droidra_2016 use the COAL~@octeauCompositeConstantPropagation2015 solver to statically compute the reflection information.
Finally, DroidRA~@li_droidra_2016 uses the COAL~@octeauCompositeConstantPropagation2015 solver to statically compute the reflection information.
The reflection calls are transformed into direct calls inside the application using Soot.
Using COAL makes DroidRA quite good at solving the simpler cases, where the names of classes and methods targeted by reflection are already present in the application.
Those cases are quite common; being able to solve those without resorting to dynamic analysis is quite useful.