Protecting and Licensing .NET Applications

.NET has seen a surge in its popularity as a development platform since 2018, powered not least by the multiplatform capabilities introduced with .NET Standard. According to the Tiobe Index, C# currently ranks in fifth spot as a choice for developers in .NET, outranked only by Python, C/C++, and Java. Python is particularly in demand for internal projects or automation use cases, as Java is for servers, and .NET for end user devices. For traditional standalone and client applications, it is safe to say that .NET is a sure second choice alongside C/C++.

Security matters, and it matters especially when applications are run out in the field, on an end user’s device. This is true for the end users themselves, as they don’t want their machines affected by malware or other harmful code, which is usually avoided by solutions like signed code. But it is also true for software developers who want to protect their work from piracy or IP theft. .NET differs from C/C++ in that the source code does not go through a compiler to run as machine code on a specific platform. Instead, it is turned into intermediate code that can still run on multiple platforms. The downside to this is that the intermediate code remains accessible for snooping and tampering by would-be attackers. License checks can be removed or replaced by forged ones, and business secrets contained in the code may simply be stolen.

Our answer: AxProtector .NET from our CodeMeter Protection Suite. AxProtector .NET works perfectly with code signatures, meaning developers do not have to make that decision between security for the end user or protection for their own IP. They can, and should, have both.

AxProtector .NET makes clever use of the easy legibility of the intermediate code: it extracts all the classes and methods contained in a .NET assembly and encrypts them piece by piece. The encrypted code is then placed back instead of the original code.

During runtime, the methods are decrypted on the fly when they are called for. The actual intermediate code remains in the device’s working memory only for a brief moment to run through the Just In Time Compiler (JIT) and create the machine code, and then it is erased from memory. A native C/C++ component, CPSRT, takes over part of the decrypting and runs cyclical security checks in the background. By comparison to a straight-up .NET solution, adding this native component increases the security of the system again. CPSRT is available for most common platforms and processes, including Windows, macOS, Linux, Intel x86 and x86-64 as well as ARM and AARCH64. It does not normally mean any limitation to the application’s ability to run on multiple platforms.

In our webinar, we will take a look at how AxProtector .NET works:

• Encrypting an assembly
• Modelling different licenses in an assembly
• Best practices for applications with multiple assemblies
• Security: Binding the encryption to a license
• Security: Obfuscation
• Security: Anti-debugging measures to ward off dynamic analyses
• Security: Traps against static analyses
• Security: Moving code into CmDongles or CmCloudContainers
• Integration in automatic build systems
• Handling errors
• A look ahead at the roadmap for AxProtector .NET

Security is not the only thing we care about: Performance matters as well. By caching the native code, AxProtector .NET means minimal loss in performance in real-life usage. AxProtector .NET is the unique combination of top performance and exceptional security.