Protect Android App from Reverse Engineering

Android appeared to have 130 security holes in 2022, according to an analysis provided by Cvedetails. Memory corruption accounts for 21% of the total, while Execute code accounts for 23%. These are both severe issues that allow malicious code to run. This is unfortunate news to Android developers because most of their customers are dealing with such security issues.

The two most discussed topics these days are security and privacy. Android apps, like any other piece of code, can be targeted, putting your users’ data in danger. In addition, your app may be reverse-engineered.

The best strategies for protecting an Android app against reverse engineering will be discussed in this post. Let’s start with an explanation of reverse engineering. What are the application’s business and technical consequences of reverse engineering?

What is Reverse Engineering?

Because of its open-source nature, Android has a wide following. Although being popular, android has a negative side too, namely vulnerabilities. Android provides app developers with a significant benefit that most mobile platforms don’t. Since it is open-source, developers and reverse engineers can efficiently study the source code at the Android Open Source Project (AOSP) and tweak it as they see fit for their requirements. In a nutshell, Reverse engineering is a technique used by engineers to re-obtain source code to rebuild a program, build something comparable to it, find a flaw in an app, or improve its security.

Technical Impacts and Business Implications of Reverse Engineering

Some of the technological and business consequences of reverse engineering are listed below.

Technical Impact

An attacker could use reverse engineering to hack the Android app. Here are some important data assets they can get access to:

• They can reveal backend server information
• Cryptographic constants and ciphers can be revealed
• Intellectual property can be stolen using this method
• Attacks on backend systems can be carried out
• Can obtain the data required to make the last code changes

Business Implications

Reverse engineering has many different business implications. Here are a few examples:

• Theft of personal information
• Identity theft threatens your reputation
• Backend systems compromise

Also Read: – Android App Development Libraries

How to Know if my Application is Vulnerable to Reverse Engineering?

Because of the intrinsic nature of coding, nearly all applications are vulnerable to reverse engineering. The majority of today’s programming languages include a lot of metadata that can help a coder troubleshoot an app. This functionality also greatly assists an attacker in gaining a better understanding of how the app functions. If an attacker can perform any of the following, an app is said to be vulnerable to reverse engineering:

• Recognize the elements of a binary’s string table.
• Perform cross-functional analysis correctly.
• From the binary, create a reasonably accurate reproduction of the source code. Although most apps are vulnerable to reverse engineering, it’s crucial to consider the risk’s possible business impact when deciding whether to mitigate it.

Top 5 Android Vulnerabilities to Exploit your Android Application

Cyber Vulnerabilities can pose an issue for businesses in terms of data loss, sensitive data exposure, Insider attacker, and other vulnerabilities. It is not practical to sort them by severity, impact, or frequency of these vulnerabilities. Below mentioned are some of the 5 popular android vulnerabilities as well as the method to mitigate them:

1. Insufficient Jailbreak/Root Detection
2. Server Information Leakage
3. Improper Certificate Validation
4. Insufficient Authorization/Authentication
5. Session Expiration

Insufficient Jailbreak/ Root Detection.

Data protection and encryption measures on the OS are bypassed when a device is rooted in android or jailbroken for iOS. When a device is infiltrated, it can run any malicious code, substantially modifying the application logic’s intended function. Generally, recovery and data forensic programs function on rooted devices as well.

Server Information Leakage

Data Leakage is an application vulnerability where sensitive data, such as technical details of the application, details of the ecosystem it works in, as well as user data is exposed. An attacker may use the sensitive data to comprise the target program. It can attack the network it’s hosted and compromise the applications on the network. The sensitive data should be protected using various encryption techniques. Information leakage can be caused by the following circumstances:

• Unable to wipe out HTML/Script remarks containing sensitive data
• Incorrect application or server setups
• variations in page replies for legitimate versus invalid input.

Improper Certification Validation

This application either does not validate SSL/TLS certifications or uses an SSL/TLS certification validation method that does not adequately check that a trusted issuer issued the certificate. If the certificate can’t be confirmed or isn’t provided, the client should be set up to drop the connection. Any data sent over a connection with a certificate that hasn’t been adequately validated may be vulnerable to unwanted access and modification. If the certificate can’t be confirmed or isn’t provided, the client must be set to drop the connection. Any data sent over a connection with a certificate that hasn’t been adequately validated could be accessed or modified by an unauthorized party.

Insufficient Authorization/Authentication

When an application fails to complete necessary authorization checks to guarantee that a client is executing a task or accessing data following the security policy, it is referred to as insufficient authorization.

What a user, service, or app is authorized to perform should be enforced through authorization procedures. For example, when a user logs in to a website, this does not automatically imply that the user has complete access to all material and capabilities.

Session Expiration

The IDs used throughout the session are expected to be invalidated after just a user logs out of an application. This is because other users could spoof that user and undertake actions on their behalf if the server is down to expire the session IDs.

Also Read: – Best Android Development Tools (ADT) List to Know in 2024

How to Prevent Android Application from Reverse Engineering?

