How to avoid reverse engineering of your android app?

According to a report published by Cvedetails (The ultimate security vulnerability data source), Android seemed to have a total number of 322 security flaws in 2017. Out of which, 23% of the flaws published in 2018 were critical and 13% of them allowed malicious code to execute. Obviously this is a bad news for Android app developers, for most of their clients are security critical such as Financial & healthcare ones.  In this article, we will discuss the best practices to protect an Android app from reverse engineering. We will look at some factors which make an Android app prone to code decompilation and some solution to how to prevent your android app from reverse engineering.  

What we are going to learn here:

• What is Reverse Engineering in Android
• How Reverse Engineering can be used to decompile Android app code
• What are some threats of a decompiled Android code
• How to avoid Android app decompilation to prevent reverse-engineering

What is Reverse Engineering in Android

People often embrace the open nature of Android as it is something that empower innovators to build groundbreaking products. But only a few know the dark side of this openness — Vulnerability.  Having said that, Android offer app developers a big advantage that most mobile OS don’t. Being an open source framework, it is fairly easy for an app developer or reverse engineer to study its source code at the Android Open Source Project (AOSP) and modify it the way they want. The technique through which most of reverse engineers re-obtain source code either with the intention of recreating the program, to build something similar to it, or to identify an app’s weakness or strengthen its security is known as Reverse Engineering in Android. 

How Reverse Engineering can be used to decompile Android app code

Android apps are always vulnerable to attack as the code is not rendered into machine code , leaving it prone to extraction and reverse engineering. The vulnerable code can then be used for a variety of reasons, which could be daunting for any serious mobile app business such as:

• Re-using the code for one’s own benefit
• Find vulnerabilities in the code
• Search for sensitive data hardcoded in the code
• Malware fishing
• Modifying the functionality of an existing application

What are some threats of a vulnerable Android code?

Android Malware and Security Issues

Android apps have serious threats from various types of malwares such as spywares, trozan, ad-wares etc. Although some of the malwares are not supposed to cause any harm, however, there are some malware which can lead to unexpected and undesirable problems like localized denial of service, abnormal battery drain etc. Moreover, malwares like Spywares can access a smartphone’s camera or microphone module to send data back to attackers. Adware is another type of malware that utilizes the existing various communication channels like Email, IM, MMS, Bluetooth or SMS etc. to transmit harmful advertisements to certain numbers of people. 

Security threats due to code de-compiling in Android

An extracted code can result in decreased security, freely available in-app purchases and can lead to misleading user data that could result in bad pricing elasticity. These are some of the common reasons why someone would de-compile your code, and you can now understand a little bit of the damage they can put you through. 

In Enterprise Mobile application development, security is even more of a concern as most of the apps are data-heavy such as Financial apps or Healthcare apps. 

We often come across threads like this one,

 A good company will never go behind their clients back and develop a similar app for a rival, and most developers won’t leave their name within the app’s code. However, a few developers leave their name inside the comments, which can then be used to extract the agency or freelancer that developed it. But that isn’t what I want you to take from this thread. By now, you should understand and notice that people are actively trying to decompile your apps, and you need to do something about it.

To further illustrate the seriousness, this thread clearly outlines how easily one can decompile your APK, even if it’s encrypted. Brendan was able to decompile a TwoFish encrypted paid app using just a few tools.

So, how do you stop anyone from gaining access to the source code?

How to avoid Android app decompilation to prevent reverse-engineering

In the above section, we saw how easy it is to decompile an Android app. In technical terms, an attacker only require to transform DEX files to JAR files and those JAR files back to source code. By doing so, it will become possible to extract an app’s source code. There are many tools which are used to reverse-engineer an android app such as dex2jar, Apktool, jd-gui, JAD etc. 

However, it is still possible to prevent reverse-engineering of Android app by taking care of few points. Let’s have a look at these points to ensure highest level of security to prevent the code decompilation in Android apps:

1) Put important code on a Server

You may rely on remote procedure calls to a well protected server.  This reduces the chance of your codes being stolen as the code will always remain on the server and nothing other than the results can be seen. However this does have a shortcoming, if your app is going to be used by a lot of users(millions), you will need to have a huge server farm.

A server farm is a huge expense and most of the time, is not a viable solution. Furthermore, in the case of low network connectivity, it leaves your code fragile and adds frustration for your users.

100% code security is costly, but the good news is that you probably won’t need it. A better solution is to keep the code that you don’t want to get out, in a hardware that you control. When you stop distributing the key parts, it makes the attacker’s work much more painful. Trying to protect all client apps also means a heavy investment and less ROI. Whereas safeguarding a server is much easier- both electronically and physically.

To add more security, you can also add double obfuscation to tackle any “man in the middle” attacks. Furthermore, the app will always send the received token to the server to request actions to be taken. Google Wallet is one such example, they rely heavily on tokens to process requests.

What else can you do?

