Protection
Defence, compiled in.
An attacker works on the binary you shipped, on a device you do not control. So the defence has to travel with the binary and run where the attack runs.
01 — What we defend against
Seven classes of attack, seven approaches.
Each layer is compiled into the build. There is no runtime SDK to initialise, and nothing for a developer to remember to call.
Repackaging and tampering
the shipped binary
the app verifies itself at runtime and refuses patched builds
Debugging
debugger and ptrace attach
blocked in the native layer
Hooking and instrumentation
injection at runtime
inline and PLT hook detection from compiled native code
Compromised environments
root, stealth root, emulators
layered heuristics and environment fingerprinting
Static reverse engineering
the package at rest
payload protected at rest, resolved only in memory
Native-layer analysis
compiled code, every ABI
control-flow and arithmetic obfuscation
Memory extraction
the live process
anti-extraction enforcement against dumping
Key custody
your signing keys
envelope-encrypted per tenant, signed outputs, keys never leave the vault
02 — Telemetry
You see the attack while it happens.
A protected build reports what it detected, when, and on what kind of device. Events are signed and append-only, so the record can be trusted after the fact. No raw personal data is stored.
00
raw personal data stored
100
% of events signed
09
defence layers per build
04
Android ABIs hardened
Scope
Android, and only what we are authorized to touch.
The protection product targets Android. Every validation we run is restricted to applications we own, infrastructure we own, and lab devices we are authorized to use. No third-party targets are in scope, on any engagement.