4 things developers often overlook when securing their software
There are many ways applications can be hacked, and some of them are much easier than you might expect. In addition to adding licensing controls to your software, it is equally important to be reasonably vigilant about securing your applications and libraries.
While software licensing is its own topic, it should always be considered alongside software security. No software's security can be made truly impenetrable, but reasonable measures can and should be taken to mitigate risk. At a high level, software security comes down to a developer's healthy skepticism about how trustworthy the information available to an application really is.
For some sources of information, such as integration with a third-party service, cryptography is often already in place to help you establish trust that data actually came from a source you trust and has not been altered along the way. However, it is surprisingly easy as a developer to overlook your own innate trust of other sources of information. Securing your applications and code is, in large part, an exercise in verifying trust.
1. User input can be maliciously crafted
User input carries the potential to be crafted to trigger unintended logic or consequences. Weaknesses here can lead to issues such as SQL injection, or can be used to discover valid email addresses that are then targeted with spam or phishing attacks. Careful, methodical design and thorough input validation are the best ways to thwart these threats. Never assume that input arriving from a user, a file, or a network request is safe or well-formed.
2. Operating system and third-party APIs can be hooked
Operating system and third-party APIs can be "hooked," meaning the logic built into a function can be altered or bypassed entirely. For example, an API that retrieves the system date and time could be altered to always return the same value, either just for your application or for the entire system. You can mitigate this by performing basic tests that confirm an API is not being hooked or tampered with in this way before you rely on its results.
3. GUI APIs can be hooked or misused
Graphical interface APIs can also be hooked or misused. For example, a disabled button can still be triggered through a direct API call. Because of this, it is important to write code that double-checks whether an action should actually run, even when the control that normally starts it is disabled. Treat the state of a UI control as a convenience for users, not as a security boundary.
4. Third-party libraries can be replaced
Third-party libraries can be replaced entirely to substitute an attacker's logic for your own. For example, a library that exposes an IsLicenseValid function could be swapped for a library that always returns a true result for that function without running any of your validation logic. Generating and verifying a hash or digital signature of the libraries your application depends on lets you confirm they have not been altered when your application loads and uses them.
This list is not meant to be exhaustive. It is critical for developers to stay mindful and to proactively look for ways that an attacker could achieve something you never intended.
Securing .NET Applications
.NET applications compile to Microsoft Intermediate Language (MSIL) code, which can be reverse engineered more easily than native binaries. If you write your software in a .NET language, consider using obfuscation to make reverse engineering significantly harder and to better protect your intellectual property and licensing logic.
Using a Packer
"Packers" are applications that pack your original binary into a new binary. The benefit of packers is that they are quick and simple to use. The drawback is that they can sometimes cause compatibility issues and false positives with virus scanners.
Keep in mind that not all packers focus on security. Many (such as UPX) focus primarily on compression rather than protection, so choosing a packer with security in mind matters.
Within the SoftwareKey System, Instant Protection PLUS 3 (IPP3) and AutoCrypt SL are examples of packers that include added security features and can also add licensing to packed or wrapped applications.
Summary
Securing your software is always important, and it plays a crucial role in making sure your software's licensing is not compromised or bypassed entirely. There are many facets to software security, and many of them are easy to overlook. Focus on verifying trust at every boundary: validate user input, confirm that the APIs and libraries you rely on have not been tampered with, and never treat the state of a UI control as a security guarantee. Combined with reasonable obfuscation and a security-focused packer where appropriate, these practices make your application a much harder target.