How To Protect Mobile Apps Against Reverse Engineering

Talking about the smartphone industry, it’s inundated with numerous apps. Mobile app security has turned into a buzzword in today’s advanced technological landscape and needs developers’ focused efforts to build and manage mobile apps. As millions of mobile apps flood the app sector, so do the vulnerabilities and security threats afflicting them. One such threat is reverse engineering, which can cause serious repercussions specifically for the fintech/banking/e-wallet industry, from revenue loss to intellectual property compromises. App developers must inculcate robust security features in apps to manage this threat expeditiously and secure apps from inadvertent sabotage.

What’s Mobile App Reverse Engineering?

Mobile app reverse engineering is the process of examining the compiled application to extract information about the source code and other resources that help in making an APK file. There are multiple tools available through which DEX (Dalvik Executable) files are decompiled to JAR files, and after that to Java source code. Competitors can use reverse engineering techniques to see your app’s functionalities and copy a few features stealthily. Cybercriminals may use this to access your app’s premium features by bypassing the verification process.?

Why Does Banking Apps Security Testing Include Reverse Engineering Process?

To Allow Black-Box Testing

Many apps include controls that hinder dynamic analysis. End-to-end encryption and SSL pinning sometimes prevent you from manipulating or intercepting traffic with a proxy. Moreover, root detection may prevent the application from running on a rooted device, stopping you from utilizing advanced testing tools. Therefore, you must deactivate such defenses.

To Improve Static Analysis

During black-box testing, static analysis of the app’s binary code helps you determine the app’s internal logic and identify flaws like hardcoded credentials.

To Evaluate Resilience

Apps that implement MASVS-R (Mobile Application Security Verification Standard Anti-Reversing Controls) protection measures must withstand reverse engineering. To determine the effectiveness of controls and for the resilience assessment, the security team should attempt to bypass the defenses by following the techniques of reverse engineering.

How To Protect Mobile Apps Against Reverse Engineering?

Save Crucial Code On The Server

You may depend on remote procedure calls to a firmly secured server. This minimizes the chances of code being stolen as it always remains on the server, and only the results can be seen. However, there is one shortcoming, if millions of users are going to use the application, you will need a vast server farm.?

A server farm is expensive and not a viable solution, and in case of poor network connectivity, it causes frustration for users and leaves the code fragile. Code security is essential but costly, but a better solution is to keep the code in the hardware you control. When you don’t distribute the essential parts, the attacker’s work will become much more complicated. Trying to secure all client apps means less ROI with heavy investment, but safeguarding the server is more manageable – both physically and electronically.?

To add an extra layer of protection, you can add code obfuscation to combat man-in-the-middle attacks. Moreover, the server always gets the received token from the app to request the action that needs to be taken.

Debugger Identification Techniques

There are multiple ways to safeguard the code from decompiling. One such method is debugger identification techniques that can be used to prevent runtime analysis. There are several debugger identification techniques and if you want to learn more about it, check out the OpenRCE Anti Reverse Engineering techniques database. This database provides the disruption and analysis of multiple disassemblies, debugging, and dumping tricks. This resource helps reverse engineers identify, locate and bypass such tricks and tactics.?

Use C/C++ Language To Write Important Parts Of Code

A Java code is easier to decompile as compared to C/C++ code. Therefore, write the critical code in C/C++ and add that as a compiled library. Though it can be turned into assembly code, however, reverse engineering of the massive library from the assembly is significantly cumbersome and time-consuming.?

Furthermore, use NDK to write the crucial code natively into .so files, which is unlikely to be decompiled than .apk files. There are few advanced decompilers available, but that would need the hacker to be proficient in assembler language, ARM processor architecture, Compiler ABI, and JNI Conventions.?

Secure User Credentials

It’s recommended to secure the user credentials to prevent the app’s reverse engineering. It’s preferred to utilize an authorization token instead of seeking user credentials frequently. It will allow the application to prevent phishing attacks likely to be unsuccessful. Besides that, the device should not store usernames and passwords. The authentication process of the application can be automated, but it will need user credentials. In such circumstances, the credential object should be used that contains sign-in information.

