4 things developers often overlook when securing their software

By Abram P | General Licensing Tips

Feb 15

There are many ways applications can be hacked, some of which could be much easier than you might expect. It is consequently important to be reasonably vigilant about securing your applications and libraries.

While software licensing is its own topic, it should always be discussed with software security in mind. It is important to know that it’s unreasonable to expect any software’s security to be impenetrable, but reasonable measures can be and should be taken to mitigate risks, as outlined in our previous article, 5 Blatant Truths About Software Licensing Systems and Piracy.

You wouldn’t give your credit card number over the telephone, if you didn’t trust the person on the other side. Similar precautions should be taken when developing applications.

“Distrust and caution are the parents of security” -Benjamin Franklin

At a high level, achieving software security is accomplished through a developer’s skepticism regarding the trustworthiness of information available to the application. For some sources of information, such as integration with a third-party service, things are often already designed to use cryptography as a means for you to establish trust that the data has actually originated from a source that you trust, and that it has not been altered. However, it is surprisingly easy as a developer to overlook your own innate trust of other sources of information.

Securing Your Software

Securing your applications and code is an exercise in verifying trust. Here are some things to be mindful of that can be particularly easy to overlook as a developer:

  1. User input carries potential to be maliciously crafted to carry out some unintended logic or consequence. Weaknesses in this regard could lead to issues such as SQL injection, or could be a means to find valid email addresses to target as recipients of spam or phishing attacks. Careful and methodical design and input validation are the best ways to thwart such threats.
  2. Operating system and third-party APIs can be “hooked,” whereby the logic built into the operating system’s function may be altered or bypassed entirely.  For example, an API to retrieve a system’s date and time could be altered to always return the same value (either for just your application, or the entire system). This can be mitigated by performing basic tests to ensure an API is not being hooked or tampered with in this manner.
  3. GUI APIs can also be hooked or misused. So for example, it is possible that a disabled button could still be clicked through an API call, which makes it important to have code that double-checks whether or not it should run even if said button is already disabled.
  4. Third-party libraries could be replaced entirely to substitute your logic for a desired outcome. For example, a library that has a IsLicenseValid function could be replaced with a library that always returns a true condition for this function without running any of your license validation logic. Generating and verifying a hash or digital signature of libraries you rely upon will allow you to verify they have not been altered when your application loads and uses them.

Of course, this list is not meant to be an exhaustive one. It is critical for developers to be mindful and proactively search for means whereby hackers can achieve what you did not intend.

.NET Applications

.NET applications compile to “Microsoft Intermediate Language” (MSIL) code, which can be reversed engineered more easily. If you use .NET languages to write your software, read more about protecting your intellectual property with obfuscation.

Using a Packer

“Packers” are software applications that “pack” your original binary into a new binary. The benefit of packers is that they are very quick and simple to use.  However, 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. For example, many (such as UPX) focus primarily on compression.

Within the SoftwareKey System, Instant Protection PLUS 3 and AutoCrypt SL are examples of packers that include added security features, and also add licensing to packed/wrapped applications.

Conclusion

Securing your software is always very important, and plays a crucial role in ensuring your software’s licensing is not compromised or bypassed entirely. There are many facets to securing your software, and many things can be easy to overlook. If you’re currently using or considering using the SoftwareKey System, and you have questions, our team is just a click or a call away. Contact us here.

About the Author

Abram Pousada is one of the passionate Software Engineers with SoftwareKey.com. He started his career with SoftwareKey.com when he was in high-school and has been with the company for over a decade. After-hours, the self-proclaimed geek enjoys a variety of engaging hobbies ranging from even more programming to video games and mountain biking.