Topic starter
06/09/2026 3:44 pm
TL;DR: Application binaries expose keys, trust logic, and API behaviour to attackers who can study them offline, making information asymmetry the real application security problem, according to Arxan Technologies. The practical shift is from trying to hide code to designing applications that remain safe when reverse engineered, because obfuscation only delays extraction.
Editorial analysis by NHI Mgmt Group, based on content published by Arxan Technologies: “What Bad Guys 2 Taught Me About Information Asymmetry and the Application Security Problem Nobody Wants to Name”.
Key questions
Q: What breaks when application secrets are embedded in a shipped binary?
A: The secret stops being secret once an attacker can extract it offline.
Q: Why do reverse engineered apps create fraud and impersonation risk?
A: Because the attacker can reproduce the app’s behaviour, not just its code.
Q: How do security teams know if post-incident hardening is actually working?
A: It is working when restored identities match approved ownership, emergency grants are fully removed, and exception lists shrink after certification rather than growing.
Practitioner guidance
- Reduce client-side secret exposure Remove hardcoded keys, long-lived tokens and backend trust logic from shipped binaries wherever a server-side alternative exists.
- Adopt runtime anti-tamper controls Use integrity checks, anti-debugging and environment validation to make reverse engineering workflows noisier and less reliable.
- Instrument applications for abuse telemetry Collect signals for emulation, tampering, debugging and abnormal request signatures so analysts can see when copied binaries are being used.
Bottom line: Reverse engineering turns shipped code into an attacker-controlled analysis object, which means application security cannot depend on hiding logic, keys or request signatures inside the binary.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/09/2026 3:45 pm
Information asymmetry is the core application security failure, not code secrecy. Once a binary ships, the attacker gets a long, unconstrained analysis window while the defender loses direct visibility. That means the practical problem is not whether code can be hidden for a while, but whether the application remains safe after the attacker has studied it. Teams should design for exposure, not for permanent concealment.
A question worth separating out:
Q: How should teams handle third-party SDK trust in mobile applications?
A: Treat each SDK as part of the runtime trust boundary and review what it can see, call and modify. If a dependency can influence authentication, collect sensitive state or update behaviour after release, it needs the same governance scrutiny as internal client code.
👉 Read our full editorial: Application reverse engineering turns trust assumptions into breach risk