Once you ship a mobile app, the binary is on devices you do not control, and anyone can pull it apart: decompile it, read its strings, trace its logic, modify it, and repackage it. OWASP captures the gap there as M7, Insufficient Binary Protections, in its Mobile Top 10. The defenses, obfuscation, anti-tampering, anti-debugging, jailbreak and root detection, raise the cost of reverse-engineering and tampering. But there is an important nuance: these are defense-in-depth that slow a determined attacker, not a replacement for keeping secrets out of the binary and enforcing security on the server. Here is what M7 is, what its protections do, and where their limits are.
Short answer
M7, Insufficient Binary Protections, is the OWASP Mobile Top 10 risk that an app's compiled binary can be reverse-engineered, analyzed, or tampered with because it lacks protections that raise the cost of doing so. Per OWASP, attackers decompile apps to find hardcoded secrets and understand logic, and modify and repackage them to bypass checks or add malicious code. The protections, code obfuscation, anti-tampering and integrity checks, anti-debugging, and root or jailbreak detection, make this harder. But they are defense-in-depth: they slow a determined attacker rather than stop one, so the essential controls are still to keep secrets out of the binary entirely and enforce security on the server, with binary protections layered on top, not relied on alone.
What you should know
- The binary is in attackers' hands: it can be decompiled and modified.
- Reverse-engineering finds secrets and logic: hardcoded values are exposed.
- Tampering and repackaging: bypassing checks or adding malicious code.
- Protections raise the cost: obfuscation, anti-tampering, anti-debugging, detection.
- They are not a substitute: keep secrets out and enforce on the server.
What is M7: Insufficient Binary Protections?
It is the risk that an app's binary lacks the protections needed to resist analysis and tampering. A shipped app is a file an attacker can obtain and inspect at leisure: they can decompile it to read its code and strings, which exposes anything hardcoded, such as keys or endpoints, and reveals how the app works; and they can modify the binary and repackage it, to disable checks like a license or a security control, or to insert malicious code and redistribute it. Insufficient binary protections means the app makes these activities easy. The protections that address M7, obfuscation to make decompiled code harder to follow, integrity and anti-tampering checks to detect modification, anti-debugging to resist dynamic analysis, and root or jailbreak detection to flag compromised environments, all aim to raise the cost and effort of attacking the binary. M7 treats the binary's resistance to reverse-engineering and tampering as the asset, which matters for protecting intellectual property and for raising the bar against attackers.
What do the protections do, and what are their limits?
Each raises the cost of a specific attack, within limits. The table summarizes.
| Protection | What it does | Limit |
|---|---|---|
| Obfuscation | Makes decompiled code harder to follow | Slows, does not prevent, analysis |
| Anti-tampering | Detects modification of the binary | Can itself be patched out |
| Anti-debugging | Resists dynamic analysis | A determined analyst can bypass |
| Root/jailbreak detection | Flags compromised environments | Can be evaded or hooked |
The honest framing is that every one of these protections raises the effort required but can be defeated by a sufficiently determined and skilled attacker who controls the device, since the protection itself runs in code the attacker can analyze and modify. That does not make them useless: raising the cost deters casual attackers, slows targeted ones, and protects against automated repackaging, which is real value. But it means they are defense-in-depth, not a security boundary. The mistake M7 guards against is two-sided: shipping with no binary protections at all, and over-trusting them, assuming that because the app obfuscates code or detects tampering, it is safe to put secrets in the binary or enforce critical decisions client-side.
How do you address M7?
Layer binary protections on top of getting the fundamentals right. Start with what binary protection cannot fix: do not hardcode secrets such as API keys, credentials, or cryptographic keys in the binary, since a decompiler will find them regardless of obfuscation, and enforce security-critical decisions, authentication, authorization, payments, on the server, where the attacker cannot reach them, rather than in client code that can be patched. Then add binary protections as the layer they are: apply code obfuscation, strip debug symbols and debugging aids from release builds, add integrity and anti-tampering checks, and use root or jailbreak detection to inform risk decisions, sized to your app's threat model. Treat these as raising the cost for an attacker, not as guarantees, and never let their presence justify weakening server-side controls or embedding secrets. The principle is that binary protections make attacking your app more expensive, while the things that must stay safe regardless, secrets and critical decisions, live off the device.
What to watch out for
The first trap is over-trusting binary protections, deciding that because the app is obfuscated or detects tampering it is safe to hardcode a secret or enforce a critical check client-side; the binary can be analyzed, so secrets and enforcement belong off the device. The second is the opposite, shipping with no protections, making reverse-engineering and repackaging trivial. The third is leaving debug symbols and debugging aids in release builds. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled app against OWASP MASVS and surfaces hardcoded secrets and binary configuration, helping you find the secrets that should not be there in the first place, while the protections themselves you build into your release pipeline.
What to take away
- M7, Insufficient Binary Protections, is the OWASP Mobile Top 10 risk that an app's binary can be reverse-engineered or tampered with because it lacks protections raising the cost.
- The protections, obfuscation, anti-tampering, anti-debugging, and root or jailbreak detection, slow a determined attacker but can be defeated, so they are defense-in-depth, not a security boundary.
- Get the fundamentals right first: keep secrets out of the binary and enforce critical decisions on the server, then layer binary protections on top rather than relying on them.
- Use a pre-submission scan such as PTKD.com to surface hardcoded secrets and binary configuration, then add protections in your release pipeline.
