What Is App Protection?

This document introduces each concept in plain terms first, then adds more detail below each section. The top of each section is enough on its own.

How Apps Get Analyzed#

When you publish an app to a store, that file ends up installed on phones all over the world. The catch is that this file is just an archive. Anyone with the right skills can unpack it and look inside.

Taking an app apart to figure out how it works is called reverse engineering.

In more detail — the attacker's standard toolchain

• Static analysis — apktool to recover resources and the manifest, dex2jar + jadx/JEB to decompile DEX into Java pseudocode, Ghidra/IDA to disassemble native code (.so).
• Dynamic analysis — Frida/Xposed for runtime hooking on a rooted device or emulator, frida-dexdump/LSPlant to dump the DEX once it's laid out in memory, strace/ltrace to observe syscalls, gdb/lldb for debugging.
• Goals — unlocking paid features, bypassing authentication or payment, extracting secrets (endpoints, API keys), and repackaging (injecting malware and redistributing).

The core premise: the attacker runs the app on a device they control 100%. This single fact determines every limitation of protection (see Is It 100% Safe? below).

The Two Pillars of Protection#

1. Obfuscation — "Hard to Read + Locked"#

Code is scrambled and encrypted so that even when it's pried open, its meaning can't be understood.

• Code locking (packing/encryption) — the core DEX is kept encrypted and only briefly decrypted in memory at runtime. Pry the file open and it stays locked.
• String encryption — the text inside the app (addresses, keys, messages) is hidden behind cipher.
• Native obfuscation — control flow is scrambled all the way down to the machine-code level.

In more detail — Appsolid's implementation goes beyond simple name substitution (the ProGuard style). It is built from full-DEX AES-256-GCM encryption with InMemoryDexClassLoader in-memory loading (no original DEX present on disk), a native bootstrap loader, and multi-layer O-MVLL/O-LLVM obfuscation (control-flow flattening, opaque predicates, indirect-call encryption, MBA). For details: How It Works.

2. RASP — "Watch and Respond at Runtime"#

A capability that lets the app inspect its own surroundings while it runs (Runtime Application Self-Protection).

• Root/emulator — detects an unlocked phone or a fake phone running inside a PC
• Hooking/Frida — detects tools that swap out behavior in real time
• Debugger/tampering — detects line-by-line inspection and file forgery

In more detail — Typical RASP terminates via a branch when it detects a threat. That branch can be neutralized with a patch or a NOP. Appsolid adds key entanglement on top: the detection signal is folded into the decryption-key derivation, so under hooking or debugging the key comes out wrong and decryption itself fails. It's not "detect, then block" — it's "if detected, the code simply doesn't exist."

Is It 100% Safe?#

No client-side protection can ever be 100%. This isn't a limitation unique to Appsolid — it's a mathematical and physical limit shared by every app protection product (DexGuard, Appdome, Promon, and others included). We'll explain it honestly.

Why 100% Is Impossible#

An app ultimately has to run on the user's device. And that device — the very thing being protected — is one the attacker can control 100% (rooting, unlimited time, debuggers, dynamic instrumentation).

The most fundamental reason is an asymmetry of privilege. The protection code runs inside the app, with only the app's ordinary (unprivileged) permissions — there are hard limits to what a single app can do on top of the OS. The attacker, by contrast, holds root (the highest privilege) over the entire device and can observe or manipulate anything: memory, system calls, even the kernel. The side looking down from above always has the advantage, so on the same device it is fundamentally impossible for an unprivileged defense to completely block a privileged attack. That is why the goal is not to "block," but to raise the cost and to detect and respond.

In other words, a professional red team (penetration testers) with enough skill, time, and motivation can eventually observe or bypass some path. The real goal of protection is not "make it unbreakable" but to:

1. Drive up the cost and time of an attack so that most attackers give up, and
2. Detect the few who persist and report them back to us (monitoring) so they can be dealt with.

Therefore — Defense in Depth#

Because any single layer can be breached, protection stacks multiple layers. Breaking one layer leaves the next one standing, and the cost of breaking every layer at once becomes unrealistically high (packing → key entanglement → native loader → RASP → string encryption → monitoring).

String Encryption — "The Last Layer"#

Even if an attacker succeeds in extracting the code, the sensitive strings inside it (server endpoints, API keys, secrets) must not be left in plaintext. String encryption is precisely the last line of defense for that "after another layer has been breached" scenario. Even if the code leaks out, the core secrets are not exposed in plaintext.

Pentest perspective — Even if a red team recovers part of the code, not being able to immediately scoop up plaintext keys and endpoints sharply raises the cost of further analysis again. String encryption is insurance you lay down by "assuming you've already been breached."

⚠️ When Applying String Encryption — A Full Functional Test Is Recommended#

String encryption actually transforms the app's code. It's safe in nearly every case, but because each app's code structure differs, rare side effects on specific screens or features can occur. So when you enable this option, we recommend running through the app's full functionality once.

The problem is that most customer apps require a login, so we can't freely exercise every feature on our own.

We'll help you out — If you provide test login credentials, the Appsolid team will run the protected app across 102 real devices and perform a full functional regression test on your behalf. We support this verification so you can enable string encryption with confidence.

Summary#

You'll find more terms in the Glossary.

Next#

• How It Works · What Sets It Apart — the technical detail of the mechanisms
• Threat Model — what we defend against and what's out of scope
• Getting Started — try applying it yourself