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

integrate bg of rasta in bg section
All checks were successful
/ test_checkout (push) Successful in 1m15s
Details

Browse source
This commit is contained in:
Jean-Marie Mineau 2025-08-12 18:43:28 +02:00
parent 94d26973d3
commit 5e512b585a
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
11 changed files with 170 additions and 107 deletions
Download patch file Download diff file Expand all files Collapse all files

34
2_background/X_dynamic_analysis.typ Normal file
View file

@ -0,0 +1,34 @@
#import "../lib.typ": todo, APK, etal, ART, SDK, eg, jm-note, jfl-note
#import "@preview/diagraph:0.3.3": raw-render
=== Dynamic Analysis <sec:bg-dynamic>
#todo[include properly]
The alternative to static analysis is dynamic analysis.
With dynamic analysis, the application is actually executed.
The most simple strategies consist in just running the application and examining its behavior.
For instance, Bernardi #etal~@bernardi_dynamic_2019 use the log generated by `strace` to list the system calls generated in responce to an event to determine if an application is malicious.
More advanced methods are more intrusive and require modifing either the #APK, the Android framework, runtime, or kernel.
TaintDroid~@Enck2010 for example modify the Dalvik Virtual Machine (the predecessor of the #ART) to track the data flow of an application at runtime, while AndroBlare~@Andriatsimandefitra2012 @andriatsimandefitra_detection_2015 try to compute the taint flow by hooking system calls using a Linux Security Module.
DexHunter~@zhang2015dexhunter and AppSpear~@yang_appspear_2015 also patch the Dalvik Virtual Machine/#ART, this time to collect bytecode loaded dynamically.
Modifying the Android framwork, runtime or kernel is possible thanks to the Android project beeing opensource, however this is delicate operation.
Thus, a common issue faced by tools that took this approach is that they are stuck with a specific version of Android.
Some sandboxes limit this issue by using dynamic binary instrumentation, like DroidHook~@cui_droidhook_2023, based the Xposed framework, or CamoDroid~@faghihi_camodroid_2022, based on Frida.
Another known challenge when analysing an application dynamically is the code coverage: if some part of the application is not executed, it cannot be annalysed.
Considering that Android applications are meant to interact with a user, this can become problematic for automatic analysis.
The Monkey tool developed by Google is one of the most used solution~@sutter_dynamic_2024.
It sends a random streams of events the phone without tracking the state of the application.
More advance tools statically analyse the application to model in order to improve the exploration.
Sapienz~@mao_sapienz_2016 and Stoat~@su_guided_2017 uses this technique to improve application testing.
GroddDroid~@abraham_grodddroid_2015 has the same approach but detect statically suspicious sections of code to target, and will interact with the application to target those code section.
Unfortuntely, exploring the application entirely is not always possible, as some applications will try to detect is they are in a sandbox environnement (#eg if they are in an emmulator, or if Frida is present in memory) and will refuse to run some sections of code if this is the case.
Ruggia #etal~@ruggia_unmasking_2024 make a list of evasion techniques.
They propose a new sandbox, DroidDungeon, that contrary to other sandboxes like DroidScope@droidscope180237 or CopperDroid@Tam2015, strongly emphasizes on resiliance against evasion mechanism.
#todo[RealDroid sandbox bases on modified ART?]
#todo[force execution?]
#todo[DyDroid, audit of Dynamic Code Loading~@qu_dydroid_2017]