Before we go into how to protect an Android app from reverse engineering, let’s look at how to prevent an Android app from being reverse-engineered. But first, let’s look at how it works in basic terms. For easy comprehension, it can be stated as follows: An android application is simple to decompile. In a nutshell, an attacker merely needs to convert DEX data to JAR files to succeed. Back to the source code for those JAR files. The source code of an app can then be extracted. Many tools, such as dex2jar, Apktool, jd-gui, JAD, and others, are used to reverse engineer an Android app.

However, by paying attention to a few details, reverse-engineering Android apps can be avoided. Let’s have a glance at some of these points to maintain the maximum level of security and prevent Android apps from being reverse-engineered:

1. Tamper Detection

The most secure approach to telling if your program has been tampered with is to double-check that the identity used to sign it is the same as your own. In most circumstances, the Play Store will be the sole option to access your software. For example, we could verify the installation source and disable the program if it is not downloaded through the Google Play Store. If you wish to see if a debugger has been hooked to your app, you can use the following code:

guardDebugger({
//No debugger tools detected continue executing the code.
}, {
//Some debugger tools were detected.
})

To verify the source code you can do the following:

this.verifyInstaller(Installer.GOOGLE_PLAY_STORE)?.let {
if (it) {
// App is installed from Google Play
} else {
// App is not installed from Google Play
}
}

Lastly to verify if your app has been modified or not you can check the signature of your app like this:

if (this.validateSignature("INSERT YOUR RELEASE SIGNATURE HERE") == Result.VALID) {
// Signature is valid continue using the app
} else {
// Signature is invalid likely a modded version of the app
}

2. ProGuard Assistance

This is a cross-platform open-source tool that was created by. This is a Java-based cross-platform open-source program that helps secure mobile apps. It’s a command-line application that shrinks, improves, obfuscates, and checks code before running it. Here’s how it works:

• Shrink Method: Remove any unnecessary classes, fields, or methods characteristics from the mobile app.
• Optimization: study and improve the bytecode of several methods
• Obfuscation: The rest of the classes, fields, and methods are given short, meaningless names.

By making the codebase smaller, more efficient, and intricate, the preceding stages make it more difficult to reverse engineer an application.

• Pre Verification: Pre-verification information is added to JME, Java 6 or higher, classes required.

It is worth noting that shrinking, obfuscation, and code optimization are not enabled by default when you create a new project in Android Studio. The reason for this is that these optimizations increase build time and, if not done properly, may induce issues. As a result, when generating the finished product of your app to test before releasing, it’s advisable to execute these compile-time activities. Include the following in your project’s build. gradle file to enable compression, obfuscation, and optimization. The “minifyEnabled true” option is the most important item to notice here because it enables Proguard.

android { 
    buildTypes { 
        release { 
            // Enables code shrinking, obfuscation, and optimization for only 
            // your project's release build type. 
            minifyEnabled true 
            // Enables resource shrinking, which is performed by the 
            // Android Gradle plugin. 
            shrinkResources true 
            // Includes the default ProGuard rules files that are packaged with 
            // the Android Gradle plugin. To learn more, go to the section about 
            // R8 configuration files. 
            proguardFiles getDefaultProguardFile( 
                    'proguard-android-optimize.txt'), 
                    'proguard-rules.pro' 
        } 
    } 
    ... 
}

Here in the code, you can see the file named ‘proguard-android-optimize.txt’ which is a file generated by android which includes some set of rules. However, if you want to include rules such as -dontskipnonpubliclibraryclasses option, you can add it in the ‘proguard-rules. pro’file.

Even though ProGuard is used, it has a few drawbacks that can be easily fixed or can be dodged easily:

• ProGuard is unfamiliar with the APIs or naming conventions. These settings will have to be entered manually. And this configuration syntax is meant to be simple, clear, descriptive, and universal
• ProGuard now copies the manifest and resource files without any changes. In contrast, there are no directory entries in the output jars. If your software is dependent on these components, you should change or add them manually.
• Private or package viewable library classes are always ignored by ProGuard. You must use the -dontskipnonpubliclibraryclasses option if any of these private packages are installed. The checkbox for this option is located here.
• The obfuscated jar may have class names that may conflict with class names in the library jar if the input jar contains classes from the same package. As a result, packages should never be separated into input and library jars.
• The obfuscation marker interface may not be handled properly by ProGuard. If you give “-keep class * implements MyKeepInterface” and MyKeepInterface is not included in your code, for example, the specified classes are retained but obfuscated.

Deobfuscators, such as APK De-guard, are available to prevent obfuscation. It employs machine learning, making it one of the most precise and efficient deobfuscators available.

3. Obfuscate values when storing them on mobile

The native-code element of an Android application is shared libraries.

Appdome alters Android’s shared library loading process to allow for the loading of encrypted libraries. The native libraries that come with the program are then encrypted using a unique key when incorporating Binary Code Obfuscation.

When an attacker uses a reverse engineering tool (such as IDA-Pro or Hopper) to open the protected libraries, the programs fail to recognize the files as binary code.

4. Transfer Critical Data to Server

Another technique to protect android apps from being reverse engineered is to transfer the code out of the app and into an encrypted server-side language web service.

