KNOWLEDGE BASE

The Knowledge Base section of our website compiles common questions and answers, sorted by product. This new format should improve information access, compared to the previously implemented forum pages. If you have a question and you do not see it here, you may submit it by filling our our Knowledge Base Submission Form. All submissions will be considered for inclusion on this page. If you need immediate support and have a current support contract, please contact our support team.


Dotfuscator ProfessionalDotfuscator CEDashO Professional


Dotfuscator Professional


Error: Could not find a compatible version of ildasm to run on assembly <assemblyname>. This assembly was originally built with .NET Framework <version>

Dotfuscator uses ildasm and ilasm to process the input assemblies. Ildasm is the MSIL disassembler that ships with the .NET Framework SDK. Ilasm is the MSIL assembler that ships with the .NET Framework Redistributable.

Dotfuscator attempts to match each input assembly with the toolset that ships with the version of the .NET Framework that it was compiled with. So Dotfuscator will use the 1.1 versions of ildasm and ilasm on an assembly compiled on the 1.1 version of the Framework; likewise, it will use the 2.0 tools on an assembly compiled on the 2.0 version of the framework.

If Dotfuscator cannot find the version appropriate toolset for an input assembly, it will use a later version if present. It will never use an older version.

You can specify the version of ildasm/ilasm for Dotfuscator to use by adding the following project properties:

Name: ILASM_version, ILDASM_version formatted in the following way: ILASM_v2.0, ILDASM_v2.0
Value: Full path of ilasm/ildasm

Error: External Type Not Found

If the assembly on which an input assembly depends is not found then Dotfuscator gives the following error while writing obfuscated assemblies: 'External type not found typename, assemblyname, Version=.....'

The solution is to add the directory of the dependent assembly to the User Defined Assembly Load Path.

What affect does the option Library Mode have on input assemblies?

The option Library mode tells Dotfuscator that the input assembly or assemblies constitute a library. For obfuscation purposes, a library is defined as assemblies that are going to be referenced from other assemblies not specified as one of the inputs in this run.) This has implications for renaming and pruning, regardless of any custom excludes you may have set.

Renaming implications:

  • Names of public classes and nested public classes are not renamed. Members (fields and methods) of these classes are also not renamed if they have public, family, or famorassem access.
  • In addition, no virtual methods are renamed, regardless of access specifier. This allows clients of your library to override private virtual methods if need be (this is allowed behavior in the .NET architecture).
  • Any user-specified custom renaming exclusions are applied in addition to the exclusions implied by the above rules.
  • Property and Event metadata are always preserved.

Pruning (Removal) implications:

  • Public classes are not removed, even if static analysis determines they are not required.
  • Fields of these classes are not removed if they have public, family, or famorassem access.
  • Methods of these classes are not removed if they have public, family, or famorassem access. In addition, such methods are treated as entry points, so their call trees are followed and all subsequently called methods are also protected from removal.

Dotfuscator CE


How do I properly obfuscate the VB.NET My namespace used in my application?

When a type gets renamed, Dotfuscator removes property metadata. When an application uses the My namespace, it uses the properties of the types in the My namespace. For the property metadata to be retained, the solution is to exclude from renaming only the type names in the My namespace (the methods and fields will be renamed).

Below are two custom rules that excludes all type names in the My namespace.

<type name='.*My[\.]My.*' regex='true' />

<type name='.*My[\.]Resources.*' regex='true' />

How is a library obfuscated?

Dotfuscator defines a special global option called library. This option has to be set for the obfuscation of control libraries. This setting tells Dotfuscator that the input assemblies constitute a library. For obfuscation purposes, a library is defined as assemblies that are going to be referenced from other assemblies (or native code) not specified as one of the inputs in this run.

<global>
  <option>library</option>
</global>

