Traditional software intellectual property (IP) protection tools typically rely on obfuscation and/or encryption/decryption and provide only limited protection against hackers. Obfuscation modifies .NET modules in a way that complicates human readability of a decompiled program. This is achieved by renaming meaningful names of methods, classes, parameters, etc. to meaningless text. It also attempts to make the resulting Microsoft Intermediate Language (MSIL) harder to disassemble. Obfuscation does not change calls to third party or .NET Framework libraries nor does it modify the structure of the program (classes, methods). A determined hacker, therefore, can still succeed at reverse engineering obfuscated code.
Encryption/decryption offers limited protection as an encrypted assembly has to be decrypted before it can execute. Since the decryption engine together with the decryption keys are delivered to end users, the original code is retrievable if the decryption process can be somehow reproduced or intercepted, for example, by stopping it in a debugger. Additionally, when decrypted modules load into memory, they load in their original, unprotected form – any motivated individual hacker can dump the memory and retrieve the code.
Both aforementioned methods introduce a side effect in the protected application. Reflection can no longer be applied to the protected assembly to obtain information about the methods, fields, etc. of the assembly at runtime. This makes functionality relying on reflection unavailable. In summary, the traditional methods offered to protect .NET assemblies make it difficult for a hacker to recover the original source code from the protected assembly, but still feasible.
Transforming Code with Software Potential Code Protector
Software Potential Services introduces a new, sophisticated approach to help protect .NET applications. It has advantages that are not available with traditional solutions, introducing several layers of protection, called transformation. Transformation is a one-way process based on permutation that is unique to each software company’s product. Software Potential Services provides a Secure Execution Environment (SEE), which includes several layers of protection. The protection process transforms the Intermediate Language (IL) code into Secure Execution Environment Language (SEEL), and as an added measure of protection, encrypts the resulting in-memory buffer. Transformation offers an extremely high level of protection against reverse engineering and tampering.
The Software Potential Code Protector component applies code protection to selected methods within a .NET assembly using a software publisher-specific permutation. To securely protect .NET applications more securely a separate permutation is used for each individual product to be protected.
Software Potential Code Protector, as part of the build process, takes selected features or methods within an assembly and transforms them into a software publisher-specific language – SEEL – that has a software publisher-specific instruction set. A method that is transformed to SEEL is conceptually running in what amounts to a secure virtual hardware environment (SEE).
End-users of licensed or protected applications receive only this transformed code, drastically reducing visibility to disassemblers and decompilers and the risk of using a memory dump to view the code.
The strong protection provided by Software Potential Services lies in the fact that transformation is random and one-way – from MSIL to SEEL. Conversion from SEEL to MSIL is a complex process making decompilation of transformed code extremely arduous and impractical. Each SEE is its own unique challenge. Protection is further enhanced relative to the traditional solutions, because the protected code is only ever processed within the SEE. All license enforcement measures, (either standard built-in checks or custom code you write to extend it) can be transformed in this way, affording it this significant layer of protection.
Which Protection?
It is surprising just how many ISVs continue to compromise their IP and ignore the revenue leakage and the concerns of potential investors. Choosing the appropriate level of protection depends to a large degree on the nature of the application. If the .NET Code is unique and high value with individual methods that warrant attention it should certainly justify the use of strong code protection. This may be slightly more expensive initially but it will provide payback in the long-term. Some ISVs may even use both Obfuscation and Transformation together if they are seriously concerned about their code being cracked. Some protection is obviously better than none and as with guarding your property it usually better to err on the side of caution.
