Contact Desaware and order today! 

Sign up for Desaware's Newsletter for the latest news and tech tips.

Obfuscating .NET: Protecting your code from prying eyes
$39.95 [eBook]

FAQ

• Obfuscating Strong Name Assemblies
• Obfuscating ClickOnce Deployed Applications/Components
• Updates and Corrections

Obfuscating Strong Name Assemblies

The obuscation process modifes the executable file, which will cause a strong named assembly to fail validation. Use the SN.exe tool with the -R parameter to resign the executable after obfuscation. The obfuscation/resigning process can be combined into a single batch file.

Obfuscating ClickOnce Deployed Applications/Components

ClickOnce deployed applications have similar issues to the strong named issue, except that the manifests are also digitally signed and need to be recreated. To obfuscate a ClickOnce package you'll need to do the following:

1. Obfuscate each of the assemblies that you wish to obfuscate.
2. Resign each of the obfuscated assemblies.
3. Use the Mage.exe or MageUI.exe tool to update and resign each of the manifest and deployment files (.application and .manifest).

Updates and Corrections

The eBook and obfuscator have recently undergone an update for Visual Studio 2005. Assemblies obfuscated with the previous version of the obfuscator may not load or run under the .NET 2.0 framework. Those assemblies must either be bound to run under the 1.1 framework, or rebuilt and obfuscated using the 2.0 framework obfuscator that is now available (follow the link in your eBook).

The following corrections apply to the first edition of the book: Obfuscating .NET: Protecting your code from prying eyes. 

Error (unable to find dependency) when running Obfuscator.exe

Note - Download the latest release to resolve this problem for most scenarios.

When you obfuscate an application that has dependencies, the dependencies aren't found because the obfuscator EXE can't bind to them (due to .NET binding rules).

Think of it this way.

Lets say obfuscator.exe is in directory A, and your application and its components are in directory B

When your application runs, it finds it's components because they are in the same directory.

When the obfuscator runs (in directory A), it finds your main applciation in directory B because it loads it explicitely. However, it fails to load the components because they aren't in its own directory or in a directory that .NET will search.

The solution is either to move all dependent components to the obfuscator directory, or to copy the obfuscator program (and its dependencies) to your application's directory.

Page 60 - Mangler Class Constructor

Modified to load the assembly info from a copy of the PE file instead of the actual PE file. This prevents the lock of the file into memory.

Public Sub New(ByVal FileName As String)
    m_Control = New ObfuscatorEngine.Control(FileName) 
    ' Modification to prevent lock on file - DSA 3/29/02 
    Dim pefile As New IO.FileStream(FileName, IO.FileMode.Open) 
    Dim pestream As New IO.BinaryReader(pefile) 
    m_PEbuffer = pestream.ReadBytes(CInt(pefile.Length)) pestream.Close() 
    pefile.Close() 
     m_Assembly = [Assembly].Load(m_PEbuffer) 
    ' Modification end - DSA 3/29/02 
    ' Removed 3/29/02 
    '       m_Assembly = [Assembly].LoadFrom(FileName) 
    ParseManifest(m_Assembly) 
End Sub 

Page 64: - Parse Recursive Class

Corrected the logic to prevent obfuscation of protected fields that should remain visible. Modified again for version 1.0.0.0 release to use the BlockObfuscation flag to eliminate bug where one blocked member would block obfuscation of remaining members of a class. Download the latest code for corrected listings.

Page 69 - Reserved keywords.

The following lines in the FindProblemNames function:

resultlist.Add("Obfuscate")
resultlist.Add("DoNotObfuscate")
resultlist.Add("ObfuscateBlock")
resultlist.Add("..cctor")

Should be