PHS Dotfuscryptor – Details

PHS Dotfuscryptor – Details

ph solutions‘ PHS Dotfuscryptor provides you a comprehensive .NET assembly protection and packaging suite. In order to better understand the advantages PHS Dotfuscryptor offers compared with other approaches and products, it is necessary to have a closer look at both the compilation and the reflection process as employed by the .NET Framework as well as the fundamentals of the widely used protection technique of obfuscation.

.NET Compilation

In contrast to native applications, during the compilation step, the source code written in one of the .NET languages such as C# or VB.NET is not directly translated into corresponding sequences of opcodes. Rather, the output of the inital .NET compilation process is the so-called Common Intermediate Language Code (CIL Code). Together with the Metadata, which contains additional information about the classes, methods and data fields, the CIL Code is put together to a .NET assembly by one of the .NET Compilers. When a .NET application is launched on the target system, the Metadata and the CIL Code are jointly fed to the .NET Just-In-Time Compiler (JIT Compiler), which translates them into a platform specific native application code (opcodes).

.NET Framework


In some sense, the CIL Code represents the common denominator of all .NET languages. Consequently, the CIL Code can easily be retranslated into one of the .NET languages. The Metadata contained in the .NET assemblies offer additional information for this retranslation process and make the retranslation less ambiguous and allow for it to be performed automatically. As a result, in contrast to native applications which require a high level of expertise and experience, .NET applications can be disassembled, edited and reassembled to ready-to-run modified .NET assemblies even by non-professionals. Consequently, for .NET applications an effective protection against industrial spying, reverse engineering (protection of your intellectual property) or manipulation (copy protection, implementation of different software editions such as trial versions) is almost impossible.

.NET Reflection


One possible counter measure to evade this problem is the widely-used obfuscation, which post processes the .NET assembly after the compilation step. The goal of the obfuscator is to disguise the internals of the application, such that a possible attacker is kept from manipulating the assembly or restoring its original source codes. For this purpose, the obfuscator performs various modifications to both the assembly’s metadata as well as its CIL Code.


These modifications include (allegedly) harmless measures such as renaming variables, methods and classes to cryptic, non-printable names as well as rather invasive approaches such as the „result-equivalent“ manipulation of the program flow. Based on the design of the .NET Framework, the protecton approach based on obfuscation has several major drawbacks:

  • Serious modification of the assembly’s codebase
  • Plaintext string literals and other resources containing potentially sensitive informations unaffected
  • Restrictions in the availability of powerful concepts such as reflection
  • Huge amount of trust in the vendor required
  • Planned usage has to be considered already early in the development process
  • Later use or upgrade complicated

PHS Dotfuscryptor

In contrast to this somewhat to security-through-obscurity related principle, ph solutions‘ PHS Dotfuscryptor takes an entirely different approach. As a result, the above mentioned restrictions and drawbacks do not apply to PHS Dotfuscryptor. More precisely, instead of trying to confuse possible attackers, the protection provided by PHS Dotfuscryptor relies on strong cryptography. Both the assembly’s metadata as well as its CIL Code as such are left entirely unchanged. In addition to this, the .NET applications protected by PHS Dotfuscryptor start as native Windows applications and launch the .NET Framework Runtime on demand.


Consequently, neither the protected assembly’s Metadata nor its CIL Code are accessible for a reflector. At assembly runtime, however, both components are fed to the JIT Compiler in their exact original form, allowing for the exact original native executable code to be generated and executed. Compared to the protection through obfuscation, this yields the following advantages:

  • No modification of the assembly’s codebase (no modification of the program logic)
  • Implicit protection of plaintext string literals and embedded resources
  • No restrictions to the availability of concepts such as reflection (no name mangling)
  • Independent of the development process
  • Upgrade possibly at any time

In addition to this, PHS Dotfuscryptor offers additional valuabe features. These include an assembly packaging mechanism as well as a debugger protection facility. While the former allows for embedding and protecting additional assemblies referenced by the startup assembly, the latter enables you to protect your application against external debugging.

Overview ← → Features