If you can copyright the design and identity, what’s going on behind the lines of code? Are they protected from plagiarism? How come there are so many identical apps? Is it just because “great minds think alike?” Or is there a rampage going on? I’ll try to address those questions with the help of my fellow mobile developers.
What Can Happen With Unprotected Apps
Application source code is the essence of any application. Hundreds of hours of work, all the knowledge, discoveries, duct tape solutions, and every single bit of hope to succeed are concealed in the application source code. Like a belly of a beast, it is vulnerable and the consequence of it being damaged are terrific.
So if someone either steals or decompiles a chunk of your app’s source code or the entire code, basically hijacks your iOS or Android app, what can you do? The worst case scenarios include the following outcomes:
- Your app gets cracked. If your app is a paid-for one, the villain can make a free version of it and just kill your business model. This will most likely require that you abandon your project and come up with another one. Tough call.
- Your app gets infected. They keep the app paid and normal, but infect it with virus ware or malware to create scammer schemes on later builds. In this case, your loyal users get a kick in the teeth which ruins everything you’ve built. This is a bad one and will most likely force you out of the business, not to mention legal troubles.
- Your app becomes a guinea-pig. If the app you created is of any success, it has a target on its back. If your competitors get a hold of your app’s source code, they’ll rip it into pieces and get chunks of your former competitive edge. Will most likely end your app’s life.
Now let’s relax a little and look how and why your application source code can be stolen. Once the app is out, you can expect people to start messing around with them.
Is App Reverse Engineering Worth It?
So apart from all the drama, having your code stolen is a bummer that if not ruins your brand, might be a huge distraction dragging time from what really matters – your business goals. At Shakuro, we consider source code of an application our 100% responsibility. It’s security, safety, and bulletproofness have to be constantly tested as features get implemented.
iOS Code Security
Our iOS apps have code written in Objective-C and Swift which compile into a binary code. The source code is stored in our private GitHub repository or client-side repositories. The app-server user data interaction goes via native iOS functions or OpenSSL certificate to encrypt the traffic for extra protection.
This basically turns our iOS apps into black boxes that you can’t really see into. But with a certain amount of persistence, they can peek into it from different angles and fish something out. Apps consist of different parts like:
- Encrypted executable – compiled code, the core.
- Metadata – variables.
- Encrypted frameworks – modules.
- Assets – images, strings, etc.
The executable part is what is usually shielded to protect the app from intrusion. Frameworks might also get tapped into. A reverse engineer can work with two states of an app – active and inactive. They can study the traffic and inject code when the app is running, and study the binaries when the app isn’t running. Decrypting binary code requires an extensive set of skills worthy of a very competent app developer.
Besides that, Swift being a fairly new technology is secure by nature as the tooling to break down its code is not there yet. As for Objective-C, there are multiple complicated tools that have to be used specifically for certain parts of the reverse engineering process and require so much effort, it almost nullifies the effect, not to mention it is unethical and illegal.
iOS Code Obfuscation
If someone is actually trying to decompile the Swift code, it is natively obfuscated. Quoting hotpaw2 from stack overflow: “Xcode also converts Swift code into a kind of intermediate representation bytecode, called Bitcode by Apple. But, IIRC, Bbitcode gets stripped out by Apple before sending an app to customers, and the app’s compiled code is also encrypted by Apple.”
Instead of putting time in complexing the app code that is not visible in the build, what we really strive to protect is SDK libraries that contain custom modules.
In addition to the native features, we can use Obfuscator which is a tool for the obfuscation of hard-coded security-sensitive strings. Obfuscator turns the strings into byte arrays and instead of passing them through the app, decodes byte arrays to reveal the strings. It does not require the entire app code to be obfuscated but gives you the choice to only affect the most crucial strings.
Android Code Security
There is no way to provide a 100% security of an Android application. If someone commits themselves to getting inside your app code, they will do it. The only way to fight it is to make it senseless.
In case of an iOS app written in Swift it is a hard and painstaking process, due to its relative novelty, but what about Java? It has been around for decades and there are millions of developers. Considering the peculiarities of the Android OS, here’s how you can protect an application. Android application source code is generally written in Java, but it is not distributed in builds as Java bytecode, instead it is uploaded in .dex files, that can be decompiled into Java source code. The one efficient countermeasure that the community seems to all agree upon is obfuscation.
Android Code Obfuscation
One of the most powerful ways to secure an Android APK is use code obfuscation. This practice changes the app variable names and classes on regular basis to make the code strings confusing and break dependencies. But it’s more than just that. Code obfuscation also shrinks the code, hides some of the snippets, and significantly shrinks it down. Some of the most popular obfuscation tools are:
- Proguard
- DexProtector
These are solid tools that prevent intrusions through some strong cryptographic algorithms while also injecting security checks in Android APK. The app can be blocked once the tool realizes the app code is being tapped into.
Android Application Licensing
A built-in feature that Android app licensing is, is an attempt to apply a flexible licensing policy on an application-by-application basis – each application can enforce licensing in the way most appropriate for it. It grants some sort of an access control to your app. “When an application checks the licensing status, the Google Play server signs the licensing status response using a key pair that is uniquely associated with the application. Your application stores the public key in its compiled .apk file and uses it to verify the licensing status response.”
“For example, an application can check the licensing status and then apply custom constraints that allow the user to run it unlicensed for a specific validity period. An application can also restrict use of the application to a specific device, in addition to any other constraints.” This feature is already being used to integrate security and transparency to the client-side app code usage.
General App Security Guidelines At Shakuro
As it might seem, code is not the most valuable part of your app, it certainly is the heart of an app, but it is almost counter-intuitive how much it takes to decompile the code and build a clone of it. Instead, there are some mobile-specific issues that affect the most valuable asset you have – information. It’s the developer’s primary goal to keep the information secure and private.
Data Storage
If an app stores any user data, especially credentials, tokens, and access keys, those things have to protected better than just by an Info.plist file. Instead, use native system’s keychain services or third-party libraries for safe storage. Also using cache and not backing all the data up on cloud services can save space and prevent someone from parsing it.
Secure Communication Channels
The HTTP protocol is an unencrypted app to server communication method. Public Wi-Fi spots that a lot of phones connect to on daily basis can be the means for man-in-the-middle attacks. So if anything confidential or security-critical is being sent back and forth, HTTPS is the more secure communication channel. For custom network protocols, use TLS.
User Data
As more apps get integrated to our lives through various useful features, phones become the ultimate hubs of personal and sensitive information that has to be stored responsibly. If a user grants your app access to that information, it shouldn’t be duplicated and stored separately somewhere. We are strongly considering where we store information and only utilize uncompromised sources.
Android-Specific Tips
- Avoid Webview due to Javascript interface vulnerabilities.
- Avoid Permission Re-delegation due to third-party apps unauthorized access.
- Avoid Intents due to the risks of being tapped into.
- Avoid SQL Injections due the inadvertent vulnerability introduction.
Bottomline
One of the best ways to resist is make the juice not worth the squeeze. The purpose of app piracy is to steal an app and get some sort of reward for it. If the significance of reward doesn’t beat the time & effort put in, the opportunistic pirates and hackers will abandon it. At the end of the day, they are businessmen also… unethical and unlawful, but backed by a twisted logic.
The overwhelming majority of developers say that if someone wants to reverse-engineer an app, they will do it.
Fair to say that source code is not why clients appreciate developers. Yes, it is the output and the result of all the hard work, but it’s not the reason they pay us. When clients hire a team, they invest in the solution of their task which is beyond just the code. They decide to hire team based on their technical abilities, their experience, their business model, etc. We win clients over the way we communicate and make an effort to sincerely understand their projects, and show our commitment to it once we start.
