MASWE-0059: Code Obfuscation Not Implemented
MAS Requirement
The app implements code obfuscation.
Overview¶
This weakness occurs when an app's code, particularly its security-relevant logic, ships without effective obfuscation, facilitating reverse engineering and static analysis.
Obfuscation does not prevent reverse engineering, but it raises its cost. Identifier renaming or string encryption are easier to implement and are considered common obfuscation techniques. However, there are other obfuscation techniques, like control-flow transformations, opaque predicates, instruction substitution, instruction block chopping, and method inlining, as well as hindering decompilers from producing usable output. Most of these techniques can be combined together.
Modes of Introduction¶
- No Obfuscation Applied: Shipping release builds without any minification or obfuscation, leaving class, method, and symbol names intact.
- Security-Relevant Logic Left Readable: Not applying enough obfuscation to security-relevant code, leaving code sections like security checks, licensing logic, and proprietary algorithms trivially analyzable.
- Obfuscation Without Hardening: Applying standard obfuscation whose transformations are automatically reversible by publicly available tooling.
Impact¶
- Bypass of Protection Mechanisms: Attackers can quickly locate and defeat client-side checks such as root detection, licensing, or anti-tampering logic, resulting in the circumvention of the app's defenses.
- Compromise of Sensitive Data: Attackers can recover proprietary algorithms and embedded secrets from readable code, resulting in intellectual property theft and easier planning of further attacks.
Mitigations¶
- Enable Obfuscation for Release Builds: Apply the platform's minification and obfuscation tooling or established commercial obfuscators to all release builds.
- Harden Security-Relevant Code: Apply stronger transformations (opaque predicates, instruction substitution, control-flow obfuscation, method inlining) to the security-relevant code.
- Implement Lossy Obfuscation: Implement obfuscation in a way that intentionally removes information from the code, rather than only shift things around.
- Assess Obfuscation Effectiveness: Regularly attempt to reverse engineer the release build with state-of-the-art decompilers and deobfuscators to validate that the protection meets its goal.
- Combine with Runtime Protections: Pair obfuscation with runtime integrity and anti-instrumentation checks (see the mitigations in Malware Detection Not Implemented, Dynamic Analysis Tools Detection Not Implemented, Runtime Code Integrity Not Verified), since obfuscation alone only delays attackers.
Knowledge¶
MASTG-KNOW-0033: Obfuscation MASTG-KNOW-0089: Obfuscation
Tests¶
MASTG-TEST-0369: Insufficient Obfuscation of Security-Relevant Native Code MASTG-TEST-0368: Insufficient Obfuscation of Security-Relevant Java/Kotlin Code MASTG-TEST-0391: Insufficient Obfuscation of Security-Relevant Native Code