Spaces:
Sleeping
Dynamic (Behavioral Sandbox) Analysis: What It Is and Its Default State
What this means for you
Static analysis (see static-analysis-guide.md) reads an app without running it. Dynamic analysis is the opposite idea: actually running the app in a controlled, isolated environment (a "sandbox") and observing what it does in real time — what network connections it opens, what permissions it actually exercises, what files it touches. In principle, this can catch malicious behavior that only shows up at runtime and wouldn't be visible from the manifest or code alone.
The important thing to understand plainly: in this deployment, dynamic analysis defaults to a mocked, non-live mode. It exists as a subsystem in Shield's architecture, but out of the box it is not actually executing apps in a real sandbox. If Shield tells you a result involved dynamic analysis, you should understand that by default this means a mock or simulated pass, not a live behavioral observation, unless the deployment has been specifically configured otherwise.
The three modes, explained honestly
Shield's dynamic-analysis subsystem supports a few distinct modes, controlled by configuration (DYNAMIC_SANDBOX_BACKEND, DYNAMIC_ANALYSIS_ENABLED):
Mock mode (the default) — DYNAMIC_SANDBOX_BACKEND=mock and DYNAMIC_ANALYSIS_ENABLED=false out of the box. In this mode, no app is actually executed anywhere. The "dynamic analysis" step either returns placeholder results or is skipped entirely, and Shield's risk verdict relies on the other engines (static analysis, YARA/APKiD, ML, certificate checks) instead. This is the realistic default state for most deployments.
Simulated mode — an intermediate option where Shield infers plausible dynamic behavior by reasoning over the static-analysis results, rather than by actually running the app. For example, if an app declares SMS-read permission and Accessibility Service usage, a simulated pass might project what that combination would likely mean in terms of behavior. This is useful for testing the pipeline and for producing more informative explanations, but it is not observed behavior — it's an inference layered on top of static findings, and should not be mistaken for empirical evidence that the app actually did those things.
Real sandbox mode (optional, self-hosted) — Shield's architecture allows dynamic analysis to be pointed at an actual self-hosted sandbox built on MobSF (Mobile Security Framework) combined with Frida (a dynamic instrumentation toolkit), which can genuinely install and run the APK in isolation and observe its real runtime behavior — network calls, API usage, permission exercising, and so on. This is the only mode that reflects true, live behavioral observation. It requires the operator to stand up and configure that sandbox infrastructure separately; it is not the default state of the system.
Why this distinction matters for trust
Security tools are most useful when users understand exactly what evidence backs a given verdict. If Shield's overall risk score for an app is high or critical, that confidence is coming from static analysis, YARA/APKiD pattern matching, the ML classifier, and certificate/impersonation checks (see the other guides in this knowledge base) — engines that are genuinely active by default. Dynamic analysis, when it contributes at all in a default deployment, is contributing mocked or simulated signal rather than a live observed execution trace. This isn't a weakness unique to Shield — building and safely operating a live Android sandbox is a substantial engineering undertaking — but it's important not to overstate what "dynamic analysis" means unless a deployment has specifically enabled the real MobSF+Frida backend.
How it fits with the rest of the pipeline
When dynamic analysis does produce real or simulated output, it's folded into the same risk-fusion process described in risk-score-guide.md, alongside static analysis, pattern-matching, and the ML classifier. It is never the sole basis for a verdict.