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

in the end I ingored a lot of feedbacks, sory jfl
All checks were successful
/ test_checkout (push) Successful in 1m52s
Details

Browse source
This commit is contained in:
Jean-Marie 'Histausse' Mineau 2025-09-30 23:40:43 +02:00
parent 346151125e
commit a3fcff0c19
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
3 changed files with 25 additions and 20 deletions
Download patch file Download diff file Expand all files Collapse all files

7
2_background/4_3_theseus.typ
View file

@ -13,8 +13,9 @@ After that, we will also look at contributions that sought to encode results ins
Some situations, like reflection of dynamic code loading, are difficult to solve with static analysis and require a different approach: dynamic analysis.
With dynamic analysis, the application is actually executed, and the reverse engineer observes its behaviour.
Monitoring the behaviour can be achieved by various strategies: observing the filesystem, the display screen, the process memory, the kernel, ...
Depending on the chosen level of observation, it can be technically difficult.
Monitoring the behaviour can be achieved by various strategies: observing the filesystem, the display screen, the process memory, the kernel, etc.
Depending on the chosen level of observation, dynamic analysis can become a serious technical challenge.
A basic example of dynamic analysis is presented by Bernardi #etal~@bernardi_dynamic_2019: the logs generated by `strace` are used to list the system calls generated in response to an event to determine if an application is malicious or not.
More advanced methods are more intrusive and require modifying either the #APK, the Android framework, runtime, or kernel.
@ -49,7 +50,7 @@ For instance, StaDynA only provide the call graph, and cannot be used as is to i
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.
We will now explore further the contributions that take this approach of using actual applications to encode their results.
We will now explore further the contributions that take this approach to encode results inside applications.
//#todo[RealDroid sandbox bases on modified ART?]
//#todo[force execution?]