I love WhatsApp. I use it daily. That’s why the recent WhatsApp breach got my attention.
The breach reminded me about a question we get asked from time to time – what’s the difference between binary-based obfuscation and source code obfuscation? When I am asked this question, I usually make a small joke and say – what’s the difference between a house and a bundle of wood?
Don’t get me wrong, I’m a security engineer and developer. I know that, in the right hands, a bundle of wood can turn into a miraculous creation. That’s not the challenge. The challenge lies in actually coding obfuscation in the source code of an Android or iOS app manually, which is an extremely complex and error-prone undertaking.
What Went Wrong With WhatsApp To Enable the Breach?
I spent a bit of time analyzing the WhatsApp breach and vulnerability. WhatsApp had implemented Java obfuscation using a popular open-source obfuscation tool. That tool places all the burden on the developer to code the solution into the app, and get it *exactly* right.
The vulnerable code was located in a non-obfuscated C library called libwhatsapp.so. That library held most of the logic for the WhatsApp code. Why was libwhatsapp.so not obfuscated? Was it an oversight? Was it to maintain the performance of the app? These questions and more reveal the underlying problem with all manual obfuscation methods. Someone chose (or forgot) to obfuscate libwhatsapp.so and that made it easier for the attacker to capitalize on the exploit, as documented by Check Point.
Manual Obfuscation Requires Lots of Considerations:
(A) You have to find a developer that knows how to code obfuscation.
It takes a highly specialized mobile developer to code obfuscation. First time mistakes, oversights and errors are costly.
(B) You have to go through trial and error to get manual obfuscation right.
There’s a learning curve. That learning curve takes time. And the learning curve starts over for each development environment and for each new developer that touches the project. As a developer, you also have to be careful not to manually obfuscate too much (or too little), to maintain the performance of your app. Remember, the larger development team is constantly writing new code that is not obfuscated. Maintaining the proper obfuscation across an app’s codebase is a real challenge.
(C) You can’t obfuscate everything in source code.
The pressure to release the app on time, non-native file systems, 3rd party SDKs, and other mechanisms pose very sophisticated problems to developers on the obfuscation project. Some things simply can’t be obfuscated in source code.
(D) Obfuscation, alone, is not enough.
Like all security measures, code obfuscation should be part of a larger protection scheme deployed within your app. App makers who rely only on code obfuscation are taking a big risk with their users, data, and IP.
Binary-Based Obfuscation is Simply Better
At Appdome, we give users the ability to obfuscate an entire app binary in seconds. Using Appdome, developers do not code obfuscation manually. Instead, a machine codes the obfuscation directly to the mobile app binary, automatically, instantly, on-demand.
Using Appdome’s binary code obfuscation, the native library is encrypted at the time of fusion. Meaning the distributed apk/ipa (after fusion) has all the native libraries encrypted and is only decrypted when loading it to the app memory. So the compiled source code is never in the clear in any file at any time. Binary-based obfuscation protects the app against Static Code Analysis. Static code analysis (a.k.a. reverse engineering) is the process of extracting information about the design of an application by examining the contents of its files. Just examining without running it. This is commonly done using tools called disassemblers or decompilers. The ones we mostly use at Appdome are IDA and Hopper. Appdome protects against Static Code Analysis with various features, including Flow relocation (Java/Kotlin from Android, Objective C/Swift for iOS), binary code obfuscation (C/C++ for Android. Objective C/C/C++ for iOS), non-native code obfuscation (Non-native code – C#/JavaScript if relevant), strip debug symbols and encrypting strings and resources.
To complete the app protection, a developer should also protect the app against Dynamic Code Analysis. Dynamic Code Analysis is the process of researching the apk/ipa while it is running either by tampering with the app and inserting code or by remotely debugging the app with an interactive debugger. The ones we mostly use at Appdome are LLDB and GDB. Appdome protects against Dynamic Code Analysis with various features including ONEShield, trusted mobile sessions, Jailbreak/ Root prevention, Data At Rest Encryption and Memory Encryption.
Leveraging technology to implement binary-based obfuscation in a mobile app eliminates the challenges of manual implementation. There are no learning curves, no coding tradeoffs, and users can combine obfuscation with other security methods inside the mobile app to protect users, data and IP. On top of that, you don’t need specialized expertise to implement obfuscation using Appdome. Anyone can implement sophisticated obfuscation and shielding methods to any app, instantly.
Preventing the WhatsApp Breach Without Coding a Thing
Using Appdome, no one has to face what WhatsApp faced. Our users can combine three features of Appdome’s security suite to eliminate vulnerabilities seen in the WhatsApp breach.
- First, ONEShield™, Appdome’s anti-tampering, anti-debugging and protection from reverse engineering system provides automatic protection for all apps built on Appdome.
- Second, TOTALCode™ Obfuscation and TOTALData™ Encryption can be combined to protect all libraries, including the native .so libraries (where the vulnerability was found).
- Finally, using TOTALCode Obfuscation, you can add Flow relocation automatically, and using TOTALData Encryption, a user could have applied Encrypt strings and resources automatically.
These features would have made the app much harder (impossible) to reverse engineer. As you can read in an earlier post, Appdome’s TOTALData Encryption also offers encryption of in-memory data, which protects and obfuscates binary source code at runtime as well. Encrypting in-memory data would have made researching the stack overflow exploit in the WhatsApp breach much harder.
Here’s a 5-minute video that shows *exactly* how. Anybody can independently verify this by creating their account on Appdome, with no development work needed.
The bottom line, the technology exists to add app hardening and app shielding to apps automatically. That same technology can be used to combine app hardening and app shielding with other security measures. That technology is called Appdome, it would have prevented the WhatsApp breach, and it can prevent breaches of your app too. Our Developer’s Guide for Mobile App Security goes into detail how developers can use Appdome to protect and secure their apps. I encourage everyone to try Appdome, which you can accomplish in less time than it took you to read this article.
