Wise Owl - Brent Rector go to the microsoft .net expert
go to logingo to accountgo to cart
  go to home go to products go to training go to about go to purchase go to contact

Demeanor for .NET, Enterprise Edition

Obfuscator features

Add to cartDemeanor for .NET, Enterprise Edition provides the most sophisticated obfuscation and optimization available for your .NET applications. Demeanor for .NET performs three categories of obfuscation - symbol obfuscation, metadata obfuscation and control flow obfuscation. All forms of obfuscation are lossy. In other words, the process throws away information making it unavailable for a decompiler.

Ease of Use

Demeanor for .NET is the most powerful and the easiest to use .NET obfuscator. Demeanor always maintains application compatibility when obfuscating an assembly. It never obfuscates types and members in such a way as to violate an assembly's public interface to other assemblies. Unlike other obfuscators, Demeanor for .NET does the "right things" without tedious configuration. It just works, right out of the box. With Demeanor for .NET, you never have to set hundreds of XML configuration entries in order to use the product.

Works on all your code, regardless of programming language

Demeanor for .NET properly obfuscates your .NET applications regardless of the programming language you use. You can develop in any .NET programming language and Demeanor for .NET can obfuscate your assemblies. Unlike other obfuscators, Demeanor for .NET can obfuscate assemblies written in all of the Microsoft managed languages including C#, C++ with Managed Extensions, CIL, J#, and VB.NET.

Works on all your code: single- and multi-module assemblies

Of course, Demeanor for .NET can obfuscate your single file dll or exe assembly. However, in many ways, that is a trivial case. Some developers choose to build an assembly as a multi-module assembly for two common reasons: they want faster incremental assembly download or they have a multi-language assembly.

As far as we know, Demeanor for .NET is the only obfuscator that properly obfuscates a multi-module assembly.

Works on all your code: multi-assembly applications

Demeanor for .NET can obfuscate your entire application. Normally, when you obfuscate an assembly, the obfuscator must not change the names of any types and members that are accessible from outside the assembly. For example, a client application (an .exe) binds to the public types and members of its dependent assemblies (typically .dll's) using the names of the types and members.

However, quite often, an application may use one or more DLLs exclusively. In this case, you can request entire application obfuscation and Demeanor for .NET will remove all the original symbolic information from all of your assemblies.

Works on all your code: multi-cultural applications with satellite assemblies

Many applications today must support multi-cultural environments. The .NET Common Language Runtime makes developing such an application much easier than it was previously due to the Runtime's support for managed resources and satellite assemblies.

Most obfuscators blindly rename symbols in an assembly without considering all the effects the renaming has upon the correct operation of your code. Demeanor for .NET understands the relationships between an assembly and its associated satellite assemblies. When Demeanor for .NET obfuscates each primary assembly, it also makes the appropriate changes in all of the assembly's satellite assemblies.

Incremental obfuscation

Add to cartYou may want to ship a new version of an assembly that was obfuscated with entire application obfuscation. With entire application obfuscation, assemblies reference types in other assemblies using their obfuscated type and member names. In order to ship a new version of a single assembly that was obfuscated as a set, an obfuscator must insure that types and members in the new version receive the same obfuscated names as they had in the previous version. Demeanor for .NET can maintain assembly compatibility by reusing the same obfuscated names during incremental obfuscation.

Command line utility

Many developers build their product using makefiles or NANT. They want an easy to use command line utility version of an obfuscator. With Demeanor for .NET, obfuscating an entire application including the .exe file, all of its dependent assemblies, and, for each assembly, all of the 202 possible associated satellite assemblies is as easy as:

Demeanor -app -sa MyApp.exe

Visual Studio .NET integration

Other developers prefer to work exclusively within the Visual Studio .NET environment. Demeanor for .NET includes Visual Studio .NET integration. When you build a solution, Visual Studio .NET builds each project in the solution and obfuscates it as desired. You set the obfuscation properties for each project using a Visual Studio .NET property page.

Assembly optimization as well as obfuscation

While testing Demeanor for .NET against many .NET assemblies, it averages an 8-12% *reduction* in size. For example, Microsoft's System.Windows.Forms.dll assembly is 2 MB before obfuscation and 1.8 MB after obfuscation. This causes an obfuscated .NET assembly to download faster (as it's smaller), to load faster (for the same reason) and to run more efficiently in memory (as it occupies fewer pages). Approximately 1/2 - 2/3 of the size reduction comes from the fewer symbols present in the metadata. The remaining size reduction comes from Demeanor for .NET's smarter and more efficient code and metadata generation.



Obfuscation techniques


Symbol obfuscation

