Dotfuscator code Obfuscation FAQ

• What is Obfuscation?
  
• Why Obfuscate?
  
• What Java and .NET applications should be obfuscated?
  
• Does Java or .NET obfuscation affect performance?
  
• What is Compaction?
  
• Why Compact?
  
• What is Software Watermarking?
  
• What factors should be considered in selecting a Java or .NET obfuscation tool?
  
• Why do I need Tamper Detection and Notification?
  

Dotfuscator

• What are the differences between the Professional and Community Editions of Dotfuscator?
  
• Can I get an evaluation copy?
  
• Is Dotfuscator a profiling tool?
  
• Does Dotfuscator change the source code of my application?
  
• Does Dotfuscator require me to distribute any additional libraries or programs with my final application?
  
• How does Dotfuscator obfuscate assemblies?
  
• What is PreEmptive Solution's patented Overload Induction^TM ?
  
• Why would I use obfuscation to hide application vulnerabilities? Wouldn't I be much better served by simply ensuring that I have no vulnerabilities?
  
• How does Dotfuscator work on API libraries?
  
• What is String Encryption?
  
• What is Incremental Obfuscation?
  
• What is Control Flow obfuscation?
  
• What happens when I try to use a decompiler on an application run through Dotfuscator Professional?
  
• What is Enhanced Overload Induction?
  
• Can I run Dotfuscator on my ASP.NET pages?
  
• Can I run Dotfuscator on my Windows Forms application?
  
• Can I run Dotfuscator on my .NET Compact Framework application?
  
• What is Assembly Linking?
  
• What versions of .NET and Visual Studio does Dotfuscator support?
  
• Is there a way to declare in my source code which items I want to exclude from obfuscation?
  

Technical

• Can I use regular expressions to exclude or include certain types, methods, or fields?
  
• How do I integrate Dotfuscator into my automated build process?
  
• My assembly has a strong name. How can I use Dotfuscator when the obfuscation process would invalidate the signing of the assembly?
  
• Why can't I just use NGEN to compile my assemblies into a native code before shipping to my customers?
  
• What about a tool that converts your assemblies into native format and applies encryption?
  
• Can Dotfuscator process applications that use reflection?
  
• Is the use of typeof in C# always OK?
  
• What if I need to do a lookup by name?
  
• Can uses of codebehind methods in *.aspx and *.ascx files be obfuscated?
  
• Is remoting a problem for the obfuscator?
  
• The Framework uses reflection to find the name of the type and append .resources to the type name. Is this a problem?
  
• I have heard that XML Serialization "serializes an object and uses the names of the members, as determined at runtime, as the XML element names." Is this a problem?
  
• Is Late Binding a problem? I am thinking of the uses of Assembly.Load and InvokeMember.
  
• Does Dotfuscator handle P/Invoke native calls?
  
• I have code written in Managed C++. Can I use Dotfuscator on these assemblies?
  
• My application uses managed resources. Can I still use Dotfuscator?
  
• How can Dotfuscator break ILDASM without adversly affecting the runtime?
  
• I used the "breakildasm" feature, but I can still open my application in the ildasm GUI. What's wrong?
  
• What does renaming to "unprintables" mean?
  
• Does Dotfuscator produce unverifiable code?
  
• How do I figure out an obfuscated stack trace that I get back from the field?
  
• What is cross-assembly obfuscation?
  

General

An obfuscation tool alters an executable to conceal information and confound analysis. In other words, it alters an executable in a way that resists decompilation efforts without altering computing processes.

Java and .NET obfuscation tools scramble code to deliver full value to the customer (JVM or CLR) without revealing details of internal processes. Obfuscation tools remove context from compiled code that humans (and reverse-engineering tools) would use to decipher the code's meaning. The objective [of obfuscation] is to remove context from an application while preserving its execution integrity.

Without argument, obfuscation (or even encryption) is not 100 percent protection. Even compiled C++ is disassembleable. If a hacker is perseverant enough, they can find the meaning of your code. The goal of obfuscation is to make the reverse engineering process extremely time consuming and painful so that it's not worth the effort, stopping all casual hackers and as many serious hackers as possible.

