As a developer once said… It depends!!!
In a nutshell, it depends on what is motivating you to use obfuscation in the first place. If you plan to use only code obfuscation as a security measure then you may end up with a Maginot Line on your security defences.
In this article, we will first provide a brief lesson on World War II to understand how the French's impenetrable fortifications built to prevent invasion by Germany were easily circumvented. We will use this as an analogy to understand how attackers can do the same when they encounter code obfuscation being used as a technique to hide hardcoded secrets in a mobile app.
Source: https://simple.wikipedia.org/wiki/Maginot_Line
The Maginot Line was a series of fortifications built along the French border with Germany in the 1930s, intended to deter a German invasion. However, the line was bypassed by the German military in 1940, by going around it, leading to the quick defeat of France in World War II.
The bypass consisted in going around it through the bosques of Ardennes in Belgium, a terrain the French military deemed too hard to go through due to its natural barriers, a dense forest area with rough terrain and a few roads, thus they narrowed their efforts on defending those roads, but the Germany military just went through the wilderness of the dense forest and encircled them, with the rapid defeat and subsequent occupation of Paris and capture of the Maginot Line from behind.
Code obfuscation is the process of making code harder to understand or reverse-engineer by making changes to the code that do not affect its functionality. This can include techniques such as renaming variables and functions. This helps to conceal the logic and purpose of an app’s code to protect from intellectual property theft, but it isn’t very effective to hide secrets, certificates or other sensitive info, once a range of open source tools exist to statically reverse engineer the Mobile App and extract those. For example, MobSF is one of those tools and you can see it being used in the article How to Extract an API Key from a Mobile App by Static Binary Analysis.
Obfuscation has its trade off's, when implemented properly it can slow down, but never fully stop a dedicated attacker. In order to actually be effective, obfuscation is difficult to implement, hard to maintain in a continuous integration and continuous delivery format, and can slow down performance while increasing the size of an app, leading to a suboptimal user experience.
Bear in mind that code obfuscation does not include the process of hardening your code, by encrypting it and/or adding logic to it to make it self-defensible against running in root/jail-broken devices, emulators, detecting debuggers, instrumentation frameworks, MitM attacks and other undesirable potential threats at Runtime.
Like the Maginot Line, code obfuscation may give you a false sense of security for today's mobile threats to APIs. This is because modern attackers have a wide range of tools and techniques at their disposal that allow them to easily reverse-engineer obfuscated code. For example, a process called de-obfuscation can be used to reverse the changes made to the code and make it readable again to a certain extent. Additionally, attackers can use tools such as debuggers and decompilers to analyse obfuscated code in order to understand how it works, identify vulnerabilities, and steal those secrets you tried so hard to hide with code obfuscation.
Furthermore, when an attacker doesn’t want to spend the time de-obfuscating your code or doesn’t have the skillset he just goes around it, just like the Germany military did with the Maginot Line, by doing a MitM attack, and if necessary using Frida to bypass certificate pinning when you have it to protect your HTTP requests from being intercepted, as shown in the article How to Bypass Certificate Pinning with Frida on an Android App.
Rather than trying to make it harder for attackers to understand the code, developers must engage in proactive measures to actively monitor and secure their Mobile Apps and APIs.
To secure a Mobile App and their APIs one will traditionally resort to different tools for both purposes, but what if you could do all with only one solution? Yes, you can do it all with Remote Mobile App Attestation.
With the use of Remote Mobile App Attestation you will have your mobile app being continuously analysed on the background (via responses to non re-playable challenges from a cloud service), and on a successful attestation it gets a valid signed JWT token that is then automatically added to outgoing API requests, thus allowing the API to only serve requests when a valid, and not expired, JWT is in the header of the API request. This gives you the guarantee that your API only serves requests to genuine and unmodified instances of your mobile app that isn't under attack and was registered with the cloud service:
To get your secrets out of the mobile app code you will want to take advantage of the Remote Mobile App Attestation security that guarantees to deliver them just-in-time of being used in the API request, but only to mobile apps that pass the mobile device and mobile app integrity checks:
On top of Remote Mobile App Attestation and Runtime Secrets you also get Dynamic Certificate Pinning, out of the box, (with over-the-air secure pin rotation capabilities and zero code) to guarantee the integrity of the communication channel between the Mobile App and their APIs:
Finally, to monitor live the ongoing threats faced by your mobile app you can then use the live Grafana Dashboard to keep an eye on the attacks in real-time:
Code obfuscation is a security technique that is becoming increasingly ineffective to today's threats and attacks faced by Mobile Apps and their APIs. It is similar to the Maginot Line in that it is a defensive measure that is easily bypassed by attackers and expensive to implement/maintain. Instead, organisations should focus on implementing proactive security measures to protect their APIs, like Remote Mobile App Attestation and Runtime Secrets, that allows app developers to deliver secrets just-in-time of them being used in the API Request to mobile apps that attest successfully.
In conclusion, if you are using code obfuscation with the main goal being to secure/hide your secrets and/or sensitive data, then you give yourself a false sense of security, a Maginot Line.
Cover photo by ThisIsEngineering from Pexels
Paulo Renato is known more often than not as paranoid about security. He strongly believes that all software should be secure by default. He thinks security should be always opt-out instead of opt-in and be treated as a first class citizen in the software development cycle, instead of an after thought when the product is about to be finished or released.
