How Common Is Code Obfuscation in Popular Android Apps?

Whether the goal is to steal intellectual property, gain access to sensitive user information, or access just about anything on a back end server, many targeted attacks begin with reverse engineering parts of client-side applications to gain understanding of their structure and to identify weak spots. Even if the eventual attack happens on the backend, analyzing the client-side counterpart often reveals crucial information about its APIs and authentication mechanisms.

For this reason, we believe that code hardening is non-negotiable for any app using original algorithms or operating with sensitive data.

In 2023 OWASP defined the 2nd version of their Mobile Application Security Verification Standard (MASVS), which serves as a set of guidelines for app developers trying to secure their mobile apps, as well as security testers trying to find vulnerabilities in them. It also provides Application Security product vendors like Digital.ai a framework for how to think about the app security landscape of today. OWASP’s MASVS-RESILIENCE controls perfectly fit with how Digital.ai (and Arxan before it) thinks about code hardening and anti-tampering:

• MASVS-RESILIENCE-1: The app validates the integrity of the platform.
• MASVS-RESILIENCE-2: The app implements anti-tampering mechanisms.
• MASVS-RESILIENCE-3: The app implements anti-static analysis mechanisms.
• MASVS-RESILIENCE-4: The app implements anti-dynamic analysis techniques.

While ensuring integrity of the platform, anti-tampering, and anti-dynamic analysis are often more impactful, if they are implemented without anti-static analysis they are vulnerable to advanced attackers easily spotting and neutralizing them.

Keeping this in mind, let’s start by evaluating how common it is for today’s apps to implement the MASVS-RESILIENCE-3 control. To do this, we reviewed 40 of the top free apps on Google Play, looking for clear signs of code obfuscation.

What We Found

To fully understand our findings, we must first describe our methodology. Bytecode-based languages like Java and Kotlin often retain class and method names. Even when the code is obfuscated, those identifiers can provide reverse engineers with enough clues to understand the app’s architecture and create an attack. Renaming, or name obfuscation, removes that identifying information from the code. Because the presence of Renaming (i.e. the lack of readable identifiers) is very visual and easy to spot, we used it as a criterion for this analysis.

After decompiling the target apps, we classified them into 3 categories based on renaming coverage:

• No Renaming: Nothing in the app is renamed, indicating non-existent or weak security.
• Local Renaming: Only some distinct parts of the app are renamed, which might indicate use of a Runtime Application Self-Protection (RASP) library for security, or a low-effort configuration.
• Global Renaming: Most of the code is renamed, indicating use of a comprehensive security solution and thoughtful configuration.

Among the selected apps, 37% were completely unprotected, 28% had only a few classes renamed, and the remaining 35% had renaming applied across most classes.

We need to note here that renaming only certain components (28% of apps analyzed) can actually make those parts stand out, because doing so highlights the most sensitive logic or security controls for an attacker to focus on and remove. In contrast, applying renaming more uniformly across the entire codebase (35% of apps of apps analyzed) hides these signals, making it far harder to distinguish valuable targets. This makes deconstructing the protected code a much more difficult task and significantly increases the time it takes to reverse engineer the app (which is truly the attacker’s most important and limited resource). In many cases, this increased complexity alone is enough to deter further attempts.

These results show that a considerable part of app developers put at least some thought into securing their apps, but at least a third of apps in the spotlight are still going to market with code that can be easily inspected, modified, and repackaged.

What Does This Mean?

This matters because unprotected or lightly protected apps are far easier targets for reverse engineering and tampering. For most apps, that can mean leaking intellectual property, exposing API keys, or revealing business logic that attackers can exploit. For games, it opens the door to cheating, modding, or cloned releases, which directly impact revenue and brand integrity. The current distribution shows that while some teams take security seriously, many still leave large parts of their codebases exposed.

It is clear: basic client-side protection is still not a universal standard, even among high-visibility apps and there is a real need for better consistency and awareness. The next post in this series will take a closer look into how much more difficult it is to analyze a well secured app compared to complete lack of protection or a low-effort implementation.