Android Anti-Reversing Defenses¶
Overview¶
General Disclaimer:
The lack of any of these measures does not cause a vulnerability - instead, they are meant to increase the app's resilience against reverse engineering and specific client-side attacks.
None of these measures can assure a 100% effectiveness, as the reverse engineer will always have full access to the device and will therefore always win (given enough time and resources)!
For example, preventing debugging is virtually impossible. If the app is publicly available, it can be run on an untrusted device that is under full control of the attacker. A very determined attacker will eventually manage to bypass all the app's anti-debugging controls by patching the app binary or by dynamically modifying the app's behavior at runtime with tools such as Frida.
You can learn more about principles and technical risks of reverse engineering and code modification in these OWASP documents:
- OWASP Architectural Principles That Prevent Code Modification or Reverse Engineering
- OWASP Technical Risks of Reverse Engineering and Unauthorized Code Modification
Knowledge Articles¶
| ID | Name | Platform |
|---|---|---|
| MASTG-KNOW-0029 | File Integrity Checks | |
| MASTG-KNOW-0031 | Emulator Detection | |
| MASTG-KNOW-0027 | Root Detection | |
| MASTG-KNOW-0035 | Google Play Integrity API | |
| MASTG-KNOW-0034 | Device Binding | |
| MASTG-KNOW-0033 | Obfuscation | |
| MASTG-KNOW-0028 | Anti-Debugging | |
| MASTG-KNOW-0030 | Detection of Reverse Engineering Tools | |
| MASTG-KNOW-0032 | Runtime Integrity Verification |