“Do you protect your apps?” That’s what our field engineer recently cried across a room full of Android developers. The question splits the room. Half are confused; half respond with a confident “of course we do, we use the tools that come with Android Studio (1).”
Let’s address the confusion first and define the question. Once a mobile app is published to the app stores, it is available for the world to download. That includes attackers that have motivations beyond simply using the functionality of your app. They want to reverse engineer it to learn its secrets; and to then use that knowledge for their own means.
So when we ask developers if they protect their apps, we are asking if they are safe from reverse engineering.
The other half of the room is correct, as Android Studio does provide tools that help. These are Proguard and R8. Given they are free and come with Android Studio, on the surface there really is no excuse not to use them. Though that advice comes with a warning: both tools are described in the Android community as “optimisers,” not “protectors.”
They apply a form of obfuscation known as Symbol Obfuscation. This means they take the meaningful names of your packages, classes and methods and shrink them down to simple, single letter alternatives (e.g. com.mycompany.topsecretencryption.encrypt becomes a.b.c.d). This reduces the size of your code base and takes away information that would be a useful entry point to an attacker trying to understand what your code does.
This is a good start and creates a small hurdle to anyone reverse engineering code. But it is only a small hurdle and one that is quickly stepped over. True protection needs to go much deeper and have many more layers.
The first layer required is still obfuscation. A different kind of obfuscation though – Control Flow Obfuscation. This goes much deeper than the superficial renaming. It makes the code logic itself difficult to read and understand.
The second layer is environmental checks. These make sure the app is running only where the developer intended. It isn’t on an emulator being monitored; it doesn’t have a debugger attached to it; and it isn’t under the control of a hooking framework like Frida.
The third layer is a technology called anti-tamper. This gives confidence the code is executing exactly as the developer intended as it thwarts attempts to change the code and the wider app package. It makes sure other protections stay embedded in the app; that an attacker isn’t prodding-and-poking the app to understand how it works; or that the IP isn’t being repackaged or used out of context.
These three layers are designed to complement each other, becoming more than the sum of their parts. This is the approach taken by ProtectMyAppTM and is how true protection against reverse engineering is achieved.
So now you know, just like our protection, when we ask if you’re protecting your app, it’s really a multi-layered question.
(1) Android is a trademark of Google LLC
