Threat Model
Any security assessment begins with "what are we defending against, and what attacker do we assume?" This page honestly states what Appsolid defends and what falls outside that scope. We do not overstate our claims.
Assumed Attacker#
Appsolid is designed assuming an attacker with the following capabilities.
| Capability | Description |
|---|---|
| Full device control | Rooting, custom ROMs, SELinux permissive |
| Static analysis | Decompiling the APK/.so with apktool, jadx, Ghidra, IDA |
| Dynamic instrumentation | Frida, Xposed, frida-dexdump, gdb |
| Time and repetition | Running at scale and repeatedly on emulators |
| Repackaging | Tampering, then re-signing and redistributing |
In short, we assume an attacker at the level of a penetration test (red team).
In Scope#
| Threat | Countermeasure |
|---|---|
| Static code analysis and decompilation | DEX encryption, in-memory loading, native loader, O-MVLL |
| Memory dumping (frida-dexdump, etc.) | Key entanglement (not assembled when hooked) + RASP |
| Dynamic hooking (Frida/Xposed) | Hook detection + key entanglement |
| Debugging | anti-debug + timing checks + key entanglement |
| Execution on rooted devices and emulators | Detection followed by safe termination |
| App tampering and repackaging | Integrity verification (APK) |
| Secret string extraction | String encryption |
| Lack of attack visibility | Real-time threat monitoring |
Out of Scope#
Honestly, these are the areas Appsolid cannot block on its own.
- Server-side vulnerabilities — Flaws in API authentication, authorization, and business logic belong to server security, not app protection. (App protection only guards the secrets contained in the client; it cannot fix a poorly designed API.)
- High-privilege local analysis (rooted device) — a structural limitation shared by every client-side protection. Static analysis, non-root dynamic instrumentation, and non-root repackaging are all blocked and responded to; but because code must ultimately exist in memory at some point in order to execute, an attacker with full control of the device may, under limited conditions, observe code while it runs. The background is covered under structural limitation. The goal is to raise this cost high enough, and to detect and respond to attempts.
- Social engineering and phishing — Attacks that trick users into surrendering their credentials fall outside the scope of code protection.
- OS/hardware 0-days — Undisclosed vulnerabilities in the platform itself.
- Legitimate key holders — Insiders who hold a valid signing key.
Stating these limits explicitly is itself a basis for trust. The claim "we block everything 100%" does not hold up technically.
Protection Philosophy — Cost, Time, Visibility#
Goal = attack cost ↑ + attack time ↑ + attack visibility ↑
- Cost and time — Multiple layers of protection (defense in depth) make breaking through all of them simultaneously impractical.
- Visibility — The few who keep trying to the end are detected and reported via monitoring so you can respond.
Next#
- How It Works — the mechanism behind each defense
- Security Assurance · Quality — how we verified that the defenses actually work