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 code base 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 mechanism 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.
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 via a free trial, with no development work needed.
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. I encourage everyone to try it, which you can accomplish in less time than it took you to read this article.