Preemptive's products have accomplished this completely. Your program will produce the same results as it did before obfuscation, but the code is far more difficult to reverse-engineer.

Why Obfuscate?

Programs written for .NET are easy to reverse engineer. This is not in any way a fault in the design of .NET; it is simply a reality of modern, intermediate-compiled languages. The .NET Framework uses of expressive file syntax for delivery of executable code: MSIL (Microsoft Intermediate Language) for .NET. Being much higher-level than binary machine code, the intermediate files are laden with identifiers and algorithms that are immediately observable and ultimately understandable. After all, it is obviously difficult to make something easy to understand, flexible, and extendable while simultaneously hiding its crucial details.

Anyone with a copy of a free decompiler such as Reflector for .NET can look at your code and reverse engineer your source code. Suddenly, your software licensing code, copy protection mechanisms, and proprietary business logic are much more available for all to see - whether it's legal or not. Anyone can peruse the details of your software for whatever reason they like. They can search for security flaws to exploit, steal unique ideas, crack programs, or worse. This should be enough to make you pause for thought.

With all of that said, decompilation should not be a risk or a showstopper. Organizations concerned with their intellectual property on the .NET platform need to understand that there is a solution to help thwart reverse engineering - obfuscation. Obfuscation is a technique that provides for seamless renaming of symbols in assemblies as well as other tricks to foil decompilers. Properly applied obfuscation can increase the protection against decompilation by many orders of magnitude, while leaving the application intact.

Also, since obfuscation indicates that the IP owner has taken measures to secure the IP, obfuscating your .NET program may provide you with more legal options in the event it is required.

Lastly, Gartner has recommended obfuscation as a means to protect intellectual property from theft and vulnerabilities from exploitation. 

What Java and .NET applications should be obfuscated?

.NET or Java applications should be obfuscated when: 1) the source code is not publicly available; 2) there is private information in the code, such as SQL, usernames, and passwords; or 3) system performance, bandwidth, or application size is an issue. Obfuscation often is not required if application size is not an issue and the source code is freely distributed or open source.

Corporate and other developers will benefit from setting a policy requiring use of an obfuscation tool as a standard build practice, rather than addressing the question on an application-by-application basis. This avoids the need to assess the issue separately for each development project.  

Does Java or .NET obfuscation affect performance?

Software obfuscation tools need not slow performance in any noticeable way. In fact, a sophisticated Java or .NET obfuscation tool can take a few steps to improve performance by compacting applications. Optimal application of overload induction techniques will reuse identifier names, and other functions will prune unused classes, methods, instance variables, and design time metadata. The size reduction can range from 20-40% or more of an application's size.

Compacted programs often load faster and run in less memory. Moreover, networked distribution of components is more efficient because application size is reduced.

What is Compaction?

As part of the complete analysis of your application, it is possible to determine unneeded elements. The compaction or pruning process can then remove all the unused classes, methods, instance variables, design time metadata, and actual bytecode to produce a much smaller application. In addition, correctly applied obfuscation techniques, such as PreEmptive's patented overload induction, can have a compacting effect. Due to its heavy reuse of identifier names, it saves significant space.
Note: this entire process is performed on bytecode or MSIL, not source.

The size reduction caused by compaction is literally staggering. Some customers have reported a 70% size reduction in their executable. We imagine those customers use large, third party libraries that were heavily trimmed. In our tests, we see a solid 30-40% shrinking in many applications.

TOP

Why Compact?

Compacted programs tend to load faster and run using less memory. For many applications that are distributed on CD-ROM, the size of the application isn't often a serious worry. However, more and more applications are involving a networked/distributed component, browser based or written for embedded systems. In those cases, every byte counts and compaction is essential.

What is Software Watermarking?

Software watermarking is used to hide customer identification or copyright information within software applications, similar to how it is hidden within other digital content such as songs, movies, and images. A watermark can be used to identify owners of the software or to track the origin of a pirated copy.

What factors should be considered in selecting a Java or .NET obfuscation tool?

Performance can be measured by comparing product features and functionality. Does the tool or vendor:

