Today more than ever, applications are mobile and can be run worldwide. And many useful apps access sensitive data and have value-added functionality within them (such as trade secrets). Because traditional firewall type attacks are much more difficult today, hackers are increasingly targeting both consumer and enterprise mobile and desktop apps as a newer attack vector. So, those apps may be at risk from theft of IP/underlying sensitive data, malware injection and more advanced targeted threats.
If the answer to both is no, then you may be less at risk to hacking, theft and tampering. You can stop reading.
If the answer is yes to either, then you should strongly consider “hardening” your application by incorporating enhanced security state checking, code obfuscation and encryption before it is released. These steps will complicate the reverse-engineering, debugging and tampering process and increase resistance against compromise and exploitation. They will help move a DevOps process to a DevSecOps process.
Because of free and easily available tools, reverse engineering of code has become a common practice for outsiders wanting to understand how to compromise an application, to bypass security checks and controls or get at underlying data. For some applications, unmanaged access to source code can also pose material risks including application vulnerability exposure, increased likelihood of system attack, theft of intellectual property, privacy violations, and revenue loss through circumvention of usage and other metering enforcements. Techniques such as obfuscation and encryption can make it materially harder to reverse engineer code by breaking the reverse engineering tools and/or making the output extremely hard for a human to follow.
In addition, applications can be made to be resistant to tampering. This might involve automatically inserting overlapping and redundant checks to determine if an application was modified in any way. Or detecting if an application is begin run in a jailbroken device that might compromise some of the safety guarantees. Exploitation of applications can take many forms. For example, by using a debugger on a production application, a hacker without any special privileges can:
The hacker could view encryption functions and the values of dynamic keys and observe when and how sensitive information is saved to file systems and databases. Or, they might modify and release a tampered version of an application to bypass controls (such as license checks), or inject malware code to collect and transmit data, etc.
An effective debugger detection, defense, and mitigation strategy might include:
The same techniques could be applied to tampered apps, apps running on a jailbroken device and other conditions that could lead to an app’s integrity being compromised.
For sensitive or high value applications, organizations in virtually every industry are incorporating application hardening and obfuscation into their DevSecOps process. Because many of these techniques are applied at the binary level they can be difficult or error-prone to apply manually. Fortunately, an application hardening and obfuscation tool can easily be added to the end of your build process making your apps more resistant to reverse engineering and hacking.
If you are building with .NET, a free tool called Dotfuscator Community Edition is included in Visual Studio can get your team started today. https://docs.microsoft.com/en-us/visualstudio/ide/dotfuscator/
If you are building with Java, a free tool called Proguard is available and can get your team started. https://sourceforge.net/projects/proguard/
If you are building for iOS, a free tool called PPiOS-Rename is available and can get your team started. https://github.com/preemptive/PPiOS-Rename
Of course, commercial full featured solutions are also available at https://www.preemptive.com/preemptive-protection