Today, I’d want to talk about source code obfuscation for Android apps. How much does it cost to enable obfuscation? What effect does it have on your software? This is the topic I’d want to discuss today.
But why is it crucial to comprehend the price?
Take a moment to recall the last time you were shopping. When deciding whether or not to buy a product, you must consider the following factors: Is the worth of this product greater than the value of rice? For security controls, the same question should be posed. We, the security team, are responsible for assisting you, the developer (or product manager), in understanding the value it can provide (what dangers it can reduce) as well as its cost (how it can affect your software). You can make the best selection – for you — if you grasp both the value and the price.
Let’s get back to the obfuscation now that we know why the price is so essential. There are three side effects that I’ve noticed:
–New bugs are being introduced.
–Debug vs. Release builds for production debugging
Let’s take a closer look at each of those side effects to see what they are and what we can do about them.
1. Bringing in new bugs
The first is that enabling source code obfuscation can and will result in the introduction of new flaws. It occurs when obfuscation alters your code, including changing the names of classes, attributes, and functions. This is fine as long as you don’t have any code that uses the names of classes, properties, or functions.
Serialization is an example, because the serialization process uses (by default) the object properties names (see, for example, the Gson documentation). The property names will change as a result of the obfuscation process, and the serialized JSON will change as well. This could result in invalid JSON being transmitted to your server, for example.
Code that makes use of reflection is another example. Let’s imagine your code searches all of the classes for a specific attribute. When you enable obfuscation, this code will fail since the property name has changed.
What options do you have? Because this is such a prevalent problem, there are good answers. You can, for example, prevent certain classes from being obfuscated (see this question on Stack Overflow). Another alternative is to define how to serialize the class explicitly (this is the relevant Gson documentation). You should still be aware of the problem and be prepared to put in some extra effort to address it.
It’s also worth remembering that this is a continuous process: each new serialized class or piece of code that uses reflection potentially causes the problem. You’ll need a system in place to deal with it (for example, code review questions or static analysis) so you can address it quickly.
2. Production Troubleshooting
The only helpful information you have when analyzing a production crash is the exception that was thrown (what happened) and the call stack (where it happened). When the call stack has understandable method names, this information is beneficial, but what happens when the code is obfuscated? The names of all classes and methods will be obscured, resulting in a call stack that is useless. It’ll be difficult to figure out what a.b.t.1 means, thus an exception was thrown in there.
This is another common issue with a simple remedy. ProGuard generates a mapping file that replaces the random names of classes, methods, and properties with their original names. This file may be used to decode the obfuscated call stack and restore its functionality.
That may appear straightforward, but there is some work to be done in order for this method to function: To begin, you must save all of the mapping files for all of the current production versions. Those files should be kept in a secure location because if a hacker obtains them, the obfuscation will be useless. Second, if you use an error reporting service (such as Bugsnag or Fabric), you must upload this file there as well. This adds some operational overhead, which you should think about.
3. Debug vs. Release build
Those two adverse effects are linked to the final negative effect I’d want to talk about. It’s standard practice to enable obfuscation only on release builds. Why? Because of the distinction between debug and release builds, this is the case.
Debug builds are what developers use on a daily basis. This build is designed with the developer in mind; it must be quick and simple to debug. The user is at the center of the release build; they should be able to work quickly and safely. This is why obfuscation is limited to release builds: obscured code is much more difficult to debug (that was what the previous section was about). Obfuscation also slows down the development process.
The main issue is that it causes a considerable disparity in build quality between the release and debug builds. Obfuscation of code can and will result in the introduction of new flaws (this was the first issue I discussed). Enabling obfuscation only on the release build means that errors will be identified much later – only when utilizing the release build: by end-to-end or acceptance tests — or, in the worst-case scenario, only on production.
This is a potentially dangerous adverse effect. What makes matters worse is that it isn’t much you can do to address the problem. One solution is to enable obfuscation for debug builds as well, however, this raises additional complications (like I discussed above).
Wrapping Up
Obfuscation of source code is important security control. It adds another layer of security when done appropriately (of course, it should never be the only protection). However, it comes at a cost, just like any other security measure. Now that you have a better grasp of the price, you can make an informed selection based on the threat model of your application. You may not have a choice in some cases, such as when you are forced to follow a specific regulation. Even in those cases, knowing the price can help you estimate the amount of effort required.
Last but not least, OWASP is here to assist you. I wanted assistance while working on enabling obfuscation in Android applications. Throughout the process, the Mobile Testing Guide and the people in the relevant Slack channel were quite helpful. When you need assistance, don’t be afraid to ask for it.