• Stop decompilers from producing useful output?
• Use XML based configuration?
• Offer a solution for both the Java and .NET environments to allow for consistent deployment and less of a learning curve?
• Provide granular configuration options so you can tailor the obfuscation to your application?
• Generate map files to facilitate stack trace interpretation?
• Provide tools that help in troubleshooting and debugging obfuscated applications?
• Use overload induction to rename methods and fields?
• Use incremental obfuscation to facilitate patch distribution?
• Employ control flow obfuscation to destroy patterns that decompilers use to re-create source level control structures?
• Shrink application size through pruning and renaming?
• Apply effective string encryption to hide sensitive information?
• Integrate easily into automated build systems?
• Consistently offer enhancements that expand product capabilities?

In addition, for .NET obfuscation tools, the following questions are appropriate:

• Does the obfuscation tool integrate seamlessly with Visual Studio?
• Is the obfuscation tool updated in a timely manner to support new versions of Visual Studio and the .NET Framework?
• Does the obfuscation tool allow the .NET verifier feature to function properly?
• Does the obfuscation tool go through Microsoft's internal security checks and testing process?

Reliability can be reviewed by assessing the vendor's past performance record and experience in the industry. Support can be assessed by considering:

• Does the vendor offer live support?
• Does the vendor demonstrate industry experience?
• How long has the vendor been in business?

Another way to evaluate .NET and Java obfuscation tools is to consider the conclusions of experts, such as the creators of the frameworks.

• For .NET obfuscation tools, has the program been selected and endorsed by Microsoft?
• For Java obfuscation tools, has the program been selected by Sun and used on some of the JDK Libraries?

PreEmptive Solutions' Java obfuscation tool and .NET obfuscation tool compare favorably in terms of performance, reliability, support, and industry acceptance. In addition, the products reflect product leadership and contain patented technologies.

Why do I need Tamper Detection and Notification?

If you invest in fire prevention - don't you also want fire detection? If an organization cares enough to invest time and resources into reverse engineering prevention, wouldn't that same organization benefit from reverse engineering/alternation detection - especially, if there wasn't an additional fee? Tamper Detection and Notification is included as part of Dotfuscator Professional.

Those who lose sight of the fact that the organizing principle behind obfuscation is the requirement to manage risk also undervalue the importance of the obfuscation process. The result is a one dimensional view of obfuscation as a finite set of technology limited to the transformation of application binaries. However, the emergence of Service Oriented Architecture (SOA) and Software as a Service (SaaS) combined with a growing recognition that the most effective IT controls must bridge the development lifecycle and operations management has made it possible, for the first time, to help prevent reverse engineering and to detect tampering when it occurs.

Dotfuscator

The Professional Edition provides superior protection to foil decompilation, size reduction to conserve memory and improve load times, deep Visual Studio.NET integration for seamless configuration, incremental obfuscation to release patches, watermarking to track pirates, and phone and email technical support.

The Community Edition is an entry level obfuscator included in the Professional and Enterprise SKUs of Visual Studio.NET 2003 and the Standard and Professional SKUs of Visual Studio 2005 and the Architect, Developer, Test, and Suite SKUs of Visual Studio Team System. In order to run, the Community Edition requires that Visual Studio also be running. It is targeted at students and freeware authors.

Can I get an evaluation copy?

A 14 day evaluation copy of Dotfuscator Professional Edition .NET Obfuscator may be obtained from here.

Also, Dotfuscator Standard and Profession Editions that are purchased over the web come with a 30-day money back guarantee. 

Is Dotfuscator a profiling tool?

No. Dotfuscator is a .NET application optimization and obfuscation system. A common misconception is that Dotfuscator is comparable with profiling systems. Dotfuscator is not a profiler. A profiler tells you where your code bottlenecks are (often due to poor performing algorithms, etc.)

Does Dotfuscator change the source code of my application?

No. Dotfuscator .NET obfuscator works solely on compiled .NET assemblies. Your source code is not needed (or affected).

Does Dotfuscator require me to distribute any additional libraries or programs with my final application?