Secure API Keys

Generally, API keys are used by third-party providers to provide access to the resources. It’s advisable not to save the API keys in preferences, resources folders, shared assets, or as a hardcode in Java because it can be unzipped to decompile the API. Use public/private key exchange or NDK to secure API keys.

Be Cautious While Implementing SSL

Developers implement SSL certificates for enhanced security of the code over the server. An SSL certificate helps encrypt a resource and authenticate the identity. While implementing SSL, multiple methods are defined by the class, which implements an SSLSocketFactory interface (on Android). The shortcoming of these methods is that all certificates can be accepted, which makes the code vulnerable to man-in-the-middle attacks. There is a big chance of loss of data confidentiality if it’s being transferred through TLS/SSL protocols. A cybercriminal can breach the connection and get the data by giving a self-signed certificate. Therefore, be cautious while working with SSL certificates.

Hashing Algorithm

Many hash functions such as SHA1, MD2, MD5 are unprotected and prone to attacks. If you use such functions to save information like passwords, contact details, etc., confidentiality can be breached easily. Therefore, use secure functions like SHA-2. Additionally, the hash function must be resistant to collisions and should not be too fast. A fast hash function complicates the cyber attack by exhaustive search.

Use Of Reflection Insecurely

It’s possible to execute arbitrary harmful code. The argument interpreted by the method applying reflection function is generally from an untrusted source. This enables the cybercriminal to manage the app’s control flow graph, allowing them to bypass verification mechanisms and gain access to multiple restrictions.

To prevent this, build a whitelist of commands in an app and ask the users to select only from that list. Never use user-entered data as a method for applying reflection. Ensure to maintain the uniqueness and integrity of the configuration files during their use with reflection. Configuration files should never set reflection parameters if resources are absent for security analysis.?

Why Should Fintech/Banking Apps Protect Against Reverse Engineering?

People have an excellent level of trust in banking apps as they protect our funds and assets. Since mobile banking usage is growing immensely, it’s essential for fintech/banking firms to stay ahead of cyber adversaries. Cybercriminals reverse engineer banking apps to determine how the app runs and insert malicious code to steal user credentials or trick the consumer into downloading/installing an app’s modified version. Another threat to banking apps is banking trojans that can monitor/record keyboard usage, including the data typed into a system, which might contain usernames, passwords, emails, as well as financial information such as credit card numbers.

Banking apps also seek security from overlay attacks. When trying to steal user credentials, the overlay attack uses the mobile ecosystem’s vulnerability to create a fake login that covers up the regular mobile banking login. Overlay attacks are usually successful since they strike unexpectedly. Moreover, mobile malware is another growing threat. Advanced malware is able to root the device, allowing users to attain root access or privileged control over Android subsystems and ultimately modify the code of banking applications to perform payments that have not been approved.

Therefore, banks and financial institutions are now aware of the complexities of creating reliable security measures for applications. It requires insights into various fields of expertise and is both time-consuming and complicated. Consequently, these firms are now turning towards vendors that offer easy-to-integrate and ready-to-use security solutions. One efficient solution is app hardening, which is the process of protecting mobile apps against tampering and reverse engineering. App hardening makes it much more tricky to manipulate the app, thereby thwarting numerous cyber threats while making the app immune to both dynamic and static analysis. Static analysis refers to the cyber-attack where the attacker attempts to decompile the app on a local machine. On the other hand, dynamic attacks manipulate apps by using hooking frameworks or debugger tools.?

App hardening is crucial specifically for banking apps to defend against IP theft, vulnerabilities exploitation, data misuse, tampering, etc. Moreover, runtime threat monitoring is also vital for minimizing insider threat risks and increasing data protection capabilities. Firms are in a stronger position to defend against outside and insider threats when they have complete visibility into data usage and access and can enforce data security policies to prevent confidential data loss.