Reverse engineering and code modification present significant security and business risks. They allow for malicious hackers (or competitors) to easily gain access to your proprietary source code, including your algorithms, ideas, data formats, licensing, security mechanisms, and potentially even your customer data.

Java files, like the ones that make up many applications, including mobile applications, are easy to decompile and reverse-engineer. This is due to the very properties of Java itself; what allows it to run seamlessly on multiple platforms, also allows the reverse translation back to source code very straightforward and easy to accomplish.

As it stands today, many applications do not utilize source code protections. This means that anyone with access to installer or the installed files has unfettered access to that application’s source code. With that access they can easily create a clone of your product, inject malicious code into it and redistribute it, create malicious programs or code that expertly attack your product, and even find previously unknown vulnerabilities in your code.

In addition to these information security risks, there is also the business risk since all of your intellectual property in that application is now easily made available through techniques that a person with only average skill can perform in moments with popular open-source tools. Not to mention any damage that can be done if they discover any vulnerabilities or customer data within the application. However, there are ways to help protect against these weaknesses, such as using obfuscation and encryption.

While it is unlikely to fully eliminate these risks, you can take steps to mitigate them. The Open Web Application Security Project (OWASP) offers several suggestions:

• Apply Integrity Controls – Develop a method that allows the program to check the integrity of its files.
• Deter and Discourage – Make it so time-consuming, difficult, and expensive to violate your application that it would become impractical.
• Code Obfuscation – Transform program code and their control flows to an unintelligible form.
• Symbol Stripping and Renaming – Remove unused program symbols from application binaries, and change commonly understood program symbol names to irrelevant names.
• Encryption – Encrypt as much of the application as possible. This can and should be extended to encrypting the application installer, which will render the installer useless without the decryption passphrase.
• Damage – Replace sensitive regions with decoy or garbage code when not in use, and replace with the original code when in use.
• Root / Jailbreak Detection – Determine if the mobile device is rooted or jailbroken during run-time of the application.

Additional measures can also be taken such as inserting anti-debugging logic and checksums to deter reverse engineering and tampering. Features such as self-repair logic to re-create files that have been tampered with, instituting standard reactions and alerts to notify users that something has gone wrong, and shutting down to prevent any damage are all ways to ward off or respond to an attack.

Keep in mind that all of these most likely cannot be instituted at once and each of them comes with some form of concession, typically in the form of additional costs, time, or performance tradeoffs. However, they should each be considered and tested for best fit into your applications.

Commercially available tools provide many of mitigations mentioned above, while other solutions may need to be developed in-house. While there are several open source tools available, security researchers have started to suggest that some of them do not provide sufficient obfuscation, but they should be considered along with the commercial software as well. Keep in mind that due to the fundamental principles of open source tools, anyone (even the bad actors) can see what the tools are capable of, and react accordingly.

Unfortunately, many business leaders are concerned with the short term results – like saving development time and increasing performance – and in doing so, they fail to take into account the potential security risks of unprotected code.  There is no perfect solution when it comes to code security, but if you follow the OWASP suggestions, you will be on the right path to protecting your code, your intellectual property, and your business.