ildasm pictureThe metadata in a .NET assembly contains the original source language symbolic names and types for all your classes, interfaces, methods, fields, properties and events. In fact, there are only two types of source file information that aren't also present in the binary assembly, your comment statements and the names of your local variables.

To someone trying to steal your intellectual property, these symbolic names are the most useful and valuable information present in the assembly. Removing as much of this symbolic information as possible greatly increases the effort (and therefore cost) required to reverse engineer your application. If you've ever tried to debug a program without debug symbols, you've seen this difficulty first hand. However, there are two crucial aspects to symbol obfuscation that many obfuscator vendors seem not to understand.

First, an obfuscator must discard the original symbols. Some first-generation obfuscators compute the replacement symbol using the original symbol. For example, such an obfuscator might simply encode or permute the original characters in the symbol. This technique provide zero intellectual property protection. A decompiler targeting that obfuscator can simply retrieve the original symbolic names by reversing the transformation. By discarding the original name and selecting an independent replacement name, a decompiler cannot retrieve the original name. Another way to state this is that the symbol transformation must be lossy.

Second, given a lossy symbol transformation, any replacement symbol choice is as good as any other choice with respect to its obfuscation value. Specifically, you get no more obfuscation by assigning as many items as possible the same name than you get from assigning every item a different name. In other words, there is no obfuscation benefit to symbol overloading.

The goal of obfuscation is to modify an application so that it is harder to reverse engineer. This requires the obfuscator to make more difficult both human and automated attacks. An obfuscation difficult for a human to understand is often easy for an automated tool to handle, and vice-versa. A quality obfuscator should use techniques difficult for both kinds of attacks.

Symbol overloading is a trivial obfuscation. A decompiler can undo the overloading by simply assigning new names to all symbols during decompilation. Note therefore that it doesn't matter what name an obfuscator gives a symbol once it has discarded the original symbol. Any choice is as good as any other choice because a decompiler gets to choose last.

That said, symbol overloading isn't a bad technique. It's just no better than any other replacement symbol algorithm in terms of its obfuscation benefit. However, there is a reason to overload names as much as possible. It minimizes the number of names in the metadata tables thus allows a .NET assembly to be smaller.

It's ironic that some second-generation obfuscators overload symbol names for the wrong reason and get a positive benefit as an accidental result. These obfuscators take advantage of the fact that many languages let you overload method names. For example, in C# and VB.NET, you can give multiple methods the same name as long as the method signatures are different. Most programmers only overload related methods. Second-generation obfuscators overload unrelated methods in a misguided attempt to increase the confusion factor of the code and in a valid attempt to reduce the number of symbols. Here's an example of how such an obfuscator might overload method names in two classes:

internal class d {               internal class e {
   private void a() { }             private void a() { }
   private void a(int a) { }        private void a(string a) { }
   private int b;                   private int b;
   private double c;                private double c;
}                                }

However, Demeanor for .NET far out-performs such simplistic name overloading algorithms. We at Wise Owl have devising a unique Name-Signature overloading algorithm that allows far more overloading of all symbol names - types, fields and methods - than method overloading. This, in turn, means that Demeanor for .NET greatly reduces the number of symbols in the metadata of your application and that reduces your application's size. For example, Demeanor for .NET will obfuscate the above example as follows. Note the following isn't legal C# but is a faithful representation, using C# syntax, of the obfuscated metadata declarations.

internal class a {               internal class b {
   private void a() { }             private void a() { }
   private void a(int a) { }        private void a(string a) { }
   private int a;                   private int a;
   private double a;                private double a;
}                                }

Even in this simple case, the original example has five symbols while the Demeanor for .NET technique only requires two symbols. As a more influential example, when Demeanor for .NET obfuscates the Microsoft assembly System.Windows.Forms.dll, it throws away ~10,000 symbols and replaces many of them with a single symbol.

Metadata obfuscation

Add to cartDemeanor also obfuscates your application's metadata. Some of the metadata present in a .NET application is not used by the Command Language Runtime during program execution. It is used only during development and by programming tools, like Visual Studio .NET, and compilers such as C# and VB.NET.

For example, the runtime understands fields and methods, but in many senses, knows nothing about properties and events. Properties and events are higher-level abstractions used by programmers and tools but which are actually implemented in terms of methods. Demeanor for .NET removes the metadata that describes your properties and events, renames the property and event methods to meaningly symbols, and removes the association that relates a property's or event's to one another.

For example, assume that your application contains a single obfuscatable property called 'AccountBalance' that has two related accessor methods called 'get_AccountBalance' and 'set_AccountBalance'. After obfuscation, your application contains no properties and two methods with meaningless names like 'a' and 'b'. This is a lossy transformation. A decompiler cannot regenerate the property and it cannot determine that the two methods have related functionality.