Renaming Rules for library:

  • Names of public classes and nested public classes are not renamed. Members (fields and methods) of these classes are also not renamed if they have public, family, or famorassem access.
  • In addition, no virtual methods are renamed, regardless of access specifier. This allows clients of your library to override private virtual methods if need be (this is allowed behavior in the .NET architecture).
  • Any user-specified custom renaming exclusions are applied in addition to the exclusions implied by the above rules.
  • Property and Event metadata are always preserved.

Pruning Rules for library:

  • Public classes are not removed, even if static analysis determines they are not required.
  • Fields of these classes are not removed if they have public, family, or famorassem access.
  • Methods of these classes are not removed if they have public, family, or famorassem access. In addition, such methods are treated as entry points, so their call trees are followed and all subsequently called methods are also protected from removal.

How do I properly exclude all members of all Enums from renaming?

<!--Select all type names that are enumerations but do not exclude them from renaming -->
<type name='.*' regex='true' excludetype='false' speclist='+enum'>
  <!-- Of the selected types, exclude all fields from the selected types from renaming -->
  <field regex='true' name='.*'/>
</type>

To apply the custom rule from the GUI:

  • Go to the 'Exclude' tab under 'Renaming'
  • Click the 'Add Type' button. This will create a custom type rule in the rule editing view located on the right pane.
  • Below the rule editing view, enter in the 'Name' field the regular expression '.*' and check the 'Regular Expression' checkbox. Having the 'Regular Expression' checkbox checked will tell Dotfuscator to interpret the 'Name' field as a regular expression.
  • In the 'Spec' listbox, select '+enum'. This says you want to select enumerations that match the regular expression.
  • Ensure that the 'Exclude Type' checkbox is unchecked. We only need this type rule in order to specify what fields we want to exclude from renaming.
  • Right click on the type rule in the rule editing view and select 'Add Field.' This will addd a custom rule in the rule editing view as a child of the parent type we had created earlier.
  • As with the custom type rule, below the rule editing view, enter in the 'Name' field the regular expression '.*' and check the 'Regular Expression' checkbox in order for Dotfuscator to interpret the 'Name' field as a regular expression.

To preview the effects of a single rule in the rule editing view, right click on the rule's node and select 'Preview' from the menu. Items selected by the rule will appear shaded in the application tree view. To preview the combined effects of all the rules defined in the rule editing view, click on the 'Preview' command button. All items selected by applying all the rules will appear shaded in the application tree view.

The above custom rule should exclude from renaming all fields within enumerations.


DashO Professional


How can I rename the dynamically loaded classes?

To rename the dynamically loaded classes turn on 'FORNAMEDETECTION' and 'RENAMEFORNAME' options. Using the fornamedetection option instructs DashO to automatically include all the possible dynamically loaded classes. The renameforname option allows dynamically loaded classes to be renamed.

<global>
   <option>FORNAMEDETECTION</option>
   <option>RENAMEFORNAME</option>
</global>

How can I integrate DashO into my automatic build process?

DashO can be integrated into any Ant build script by running the Java task. If you are using Ant build script, you add the following target to run Dasho:

<target name='dasho'>
  <java fork='true' classname='DashOPro' classpath='${dasho.home}/DashOPro.jar'>
   <arg value='-v' />
   <arg file='project.dox' />
  </java>
</target>

How are the serialized classes obfuscated?

Since serialization relies implicitly on the makeup of a given class, you typically need to exclude these classes from Renaming and Removal.

If your application is brand new (i.e. there are no existing serialized objects anywhere) then you may not need to worry about this section. Classes that were serializable before DashO will be afterwards also.

If you have persistent objects already in existence, then you will need to identify what classes they were created from before running DashO. As you can imagine, method/field removal and renaming will make reloading these objects impossible. The simple solution is again to exclude these classes from Renaming and Removal.

DashO now automatically keeps fields with the name 'serialVersionUID' intact (no removal or renaming ) to facilitate compatibility between Java releases. In addition, if the readObject() and writeObject() methods of Serializable classes are present, DashO will automatically treat them as entry points.