these-ammii/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 1m21s
Details

Browse source
This commit is contained in:
Jean-Marie Mineau 2025-08-21 23:39:53 +02:00
parent 3b9317b3c1
commit 99112355d4
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
1 changed files with 19 additions and 10 deletions
Download patch file Download diff file Expand all files Collapse all files

29
2_background/X_dynamic_analysis.typ
View file

@ -2,19 +2,20 @@
== 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.
As we said previously, static analysis is not capable of analysing everything.
Some situation, like reflection of dynamic code loading, require a different approach: dynamic analysis.
With dynamic analysis, the application is actually executed and the reverse engineer obserces its behavior.
Monitoring the behavior 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.
A basic example of dynamic analysis is presented by Bernardi #etal~@bernardi_dynamic_2019: the logs generated by `strace` is 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 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.
Modifying the Android framwork, runtime or kernel is possible thanks to the Android project beeing open source, however this is a delicate operation that require to revise a patch for each new version of Android.
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.
This approche is a lot less stealthy than patching Android, but is generally easier to setup and is easier to port to new Android version.
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.
@ -28,6 +29,14 @@ Unfortuntely, exploring the application entirely is not always possible, as some
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]
A common objectif of dynamic analysis is to collect bytecode loaded dynamically #jm-note[and reflections information.][check?].
Like we said earlier, DexHunter~@zhang2015dexhunter and AppSpear~@yang_appspear_2015 that by instrumenting the Android Runtime.
Qu #etal~@qu_dydroid_2017 developped DyDroid, an hybrid framework using dynamic analysis to intercept dynamic code loading and static analysis to determine the nature of the loaded code.
They used DyDroid to make an autid of the use of dynamic code loading in applications from the Google Play store in 2016.
They found that it was mostly related to mobile advertisement, and that the code loading originated from a third party library included in the application, rather than the code of the application developper itself.
#todo[DCL and reflection, then segway to hybride an limite ]
//#todo[RealDroid sandbox bases on modified ART?]
//#todo[force execution?]
#todo[Positionnement]