Demeanor for .NET also performs many other metadata obfuscations. For example, in many cases, it can discard the original accessibility of fields and methods. A decompiler no longer knows how accessible to declare your members. Generally, it has no alternative other than to declare the members using public accessibility. Lots of public fields and methods makes code harder for a human to understand.

String literal encryption

The string literals in an application often provide extremely useful information to someone atempting to reverse engineer the application. For example, a developer could disassemble or decompile an application, search for all uses of the string "password", and concentrate on understanding only the code that uses the literal.

Demeanor for .NET can encrypt all your string literals and inject the necessary code to decrypt the strings at runtime. You do not need to make any changes to your source code to support this functionality. Demeanor for .NET 's string encryption technique works with compilers, such as some Microsoft compilers, that occasionally use identity tests to determine string equality. This user-controllable feature slightly increases the size of your application and the generated code runs slightly more slowly due to the need to decrypt the literals during execution.

Directly obfuscates your binary assembly
Does not try to round-trip using ILDASM and ILASM

Demeanor for .NET makes a copy of all modules of your original binary assembly, then directly obfuscates the binary modules. Because Demeanor for .NET directly modifies the assembly's .DLL and .EXE (portable-executable) files, it can improve the memory layout of your application. In fact, Demeanor for .NET reorganizes the contents of your assembly to be considerably more memory-efficient than the assemblies currently produced by all Microsoft tools. This causes your assembly to load more quickly, execute faster and use a smaller virtual memory working set.

Other less capable tools do not have the ability to perform such optimizations to your assemblies. Some disassemble your assembly using Microsoft's ILDASM utility, then obfuscate the IL source file, then attempt to compile the IL source file using ILASM. There are constructs that can be present in an assembly that will not survive a disassemble, then reassemble, round-trip. Obfuscators using this approach can potentially break your application. In addition, such tools have no ability to optimize the structure of the assembly like Demeanor for .NET does.

Selectable symbol exclusion

You may need to exclude certain types and members from obfuscation. For example, when explicitly using Reflection or when using late binding in VB.NET (which internally uses Reflection), you access a type or member by its original, unobfuscated name. Because Reflection occurs at runtime after you've obfuscated the assembly, it's critical that you not obfuscate the name of any members accessed via Reflection.

Demeanor for .NET allows you complete control over the obfuscation process. You can specify that a particular type, method, field, event or property is excluded from obfuscation. Alternatively, you can use one or more regular expressions to describe the names of the types and members that Demeanor should not obfuscate.

Control over obfuscation via configuration file or custom attributes

Some developers prefer to leave their source code unchanged and specify all obfuscation options, such as excluding a symbol from obfuscation or the specific name to use when obfuscating a particular type or member, via a separate configuration file. Demeanor for .NET allows you to control all obfuscation options via a separate configuration file.

Other developers prefer to place obfuscation directives directly in their source file. Demeanor for .NET allows you to provide a custom attribute attached to a type or type member that specifies whether to obfuscate the type or member and, when obfuscating it, various obfuscation options.


We license each copy of Demeanor for .NET to a specific developer. Our license allows a licensed developer to install Demeanor for .NET on up to two computers as needed for the developer's sole use. However, you must purchase a separate license for each developer that will be using Demeanor for .NET.

For example, when ten developers produce a product protected by Demeanor for .NET, but only two of the developers will be using Demeanor for .NET to obfuscate the product, then you must buy two licenses.

We decided we'd rather not charge a per-copy-sold royalty for software protected with Demeanor for .NET as that's quite cumbersome for you and for us. Similarly, we also decided not to price Demeanor in other sales volume related ways.


Add to cart

Due to the success of our recent special promotion, we are now offering Demeanor for .NET, Enterprise Edition at the new, lower price of US$ 799 per license. This is a great discount from the original price of US$ 1,450.

A license for Demeanor for .NET entitles you phone and email support for 90 days as well as free updates to your licensed version. For example, when you license version 3.0, you are entitled to all updates to version 3.0 free of charge with no time limitations. We believe you should get any bug fixes we produce to your licensed product without your having to pay an annual maintenance fee. In addition, owning a license for any major version of Demeanor for .NET entitles you to purchase a license for a higher major version of Demeanor for .NET at the reduced price of US$ 599.

    Please subscribe to the Wise Owl newsletter and we will keep you informed of the latest updates to Demeanor for .NET. To subscribe, send an email to: wiseowlsoftware-subscribe@yahoogroups.com.

for Software Products