No. The output files produced by Dotfuscator are standard .NET assemblies. They will run under the .NET Common Language Runtime with no additional dependencies.

How does Dotfuscator obfuscate assemblies?

Dotfuscator uses all of the traditional obfuscation techniques. It renames all possible method and field names and is highly configurable so you can select a given method (e.g. all publics) to be renamed or not. It is not limited to private methods.

Dotfuscator also includes our patented Overload Induction renaming system. There is simply no better renaming algorithm for code protection and size reduction. No obfuscator can prevent decompilation in all cases, however, Dotfuscator makes the decompiled output extremely difficult to read. It makes decompilers work more like disassemblers!

What is PreEmptive Solution's patented Overload Induction^TM ?

As expected of any good obfuscator, Dotfuscator .NET Obfuscator renames all program identifiers to small, meaningless names. With our DashO Java Obfuscator, we experimented with creating clever renames (unprintables, etc.) but decided to rename using small, alphabetic letters. Instead of clever names, we invented and patented an algorithm called "overload induction" that has been in use in DashO since its inception. Overload induction works by identifying colliding sets of methods across inheritance hierarchies and renaming such sets according to some enumeration (e.g. the alphabet). Because separate colliding sets are identified and the enumeration starts at the beginning each time, method overloading is induced on a grand scale. The OI algorithm determines all opportunities for name reuse and takes advantage of them. Many of our customers have reported a full 33% of ALL methods were renamed to a single character (such as "a"). Typically, 10% more are renamed to "b", etc.

This effect is far stronger than normal one-to-one renaming for several reasons. First, overload induction raises the 90% casual hacker number listed above. It takes more work to undo overload induction, so fewer people will go to the trouble, and it protects more programs. Second, in order to undo overload induction effectively, a decompiler needs to implement overload induction themselves (ironically, violating our patent in the process) to undo it. Alternatively, a simpler renaming scheme can be taken to undo it to a lesser degree. Regardless of the tact taken, overload induction is provably irreversible. The best overload induction undo-er will come out with a different number of unique methods than the original source code contained. It cannot be undone all the way because overload induction destroys original overloading relationships. In undone overload induction, there will be no overloaded methods. If we assume the grand designers of OO technology implemented overloaded methods as a way of creating "more readable code", then by virtue of removing that ability, the code has less information in it than before.

Apart from obfuscation, overload induction also reduces the final program size of obfuscated code. Because of its heavy reuse of identifier names, it saves significant space. Up to 10% of the size savings in Dotfuscated and DashO'd programs are directly attributable to renaming (5% because it was OI renaming).

Why would I use obfuscation to hide application vulnerabilities? Wouldn't I be much better served by simply ensuring that I have no vulnerabilities?

Stamping out vulnerabilities is the best thing - and doing so earlier is better than later - but no one can guarantee zero vulnerabilities. (If we could we would not see the continuous stream of patches and alerts from every software and system supplier under the sun.)

At least as important are the issues surrounding IP theft and piracy. These issues persist even with "vulnerability-free code."

Last, there are a number of scenarios where a tampered application plays a pivotal role (piracy, spoofing, malicious attacks, etc.) even if an application is released with no exploitable vulnerabilities. A tampered application may have some vulnerabilities introduced "post-production." The only defense in this last case is to "detect", "defend" and "notify" when tampered applications are run. This is uniquely offered within Dotfuscator.

How does Dotfuscator work on API libraries?

You can still take advantage of renaming your non-public types, methods, and fields. Dotfuscator obfuscation is very configurable in this respect. Dotfuscator has a convenient "Library" option that automatically prevents all public methods from being renamed. If this doesn't quite fit your application, you can customize the exclusion rules at various levels of granularity. Control flow obfuscation and string encryption also protect code without renaming. 

TOP

What is String Encryption?

Dotfuscator Professional obfuscation implements runtime decrypted String encryption. As mentioned before, any encryption (or specifically decryption) done at runtime is inherently insecure. That is, a smart hacker can eventually break it, but for Strings present in customer code, we found it worthwhile. Effectively, we apply a simple encryption algorithm (with a twist to thwart decompilers) to any strings in your application you desire. 

