Vendor: Protect Your Code and Your Customers

Security through obscurity is no security at all.  Obscurity does indeed add an extra level protection and should not be ignored all together.

When creating an application, a vendor should follow all best practices to protect their application/code from “reverse-engineering, tampering, invasive monitoring and intrusion” (Source:  OWASP calls this “Application Hardening and Shielding”.  Read more about that here:  The implications of not doing so can not only lead to theft of intellectual property (i.e. the source code), but it can also bring grave harm to customers and users of the application.

When a vendor is creating an application, especially a security application, consider how its core components are assembled (from a code perspective):

  • Scripts (ex. Powershell, VBScript, etc.): written in plaintext; code can be read in any text viewer and modified
  • Just-in-time (JIT) compiled languages (ex. C# .net, Java, etc.): easily reversible to readable code; modifiable (in most cases)
  • Machine compiled binaries (ex. C++, Go, etc.): require a bit of skill to read in its decompiled form (assembly); near impossible to reverse back to anything close that resembles the original code

No application/binary can be easily protected against disassembly (machine code to assembly).  When it comes to a security product, though, one should really consider using a language which does not allow an entry level attacker to recover the original high-level source code of binaries using script kiddie level tools such as ILSpy, jd[-gui], etc. The number of attackers who can read assembly as efficiently as Java or C# should also be given consideration.  It’s probably less than 1%, so raise the bar!

Although I am coming at this from a security perspective, do not forget about the typical performance difference between machine compiled, JIT compilations, and scripts. Machine compiled binaries are typically more efficient for thick applications.  So, even if your application will be open source, you will still want to consider this.

After following all of the OWASP recommendations (ex. detecting debug attempts), ensure you digitally sign it, and ensure all processes interacting with your application verify that signature.  This last step is by far the most vital step, even if you are not concerned with your source code (ex. open source).

Featured image courtesy of Kdsphotos and

Schedule a no obligation consultation with PEN Consultants today! Information & Cybersecurity Testing - Penetration Testing, Red Teaming, Vulnerability Scanning and Assessment services for Apps, Web Apps, Network, Wireless, and more!

Categories: Blog