34 lines
3.1 KiB
Typst
34 lines
3.1 KiB
Typst
#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]
|