Let's face it - if a hacker wants to get into your code, he doesn't blindly start searching renamed types. He probably searches for "Invalid License Key" which points him directly to the type where license handling is performed. Searching on strings is incredibly easy. String Encryption raises the bar for the casual hacker and deters that many more non-serious hackers. You will want to make sure that you apply string encryption to hide sensitive information such as hardcoded SQL strings, usernames, passwords, etc. This algorithm incurs a very tiny performance penalty at runtime but, as with pretty much everything else in Dotfuscator, this option is fully configurable. 

What is Incremental Obfuscation?

Our customers in the Java space quickly told us they needed this feature. The problem was that they distributed their obfuscated code and their customers found a bug in their product. They wanted to issue a patch to fix their customer's problems, but because of obfuscation, this always wasn't possible. Fixing bugs in their code created or deleted classes, methods, or fields and caused subsequent obfuscation runs to rename things slightly differently. Unfortunately, what was renamed differently and how it was renamed differently was a mystery.

Dotfuscator Professional (and DashO Pro Java obfuscation) includes incremental obfuscation to combat that problem. Dotfuscator creates a map file to tell you how it did renaming. Therefore, if you get a stack trace from your customer, you can match it to the mapfile and find out what unobfuscated class your bug is in (obviously you should treat your mapfile as confidential). However, that same mapfile can be used as input to Dotfuscator on subsequent runs to dictate that renames used previously should be used again wherever possible.

If you release your product then patch a few modules, Dotfuscator .NET obfuscation can be run in such a way to mimic its previous renaming scheme. That way, you can issue just the patched modules to your customers.

What is Control Flow obfuscation?

Dotfuscator includes a strong form of protection called Control Flow Obfuscation. Reverse-engineering tools and Java runtimes differ in one very important area: Runtimes execute code - if the code says "goto", the runtime does; Reverse-engineering tools attempt to view sections of code at once and identify those pieces of code as for-loops or if-blocks or whatever structures were present in the source code. Runtimes don't require those structures. Loops are simply a commonly followed goto.

Control Flow Obfuscation destroys the common perception of a compiled control structure. The runtime isn't affected if one set of goto's has been replaced by another. However, the reverse engineering tools are left with spaghetti code. Since Java has no actual goto command (compiled Java bytecode does) this often poses a significant reverse-engineering problem.

What happens when I try to use a decompiler on an application run through Dotfuscator Professional?

Many of the Dotfuscator Professional transforms such as String Encryption and Control Flow obfuscation tend to break or crash decompilers. Even if Dotfuscator Professional does not outright crash the decompiler, it will stop it from generating useful input. For example, the decompiler may generate an empty or incorrect method because it had control flow obfuscation or string encryption applied to it.

What is Enhanced Overload Induction?

Dotfuscator Professional Edition extends Overload-Induction^TM by allowing a method's return type to be used as a criterion in determining method uniqueness. This feature allows up to 15% more redundancy in method renames. In addition, since overloading on return type is typically not allowed in source languages (such as C# and VB), this further hinders decompilers.

Therefore, the following code:

float getCheckingBalance(int accountnumber){}
void setCheckingBalance(int accountnumber, float value){}
int getCheckingStatus(int accountnumber){}

with standard Overload Induction becomes:

float a(int a){}
void a(int a, float b){}
int b(int a){}

with Enhanced Overload Induction it now becomes:

float a(int a){}
void a(int a, float b){}
int a(int a){}

This feature relies on compile-time analysis of your application. Therefore, remote method calls (which are
effectively reflective on the callee side of the transaction) cannot use this feature.

Can I run Dotfuscator on my ASP.NET pages?

Yes. Dotfuscator can obfuscate your ASP.NET code behind assemblies.

Can I run Dotfuscator on my Windows Forms application?

Yes. In fact, the Dotfuscator GUI is a .NET Windows Forms application that has been Dotfuscated!

Can I run Dotfuscator on my .NET Compact Framework application?

