The Security Impact of Good Renaming

The art of Application Hardening is a broad practice that includes many tactics that defend against many different attacks. At Digital.ai, we offer a wide variety of protections that we call “Guards” that help our customers harden their apps. We categorize our Guards into two groups: active and passive. While active ones are critical to verify app integrity or environment safety, static guards and code obfuscation are the backbone of strong protection as they provide resilience to reverse engineering. Without obfuscation, all protections can be easily removed, thus making them useless on their own. Digital.ai Android App Protection provides an industry-leading set of static protection guards that create layers of defense. One of the most vital tools against reverse engineering is Renaming.

In Android, code is compiled in a way that retains its original names and most of the code structure. This basically gives the attacker access to the source code and all the secrets hidden inside. Renaming changes the names of classes, methods, and fields so that the original purpose is not exposed.

However, renaming has a couple of challenges. The first one is knowing what to rename. Due to the extensive use of reflection in Android, there are many things that cannot be renamed without breaking the app. In Android, methods or classes are often referenced by their exact names, so changing these names can prevent the system from finding them, potentially causing the app to malfunction. Digital.ai Android App Protection tools include a Dynamic Analysis framework that examines the app at runtime and finds all names that can or cannot be renamed to solve this problem.

The second challenge is how we want to rename. Just changing the name is an effective first step, but different approaches exist for different situations. One weak approach would be partial renaming, where you only apply Renaming Guard to the sensitive part of the app. While it makes sense to protect security-heavy code, renaming just that one part puts a big target on it for the attackers as they know there is something critical in there. Our solution to that challenge is something we call “Organic Renaming.”

Organic Renaming

In Android App Protection 5.6.0, we introduced a new Renaming mode – ‘organic.’ This is not only a charset but a whole new type of protection. Before protection, our algorithm analyses the app and trains itself on names that already exist in the app. This allows the Renaming Guard to generate new names that make sense and appear very similar to existing ones.

This mode results in new names that are virtually indistinguishable from the original ones but are misleading and expose no information. What is the benefit of this approach over standard renaming modes? It makes it very hard to tell which items are renamed. Attackers no longer see a big red target over the renamed code as it seamlessly blends in with the rest of the application.

Examples

Attackers use various decompilers to analyze the application’s structure. Typically, it’s very easy to see everything when examining the application with tools like JADX. Let’s take a sample app and look at it with a decompiler:

As you can see, the app structure is very clear, and all the sensitive parts are exposed. Attackers can easily find places to intercept connections or steal user data. Let’s apply default Renaming to this and see how it looks. We excluded the ApplicationInterface class on purpose.

Basic Renaming

After renaming, the app is much harder for threat actors to analyze. However, there appears to be a new package filled with suspiciously named classes. Renaming is a common practice in application security, and having randomly generated names like ‘AQ,’ ‘BF,’ and ‘Bv’ immediately indicates that these classes are renamed to hide sensitive information.

Now, let’s try the Organic Renaming mode. This would generate names that are similar to the existing ones:

As we see, the names are no longer random characters, but actual words that make sense. The structure is also retained, so instead of a single new package filled with renamed classes, we have an actual structure pretending to be a real application.

This makes it extremely confusing for attackers to read the app. Instead of knowing which names are original and which are renamed, they must now play the guessing game. Maybe the ‘my.app.assist. ChooseActivityCount’ class is a real class, or maybe it’s security-critical code hiding under a different name.

We also use Organic Renaming for our own injected code. Even if you don’t have Renaming Guard enabled, our injected security checks will now hide securely between existing classes, making them impossible to find and bypass.

Final Thoughts

While no code obfuscation is perfect, it’s our job to provide a level of protection that makes it not worth the attackers’ time. Digital.ai Android App Protection provides an arsenal of obfuscation guards that complement each other and create layered security that is almost impossible to bypass in a reasonable amount of time.
Renaming is a very strong defense against reverse engineering, and we always strive to improve it. With Organic Renaming mode, we introduce a new level of challenge for bad actors that will repel attempts to analyze and modify your protected applications.