How It Works · What Sets Us Apart

This document explains the internal mechanics of Appsolid protection and how it differs from typical obfuscation and detection products. It is written concretely so that security teams can evaluate it against competing products.

In one line — Most protection schemes "detect a threat, then block it (a branch)." That branch can be turned off by patching or NOPing it. Appsolid "binds the detection signal into the decryption key," so that under hooking or debugging decryption fails and the original code never exists in memory.

Protection Pipeline#

An uploaded app goes through the following.

Input (APK/AAB)
  → Extract original DEX · AES-256-GCM encryption (per-app key)
  → Generate native bootstrap loader (.so) + O-MVLL obfuscation
  → Replace with bootstrap DEX (original is encrypted and stored as an asset)
  → (optional) String encryption / RASP options compiled in
  → zipalign (including 16KB page alignment)
  → Return unsigned artifact (customer re-signs)

1. Key Entanglement — The Biggest Differentiator#

The problem — Detection-only RASP places branches like if (debugger_present) exit;. An attacker overwrites that branch instruction with NOP or inverts the condition to neutralize detection. No matter how sophisticated the detection code is, if a kill switch exists, it can be switched off.

Appsolid's approach — The results of debugger, Frida, and hook detection are used as inputs to the decryption key-derivation function. When the environment is clean, the correct key is derived and the DEX is decrypted and loaded. In a hooked or debugged environment, the key diverges and decryption fails, and the original code is never loaded into memory in the first place.

There is no branch (an if) to switch off. It is not "detect, then block" but "if detected, the code does not exist." The attacker cannot find a target to overwrite with NOPs.

Red-team proof — A build with frida-gadget injected via repackaging self-terminated immediately (a clean build boots normally; adding only the gadget kills it). We confirmed that detection → key corruption → decryption failure → the original DEX never loading works in practice. That said, we honestly disclose the verified ceiling (the structural limit of a high-privilege rooted environment).

2. Per-app Keys#

The problem — With some packers, every protected app shares the same (or a predictable) key and routine. Once one app is analyzed, the decryption method for all customer apps is exposed at once.

Appsolid's approach — A different key is generated for each app and compiled in, split and scattered across the binary. Public NIST test vectors, common keys, and key markers have all been removed. Even if one app is analyzed, that result does not propagate to other apps.

3. Native Bootstrap Loader (.so)#

Core logic such as decryption, DEX injection, and the Application swap has been moved entirely into native code (.so).

• Hides the hook points and technique strings that automatic memory-dump tools (frida-dexdump, etc.) target.
• Minimizes exported symbols to shrink the analysis surface.
• Decryption is performed only at the moment it is needed, and only in memory — no plaintext DEX exists on disk.

4. In-memory-only DEX Loading#

The original DEX is encrypted with AES-256-GCM and stored as an asset, then loaded only in memory at runtime via InMemoryDexClassLoader (legacy RC4 fully removed).

• Even if the file is pried open, the DEX is ciphertext.
• Any attempt to dump memory triggers RASP and key entanglement.

5. O-MVLL / O-LLVM Multi-layer Obfuscation#

The following are layered in the native tier (resistant to automatic deobfuscation tools).

• Control-flow flattening (CFF) — Flattens function flow into a massive branch table.
• Opaque predicates — Inserts branches that are always true/false but cannot be resolved statically.
• Indirect call encryption — Decrypts the call target at runtime.
• MBA (mixed boolean-arithmetic) — Replaces constants and arithmetic with complex identities.
• Full string encryption — Hides native strings.

6. Anti-fingerprinting#

Strings that identify the vendor or technique are removed from the protected artifact. This makes it hard for an attacker to pin down "which protection product this is," delaying the application of known bypass recipes.

Detection-only Approach vs Appsolid#

Stability · Verification#

All of these transformations pass d8 verification + fallback and the ART verifier release gate, and RASP inspects only its own process to rule out false positives. For the actual verification procedures, see Security Verification · Quality.

Next#

• Threat Model — what this mechanism does and does not defend against
• Competitive Comparison — how the approach differs from other products