Dotfuscator Professional edition has comprehensive support for the Microsoft .NET Compact Framework. Dotfuscator can substantially reduce the memory footprint of your application, a must in embedded development where memory, power consumption, and cost are closely interrelated.

In a compact environment, application size is a very important design consideration. Dotfuscator's compaction and unused code removal features make it an extremely valuable addition to the embedded developer's toolkit.

What is Assembly Linking?

You can use Dotfuscator to link multiple input assemblies into one or more output assemblies.
For example, if you have input assemblies A, B, C, D, and E, you can link assemblies A,B, and C and name the result F.
At the same time, you can also link D and E and name the result G. The only rule is that you can't link the same input assembly into multiple output assemblies.

See this article to read more about assembly linking and how it can protect, shrink and improve your applications.

The linking feature is fully integrated with the rest of Dotfuscator, so in one step, you can obfuscate, remove unused types, methods, and fields, and link the result into one assembly.

If you have other input assemblies that reference the assemblies you are linking together, Dotfuscator will transparently update all the assembly and type references so the output assemblies will correctly work together.

What versions of .NET and Visual Studio does Dotfuscator support?

Dotfuscator .NET obfuscator supports all of them, including .NET 3.0 and Visual Studio 2008.

Is there a way to declare in my source code which items I want to exclude from obfuscation?

The .NET Framework version 2.0 provides two new custom attributes designed to make it easy to automatically obfuscate assemblies without having to set up configuration files:

• System.Reflection.ObfuscateAssemblyAttribute.
  This custom attribute can be used at the assembly level to tell Dotfuscator how to obfuscate the assembly as a whole.
  
• System.Reflection.ObfuscationAttribute.
  This custom attribute can be used on types and their members and tells Dotfuscator how to obfuscate the item.

If you are using an earlier version of the .NET Framework, Dotfuscator Professional Edition ships with a DLL containing compatible attributes. To use, add the PreEmptive.ObfuscationAttributes.dll as a reference when building your project. When referencing the compatible attributes in your source code, replace the "System.Reflection" namespace with "PreEmptive.Dotfuscator.ObfuscationAttributes".

Technical

Yes, you can use regular expressions to exclude or include certain types, methods, and fields. You can do this using the GUI by adding rule nodes in the rule editing view located on the right pane of the exclude or include tabs on any of the configuration editors. 

For example, if you want to create a regular expression that matches methods beginning with "Test"...

• Click the Add Type button. This creates a custom type rule in the rule editing view located on the right pane.
• Below the rule editing view, enter regular expression .* in the Name field the and check the Regular Expression checkbox. Having the Regular Expression checkbox checked tells Dotfuscator to interpret the Name field as a regular expression. This rule will select all types.
• Right click on the type rule in the rule editing view and select Add Method. This adds a custom method rule in the rule editing view as a child of the parent rule type we had created earlier.
• Enter in the Name field the regular expression Test.* and check the Regular Expression checkbox in order for Dotfuscator to interpret the Name field as a regular expression.
• Enter the regular expression .* in the Signature field in order to select methods regardless of signature.    
• 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 appear shaded in the application tree view.

See the topic Creating Custom Rules under Using the Graphical Rules Interface in the user guide for complete details.

How do I integrate Dotfuscator into my automated build process?

Dotfuscator Professional has a command line interface, suitable for integrating into scripting environments. Dotfuscator Professional Edition Version 2.0 has deep Visual Studio.NET integration allowing Dotfuscator to be invoked during the solution build process.

My assembly has a strong name. How can I use Dotfuscator when the obfuscation process would invalidate the signing of the assembly?

1. Delay signing the assembly during development. This is done by embedding two custom attributes into your assembly. For C#, you would include the following lines into AssemblyInfo.cs:

[assembly:AssemblyKeyFileAttribute("keyfile.snk")]
[assembly:AssemblyDelaySignAttribute(true)]

Where keyfile.snk is the name of the file containing your public key.

2. Use the strong name tool (sn.exe) that comes with the .NET Framework to turn off the strong name verification while you are testing your assembly:

sn -Vr TestAsm.exe

3. Obfuscate the delay signed assembly using Dotfuscator.

