M7: Insufficient Binary Protections (2024)

Missing code obfuscation, tampering detection, and reverse engineering protections. Attackers decompile app binaries to extract secrets or modify app behavior.

Risk Assessment

Am I Vulnerable?

• Sensitive Data in Binary: The app contains hardcoded sensitive data, cryptographic secrets, or commercial API keys within the binary that attackers can extract through reverse engineering.
• Critical Business Logic Embedded: Critical business logic, proprietary algorithms, or pre-trained AI models are embedded in the binary, making them attractive targets for intellectual property theft.
• Lack of Code Protection: The app lacks obfuscation or other code protection mechanisms, making it easy for attackers to decompile and understand the code.
• Local-Only Security Checks: Security checks exist only locally without backend enforcement. Attackers can bypass local checks by manipulating the binary.
• High Popularity: Popular apps face higher redistribution risks and are more likely to attract reverse engineering or modification attempts.
• No Integrity Verification: No integrity checking detects binary tampering or unauthorized redistribution of modified app versions.

How Do I Prevent It?

• Threat Modeling: Conduct threat modeling to identify critical content in binaries and assess the financial impact of potential breaches. Greater financial consequences demand stronger defensive investments.
• Reverse Engineering Prevention: Apply obfuscation tools to make the binary incomprehensible. Compile parts of apps natively or use interpreters and nested virtual machines to make reverse engineering harder, as many decompiling tools only support one language and binary format.
• Backend-Enforced Security: Combine obfuscation with backend enforcement of security checks. Required resources for a protected feature should only be downloaded if a check succeeds locally and in the backend. Implement integrity checks to detect code tampering.
• Minimize Binary Secrets: Provide only essential information to app binaries. Avoid hardcoding secrets, algorithms, or security checks that could be extracted or bypassed.
• Redistribution Detection: Deploy integrity checks on startup to detect unauthorized modifications and redistribution. Automatically report violations to find and remove counterfeit app store listings before they become widespread.
• Self-Assessment with Free Tools: Use free tools like MobSF, otool, apktool, and Ghidra to analyze your own binaries and assess the quality of binary protections.

Example Attack Scenarios

• Hardcoded API Keys: An app uses a commercial API where it must pay a small fee for each call, paid for by the subscription fee users pay. However, the API key is hardcoded in the app's unprotected binary code. An attacker reverse engineers the app with free tools and gets access to the secret string. Since API access is only protected with the API key and no additional user authentication, the attacker can freely work on the API or even sell the API key, causing substantial financial damage.
• Disabling Payment and License Checks: A mobile game publishes its app and the first levels for free. If users like the game, they pay for full access. All resources for later levels are shipped with the app, protected only by a license check. An attacker reverse engineers the app and locates the license check. If the app binary is not sufficiently protected, it is easy to replace the check with a static success statement. The attacker can then recompile the app and play it for free or sell it under another name.
• Hardcoded AI Models: A medical app features a specialized AI model for answering user requests, included in the source code to enable offline access. This AI model is the most valuable asset and took many person-years to develop. An attacker might extract this model from the source code and sell it to competitors. If the binary is insufficiently protected, the attacker could also learn how the model is used, selling this information along with the AI training parameters.