For example, if a company’s program has a unique code or algorithm, it would not allow that code to be stolen. They can avoid this by simply changing their code or algorithm and allowing the data to be processed on a remote server, then accessing the data through the application.

5. Use C/C++ to write important code

Java code is much easier to decompile than C/C++ code. As a result, some developers use the NDK to add the necessary code directly. So files. They also incorporate such files in a library they’ve created. Although this code may be broken down into assembly language, reverse engineering such a vast library can be time-consuming and difficult.

6. Be careful while applying SSL

Developers use SSL to enhance the safety of their code when dealing with the server and device.

There are various basic methods in the class that utilizes the SSLSocketFactory interface. However, because these simple methods accept any certificate, the application is vulnerable to middle-man attacks (MitM). As a result, data transferred via the SSL/TSL protocol may lose confidentiality.

An attacker can easily break the connection and steal valuable data by just presenting a self-signed certificate.

7. Use PBKDF2, bcrypt, and scrypt hash algorithms.

On Android, most hash functions, such as MD2, MD5, and SHA1, are insecure and vulnerable to malware. However, security can be quickly undermined if used to hold confidential information. Secure functions like SHA-2 should be used instead. A standard hash function should not be overly quick and resistant to collisions. By conducting an exhaustive search, a hash function that is too quick complicates the attack. Therefore, specialized hash functions like PBKDF2, bcrypt, and scrypt were explicitly created.

8. Securing User Credentials

To avoid reverse engineering of the application, it’s good to keep the user credentials safe.

• The number of times a user’s credentials are requested in a mobile app should be reduced. This will help the apps avoid phishing assaults, which are more likely to fail. It is recommended that you use an authorization token.
• The passwords and usernames should not be kept on the device. It’s good to finish the initial authorization and utilize a temporary authorization token.

The app’s proprietors will need user credentials to automate the app’s authentication procedure. Use a credential object to store user sign-in information in such circumstances.

Also Read: – How to Optimize Android App Performance in 2024?

9. Hide API Keys

Third-party suppliers typically offer access to resources using an API key. They frequently use it to profit from their data. It’s not a good idea to save API keys in shared assets, resource folders, preferences, or as a Java hardcode. This is due to the ease with which they can be unzipped and the API decompiled to obtain the key. To safeguard the API key, use NDK or a private/public key exchange.

10. Hashing Algorithm

The hash functions MD2, MD5, and SHA1 are the most vulnerable. If devices are being used to store passwords and personal information, they can easily be hacked. Instead, secure functions like SHA-2, AES 256, and such should be implemented.

A standard hash function must not be too fast and should be collision-resistant. A hash function that is too fast complicates the assault by completing an exhaustive search. For this reason, specialized hash functions such as PBKDF2, bcrypt, and scrypt were devised.

11. Use of Whitelist Commands

Malicious code can be executed at will. The method implement reflection function frequently accepts an argument from an untrustworthy source. This allows attackers to manipulate the control flow graph, bypassing authentication and gaining access to restricted areas. To circumvent this, make an allowlist of commands you want in an app and ask users to choose from it. Avoid directly employing user-entered data as reflection methods.

While using configuration files with reflection, keep their integrity and uniqueness in mind. Do not set the reflection parameters in the configuration files if you don’t have the resources for security analysis.

12. Avoid Using External Storage

All apps can access files saved on external storage devices. When a user connects a USB storage device to a computer, it can quickly be altered.

The files are still available in external storage if the application is deleted. However, it could lead to the disclosure of sensitive information. As a result, storing files in internal memory or using the SQLite database is recommended.

13. Database Encryption

Another way to keep an Android app safe from reverse engineering is to use data encryption. Many individuals assume it is too time – a consuming process to encrypt data in databases. This isn’t correct. Most databases now have tools that allow users to encrypt and decrypt data without manually doing so. SQLCipher, for example, is a popular SQLite Extension that supports AES256 encryption. Encryption technology from Realm has also been installed.

14. SafetyNet

Google’s SafetyNet is a tool that assists developers by recognizing if an app is running on a rooted device and determining whether the user is attempting to edit critical files made by your app to intercept critical information. How to use SafetyNet and how to integrate it is a lengthy discussion that could turn into a new topic in and of itself

15. Add Multi-Factor Security

It is critical to prevent the attacker from gaining access to the user’s device. You can also make it more difficult for attackers by implementing multi-factor security, which remembers device information and provides extra channels for detecting a login attempt from an unknown device. Some even recommend using programs like HoseDex2Jar. However, this is extremely difficult to defeat. Smali and apktools are compatible with these APKs.

Wrapping Up

These are a few tips and tricks which can help you protect Android apps from reverse engineering. Reverse engineering can provide a way to steal the source code of the android application. Using proguard and other such tools will provide the safety layer for your android application from various cyber-attacks. And encrypting your data using hash algorithms and other encryption techniques should be used for encrypting important files and that will make it hard to crack the source code. The above-mentioned Android Reverse Engineering Protection tips will provide an extra layer of security to your android application.