4. After running through Dotfuscator turn on the verification for the obfuscated assembly using sn.exe. This unregisters the dotfuscated assembly for verification skipping:

sn -Vu TestAsm.exe

5. Complete the signing process of the dotfuscated assembly:

sn -R TestAsm.exe keyfile.snk

Where keyfile.snk is the name of the file containing your private key.

Why can't I just use NGEN to compile my assemblies into a native code before shipping to my customers?

Even if an application has been compiled to native code, the .NET Runtime still requires that the complete metadata and IL be included in an assembly before it is allowed to execute. Therefore, using NGEN does not protect your intellectual property at all! In addition, NGEN code suffers from other problems including:

• NGEN'd code may lose some of the advantages that .NET gives you (e.g., platform agnosticism, verifiabilty, interoperablilty).
• NGEN'd code cannot be signed and there may be a security difference compared to managed code.
• NGEN'd code is difficult to administer because it's not automatically deleted when an assembly is uninstalled.
• NGEN'd code is brittle. It must be re-JITed every time the environment changes, which is why the metadata is still required.

What about a tool that converts your assemblies into native format and applies encryption?

Tools that compile your .NET code to native x86 code using the NGEN facility of the .NET runtime (essentially "pre-jitting" your code) and encrypt the metadata raise the bar against decompilation a bit, but these solutions always suffer from classic flaws. First, before the computer executes the program, it must have the unencrypted program in memory somewhere. It's not hard for a hacker to take snapshots of that memory. Second, any strong encryption requires a key for decryption. Where is that key to be stored? Obviously, if that key is stored somewhere in the program, it will be found and the program will be in naked, unprotected view. Even if it is somehow transmitted with every execution, it can be intercepted. In addition, this technique suffers from the same NGEN issues listed above.

Can Dotfuscator process applications that use reflection?

Yes. Transforms such as Control Flow and String Encryption are not affected by reflection. But, depending on how you implemented the reflection there may be some configuration work in order to use renaming on your public methods. So how can you use reflection and use renaming without any configuration? There are a number of ways to get a reference to a Type, and not all require the use of a lookup by name.

Is the use of typeof in C# always OK?

Yes. This is one of those cases where a Type can be obtained without a lookup by name. In the case where the Type in question is known statically, you should always use typeof. Dotfuscator can rename these types with no problem. You can always replace:

Type t = Type.GetType( "MyType");

with

Type t = typeof (MyType);

What if I need to do a lookup by name?

You have a couple of options:

• Don't rename the public methods for these classes. You will still get plenty of protection by using Control Flow, String Encryption, ILDASM breaker, etc.
• Dotfuscator has a powerful and flexible interface to exclude things from renaming. You'll need to exclude types that are intended to be returned by the GetType call. For example:
  
  Type t = Type.GetType( "MyType");
  
  In this case you would need to exclude the name of the type MyType. You do not necessarily need to exclude the members of MyType. You only need to worry about things referenced by name, as in the GetType( "MyType" ) example above.

Note: The Break Ildasm feature will be removed from future versions of Dotfuscator.  Newer versions of Ildasm are able to read the bad metadata Dotfuscator and other obfuscators introduce that cause ILDASM to break.

Can uses of codebehind methods in *.aspx and *.ascx files be obfuscated?

You can rename any method or type name that is not referenced in your .aspx file.

Is remoting a problem for the obfuscator?

If both the client and the server sides are being obfuscated, all you need to do is exclude the names of the types that are being registered for remoting. You can obfuscate the call interface. If the server is meant to be called by unobfuscated clients, then you also have to exclude the remote call interface.
Note: You should not use Enhanced Overload Induction on remote applications.

The Framework uses reflection to find the name of the type and append .resources to the type name. Is this a problem?

Dotfuscator handles this automatically by searching for such resources and renaming them appropriately ensyrung their names work with the new class names.

I have heard that XML Serialization "serializes an object and uses the names of the members, as determined at runtime, as the XML element names." Is this a problem?

