Anyone developing software applications today can easily feel overwhelmed by the persistent security threats their products face, ranging from application counterfeiting and malware injection to service theft and the theft of confidential information. This article discusses how hackers conduct their dirty deeds and how to achieve a balanced perspective on application risk and risk management, enabling you to release applications with greater confidence. Gaining this confidence requires a deeper knowledge of the risks and potential remedies.
If Willie Sutton were alive today, he wouldn’t rob banks, he’d be a hacker “because that’s where the money is.” Yesterday’s bank robber is today’s hacker armed with a decompiler and a debugger instead of a Tommy gun and dynamite.
A hacker might first try to reverse-engineer your source code to better understand how the application works. Unless your application is open source, there is no good reason to “give” your source code away. Let’s consider the risks of developing applications with managed code, specifically .NET or Java. Chances are, you’ve got some managed applications driving your business. However, managed code is almost ridiculously easy to reverse-engineer; literally anyone can download free tools that automatically reproduce the source code from the executable at hand, which can then be inspected and modified. Native applications such as iOS can also be reverse-engineered, but the available native tools don’t produce high-level source code as decompilers for .NET and Java do.
A sample of free reverse engineering tools is listed below:
| Platform | Free reverse engineering tools |
|---|---|
| .NET | dotPeek, ILSpy |
| Java/Android | JD-GUI, AndroChef |
| iOS | IDA Pro, Hopper, and r2. |
Having the reverse-engineered source code in hand makes it easier to use debugging tools to step through code and inspect what is going on.
Some free debuggers are listed below:
| Platform | Free debugging tools |
|---|---|
| .NET | Visual Studio, DotNet IL Editor |
| Java | Eclipse, Android Studio |
| iOS | LLDB, GDB |
So, now that we know how hackers investigate your code, let’s look at possible nefarious things a hacker might do with your application source code and a debugger in hand.
A hacker could make unauthorized code modifications, disable security and validation controls, bypass licensing restrictions, insert malware, change purchasing requirements, or add displays in the app. They could potentially release:
Source code analysis can reveal the presence of hardcoded credentials, data encryption conventions (or lack thereof), and sensitive information. Hackers could view the value of strings, passwords, and data utilized by your application. Depending on the nature of your application, this may be a very serious risk. HIPAA, PCI, FISMA, and other regulations recognize that data cannot be effectively managed without control over the systems that create, manage, and distribute that data. Knowledge of an application’s internal workings and the ability to modify its behavior can be used to access and distribute sensitive or regulated data.
Identity thieves sometimes examine an application’s inner workings and its data to steal information about the organization and its customers, then pose as the company’s employees. For example, auditors have identified managed code modules in an online banking application that reveal information identity thieves could use to impersonate bank employees. After an impostor earns the customer’s trust and convinces them that they are employed by the bank, collecting personal information becomes relatively easy.
Classic application vulnerabilities, such as SQL injection or cross-site scripting, can be discovered without access to source code. However, with the source code, hackers do not need to use the “trial and error” method for discovering vulnerabilities. They can examine the code directly to look for vulnerabilities—perhaps ones they never even thought to test. Once they know where the vulnerabilities are, they can exploit them to access confidential information or circumvent validation checks.
Whether you’re building applications for sale, as a key part of a larger financial or manufacturing business, or as part of a line of business apps for internal use, there is likely to be IP (trade secrets) within your software. And possession of functioning source code provides transparent access to any IP embedded in the application. So, a hacker that works for a competitor might be able to rip off some of your technological advancements by reviewing your source code.
From a Legal perspective, there are three common ways to protect the IP embedded in your code:
Although patents offer the strongest protection, patenting software requires a lengthy, expensive, and complex certification process. For the vast majority of software builders, a patent just isn’t a workable IP protection solution. In contrast, copyright protection is automatic. You don’t need to mark up your code, etc., and copyright law is the basis of most software licenses. However, it comes with its own big issues; it’s limited to copying and distributing content.
You can’t copyright algorithms, innovations, or inventions, so if someone else’s code looks nothing like yours or that organization can demonstrate they developed their code in isolation from yours, they’re in the clear. And with managed code, where someone else can generate the same algorithms as yours in multiple languages, copyrighting an application offers little real protection.
That leaves trade secrets, which have a lot going for them. There’s no certification, they last forever, and they include concepts, innovations, etc. that give your business a financial and competitive advantage. That’s why trade secret protection under the law is increasingly the regulatory strategy of choice for many development organizations.
Sounds perfect, right? Well, trade secret protection has two significant limitations. First, some major jurisdictions simply don’t recognize the legal concept of a trade secret. The other limitation of trade secret protection is even more fundamental: unlike copyrights and patents, it only covers things that are actually secret. Once something becomes public, it can no longer be protected as a trade secret.
More specifically, the definition of trade secret theft requires that possession of a trade secret be achieved through improper means, such as bribery, blackmail, or espionage. Recently enacted trade secret laws, both in the United States (the DTSA) and the European Union, specifically permit reverse-engineering of any legally acquired product. If reverse-engineering your application yields your source code, and therefore, your algorithms, such algorithms may no longer be secrets and no longer covered by trade secret protection.
The freely available tools for managed code that make reverse engineering and tampering almost trivial have very legitimate uses within the larger development community. As with all powerful technologies, reverse engineering and application modification can be used productively, but also for mischief. A portfolio of protection technologies has emerged and matured over the past two decades, and it is in use across industries.
As with any risk-based strategy, there is no “one size fits all” approach, but for many applications, doing nothing is no longer an option. PreEmptive Solutions protects intellectual property (trade secrets) and code integrity, and ultimately reputation and revenue against piracy, theft, counterfeiting, and tampering. Our layered security and obfuscation protection is directly infused into your .NET, Java, and Android applications, and that means we do not require an agent or changes to your end user’s computer/device or network. And our protection technology travels with your app wherever it goes. We help you manage application risks and make sure you are not making life easy for your hacking “friends.”
If you’re looking to strengthen your app security without sacrificing performance or user experience, explore how PreEmptive can support your team’s security strategy with a free trial!