Use Proguard

 It is an obfuscation tool that helps safeguard applications using a licensed server. It increases the difficulty of ‘reversing’ your code. DexGuard, a commercial version of Proguard, goes an extra mile and helps a little more. But your code can always be converted into samli, which can be used by developers to learn what you do with it. Again, if you don’t want others to see your code, don’t store it on their device.

2) Debugger Detection Techniques

There are some other creative ways to safeguard your code from decompiling. They involve using debugger detection techniques that you can utilize to prevent run-time-analysis and combine it with encryption of portions of binary codes. But, any enthusiastic attacker can find a way to work around it. If you are looking for more information on a specific debugger detection technique, you should have a look at OpenRCE Anti Reverse Engineering Techniques Database. It provides analysis and descriptions for various anti debugging, disassembly and dumping tricks. Many of the techniques are listed in conjunction with a specific target, but they may be adaptable to other targets.

3) Write important parts of code in C/C++

You can also write the important parts of your code in C/C++ and add them as a compiled library. While it can be disassembled into assembly code, reverse engineering a large library from assembly is extremely time-consuming. Java is easier to decompile in comparison to C/C++.

4) Write files natively into .so files

Using NDK you can write the files natively into .so files, which are much less likely to be decompiled than APKs. There are a few good decompilers available, but that would require the attacker to be proficient in ARM processor architecture, assembler language, JNI Conventions, and Compiler ABI. You are giving the proficient attacker a few sleepless nights.

5) Obfuscate values when storing them on mobile

For protecting your app’s resources when storing values on the device, don’t store them in a raw format. Store them in the form of some algorithm, i.e. 50 reward points in your app could be (x*(x^2 + 1 – Neutralizing factor))/(x+1). However, you need to optimize your algorithm so that you don’t end up on compromising while rounding up values.

6) Add multi-factor security

It is extremely important to stop the attacker from getting any access from the user’s device itself. You can also make the attackers work difficult by adding multi-factor security by remembering the information about the devices, and providing additional channels for identifying a login attempt from an unfamiliar device.

Some even suggest usage of tools like HoseDex2Jar, but it is very easy to defeat. In fact, tools like smali and apktools work fine with these APK’s.

How Matlab prevented their Android app from Reverse Engineering

One inspirational anti-piracy measure comes from Matlab, a desktop based software. Matlab protects the source of a deployed application by ‘Deploying as P-code’ or ‘Compiling into binary format’  This however does not apply to android, as it is open and rootable. The attacker can easily find the key from the system itself. Having access to the system implies having access to the keys.

The idea is to stall the attacker as much as possible. Sadly, a determined hacker can always access your codes, reach your server, watch your requests and find the keywords.

Take good note of the text below which arises from the principles of foundation of Information Technology security:

1. Whenever someone gains physical or electronic access to the machine, the machine belongs to the attacker.
2. An attacker cannot penetrate the code in your systems, but attacker can penetrate the code when it leaves the impenetrable physical boundaries.
3. When information leaves inaccessible boundaries, an attacker can always get that information.

7) Be careful while implementing SSL

Developers often implement SSL certificates for better security of their code over the server. On Android, it’s often done by defining several methods in a class that implements SSLSocketFactory interface. One issue with these types of methods is that they can accept all kinds of certificates which makes an Android code vulnerable to middle attacks (MitM). There is also huge scope of loss of confidentiality of data transferred through SSL/ TLS protocols. An attacker can easily breach the connection and get valuable data by simply providing self-signed certificate. Here’s why you need to be careful while implementing a SSL certificate on Android. 

8) Secure User Credential with extra-care

It is recommended to secure your user-credentials with extra security layer in order to avoid reverse engineering of the application. As a rule of thumb, the credentials should not be reused in many sites. This will prevent the likelihood of an app to reverse engineered. Moreover, the credentials should not be stored on the device. Wherever possible, use a short-lived authorization token to safeguard your account access. 

9) Use hash functions such as PBKDF2, bcrypt, scrypt

Majority of the hash functions such as MD2, MD5, SHA1 are not secure and prone to malware attacks on Android. Having said that, If they are used to store confidential information, security can be easily compromised. Instead, use secure functions such as SHA-2. A typical hash function should be resistant to collisions and not too fast. If a hash function is too fast, it complicates the attack by exhaustive search. For this specific purpose, specialized hash functions are developed such as PBKDF2, bcrypt, scrypt.

10) Encrypt your database to enhance Mobile Security

Mobile security in Android can also be enhanced by securing database files. If you are using SQLite then it is advisable to use SQLCipher extension which is completely open-source. Although, SQlite is quite popular among iOS developers, Android developers can also use the benefits of encryption thereby taking the utmost benefits of it in terms of security. 

Conclusion

By ensuring the above points, one can make Android reverse engineering harder for every kind of app. For starters, using proguard will provide your code from being vulnerable to malware attacks. However if you need highest order security for your Android app, it’s better to follow all the steps mentioned in the article. If you have any other methods for securing mobile apps from reverse engineering, shoot us a comment below.