If all participants in the serialization (producers and consumers of the serialized objects) are obfuscated, then no further action is required. Objects serialized in this manner will be serialized with the obfuscated names and the deserializer will be expecting those same names. It is only when one of the participants expects the original names that problem occur. In this case, exclude the type and its members from renaming. Also, use incremental obfuscation on such types if they need to be compatible across releases. This ensures that an object serialized with version 1.2 of your application will be able to be deserialized by version 1.3, etc.
Note: You should not use Enhanced Overload Induction on serialized objects.

Is Late Binding a problem? I am thinking of the uses of Assembly.Load and InvokeMember.

Typically Assembly.Load is not a problem since Dotfuscator does not change assembly names. You only need to list the dynamically loaded assemblies as input assemblies. InvokeMember will be a problem because the name of the method to invoke is passed as an argument. You will need to determine which methods are called using InvokeMember and exclude them from renaming. There are other methods to look for as well-- just about any method on System.Type that takes a named argument. Examples include:

Methods

GetMethod
GetType
GetField
GetEvent
GetProperty
GetNestedType
GetMember

Properties

Namespace
FullName

There are also GetType( string, ... ) methods on System.Reflection.Assembly that you will need to watch out for.

Does Dotfuscator handle P/Invoke native calls?

Yes. P/Invoke methods are automatically excluded from the renaming process.

I have code written in Managed C++. Can I use Dotfuscator on these assemblies?

Yes. Dotfuscator Professional can process assemblies containing managed and unmanaged (native) code, such as those created by the Managed C++ compiler. However, the Community Edition does not support Managed C++.

My application uses managed resources. Can I still use Dotfuscator?

Yes. If the resource is embedded in the assembly, the process is automatic. If it is embedded inside an external file, then the file must be in the same directory as the referencing module. If the resource is embedded inside another assembly, then that assembly must be one of the input assemblies.

How can Dotfuscator break ILDASM without adversly affecting the runtime?

There are known ways in which to break current versions of ILDASM (the disassembler that ships with the .NET Framework SDK). Most of these methods rely on inserting invalid metadata into the application that the runtime does not use, but that the disassembler tries to parse. By setting this option, Dotfuscator Professional Edition will add such metadata to your application. When the disassembler tries to read the invalid metadata, it will crash.

Note: The Break Ildasm feature will be removed from future versions of Dotfuscator.  Newer versions of ILDADM are able to read the bad metadata Dotfuscator and other obfuscators introduce that cause ILDASM to break.

I used the Break Ildasm feature, but I can still open my application in the ILDASM GUI. What's wrong?

The ILDASM GUI does not load and process all the metadata at once; therefore, the ILDASM GUI may not break if you are simply browsing the disassembly (unless you browse into a spot where Dotfuscator has changed the IL). However, if you attempt a complete disassembly into a file, or try to dump the treeview in the GUI, then ILDASM will crash when it comes to the parts of the IL that Dotfuscator changed.

Note: The Break Ildasm feature will be removed from future versions of Dotfuscator.  Newer versions of ILDASM are able to read the bad metadata Dotfuscator and other obfuscators introduce that cause ILDASM to break.

What does renaming to "unprintables" mean?

Dotfuscator Professional Edition can rename your variable, methods, and class using several predefined renaming schemes. The "unprintable" scheme uses high Unicode code points that are generally not used. This makes decompiled output even more uncomprehensible.

Does Dotfuscator produce unverifiable code?

Only if your input assembly is not verifiable. Unlike some other obfuscators, Dotfuscator's transforms do not make verifiable code unverifiable.

How do I figure out an obfuscated stack trace that I get back from the field?

Dotfuscator Standard and Professional Editions include the ability to perform stack trace translations.

What is cross-assembly obfuscation?

Dotfuscator Pro supports cross-assembly obfuscation allowing multiple assemblies to be loaded into a single project and configured in an integrated way. With cross-assembly obfuscation, references, fields, and methods are obfuscated uniformly across multiple input assemblies. For example, if you had two dlls and three exes and you wanted them obfuscated together, you can place of all your assemblies in one Dotfuscator project. Dotfuscator will automatically propagate symbol renaming selections and entry points across all of your assemblies.