 |
Order your copy with PDS today |
 |
Bel PDS ! voor speciale Entrepreneur licentie prijzen (tbv minder dan 40 medewerkers) |
.NET Obfuscator FAQ
General
What is Obfuscation?TOPObfuscation is the technology of shrouding the facts. It's not encryption, but in the context of .NET code, it might be better. Although encryption can make your assembly completely unreadable, this methodology suffered from a classic encryption flaw, it needed to keep the decryption-key with the encrypted data. So, an automated utility could be created to decrypt the code and put it out to disk. Once that happens the fully unencrypted, unobfuscated code is in plain view.
As another comparison, we could compare encryption to locking a six item meal into a lockbox. Only the intended diner (i.e. the CLR) has the key and we don't want anyone else to know what he or she is going to eat. Unfortunately, if someone can pick the lock (or find the key hidden on the bottom of the box), the food is in plain view. Obfuscation works more like putting the six-item meal into a blender and sending it to the diner in a baggie. Sure everyone can see the food in transit, but besides a lucky pea or some beef-colored goop, they don't know what the original meal is. The diner still gets the intended delivery and the meal still provides the same nutritional value as it did before (luckily, CLRs aren't picky about taste). The trick of an obfuscator is to confuse observers, while still giving the CLR the same delivery.
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 not worth the effort. The goal is to stop all casual hackers and as many serious hackers as possible.
Obfuscation removes context from compiled code that humans (and reverse-engineering tools) would use to decipher the code's meaning. The trick is to remove this context from evil intentions while retaining complete execution integrity with the original program. 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.
TOPPrograms 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.
So 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, etc. This should be enough to make you pause for thought.
With all of that said, this 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 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.
As part of the complete analysis of your application, it is possible to determine unneeded elements. The compaction or pruning process can then remove out 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.TOP
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.
Compacted programs tend to load faster and run in 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.TOP
What is Software Watermarking?
Software watermarking can be used to hide customer identification or copyright information into software applications, similar to how it can be hidden in other digital content such as songs, movies and images. A watermark can be used to identify owners of the software or track the origin of a pirated copy.TOP
What Type of
Applications Should be Obfuscated?
Anyone developing .NET applications where the source code is not publicly available or there is private information embedded inside the code.TOP
One argument we have heard is that we are writing corporate-wide software, so we do not need to obfuscate. Assuming the company provides all employees access to the source code for that application this is true. But, if not, whoever has access to the application can easily reverse engineer the source code with a freely available tool or an online web submission. If you have any information such as SQL, username/passwords, proprietary business logic etc. inside the application it can be easily obtained. In addition, applications that have a networked/distributed component, browser based, or written for the .NET Compact Framework will clearly benefit from compaction.
Why do I need
Tamper Detection and Notification?
TOPIf 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 was not 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 should occur.
Dotfuscator
What are the differences between the Professional and Community Editions of Dotfuscator?TOPThe 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.
TOPA 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).TOP
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).TOP
No. The output files produced by Dotfuscator are standard .NET assemblies. They will run under the .NET Common Language Runtime with no additional dependencies.TOP
How does Dotfuscator
obfuscate assemblies?
Dotfuscator uses all of the traditional obfuscation techniques. It renames all possible method and field names. It is highly configurable so you can choose a given method (e.g. all publics) to be renamed or not. It is not limited to private methods.TOP
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 ?
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 ended up just renaming to 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.TOP
This effect is far stronger than normal one-to-one renaming for several reasons. Firstly, 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. It does protect more programs. Secondly, 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).
How does Dotfuscator
work on API libraries ?
TOPYou 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. Not to mention control flow obfuscation and string encryption go a long way to protect code without renaming.
TOPDotfuscator 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 does a nice grep on "Invalid License Key" which points him right 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 sensistive 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?
TOPOur 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 just a patch to fix their customer's problems, but because of obfuscation this always wasn't possible. Fixing bugs in their code would often create or delete classes, methods or fields. This action caused subsequent obfuscation runs to rename things slightly differently. Unfortunately, how and what was renamed different 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. So 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.
So, 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 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 particularly care and certainly don't need those structures. Loops are simply a commonly followed goto.TOP
Control flow obfuscation destroys the common perception of a compiled control structures. The runtime doesn't care as one set of goto's has been replaced by another. But reverse engineering tools now 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. And additional transforms such as enhanced overload induction will make it almost impossible to figure out what is going on anyway.TOP
What is Enhanced Overload
Induction?
TOPDotfuscator Professional Edition extends Overload-InductionTM by allowing a method's return type to be used as a criterion in determining method uniqueness. This feature can allow up to 15 percent 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.
So, the following code:
with standard Overload Induction becomes:float getCheckingBalance(int accountnumber){} void setCheckingBalance(int accountnumber, float value){} int getCheckingStatus(int accountnumber){}with Enhanced Overload Induction it now becomes:float a(int a){} void a(int a, float b){} int b(int a){}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 codebehind assemblies.TOP
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!TOP
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.TOP
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!
TOPYou 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 2.0 and Visual Studio 2005.TOP
Is there a way to declare in my source code which items I want to exclude from
obfuscation?
TOPThe .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
Can I use regular expressions to exclude or include certain types, methods, or fields?TOPYes, 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 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. This rule will select all types.
- Right click on the type rule in the rule editing view and select "Add Method." This will add 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 will 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. Version 2.0 of Dotfuscator Professional Edition has deep Visual Studio.NET integration allowing Dotfuscator to be invoked during the solution build process.TOP
1. Delay sign 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:TOP
[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. Now 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.
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. So using NGEN does not protect your intellectual property at all! In addition, NGEN code suffers from other problems including:TOP
* NGEN'd code may lose some of the advantages that .NET gives you (eg, platform agnosticism, verifiabilty, interoperablilty)
* NGEN'd code cannot be signed and there may be security difference compared to managed code.
* NGEN'd code is harder to administer because it 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 relatively classic flaws. For one, 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. Secondly, 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.TOP
Can
Dotfuscator process applications that use reflection?
Yes. Transforms such as Control Flow, 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 I use reflection and use renaming without any configuration on my part? There are a number of ways to get a reference to a Type, and not all require the use of a lookup by name.TOP
Is the use of typeof in C#
always OK?
TOPYes, 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 problems. So you can always replace:
Type t = Type.GetType( "MyType");
with
Type t = typeof (MyType);
What if I need to do a
lookup by name?
TOPYou 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.TOP
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. Last, you should not use Enhanced Overload Induction on remote applications.TOP
Dotfuscator handles this automatically by looking for such resources and renaming them appropriately so their names work with the new class names.TOP
If all participants in the serialization (producers and consumers of the serialized objects) are obfuscated, then you don't need to do anything special. 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 you will have problems. In this case, you will need to exclude the type and its members from renaming. Also, you will need to use incremental obfuscation on such types if you need them to be compatible across releases. This will ensure that an object serialized with version 1.2 of your application will be able to be deserialized by version 1.3, etc. Last, you should not use Enhanced Overload Induction on serialized objects.TOP
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:TOP
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.TOP
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++.TOP
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 on of the input assemblies.TOP
How can Dotfuscator break ILDASM without adversly affecting the runtime?
TOPThere 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 Ildasm are able to read the bad metadata Dotfuscator and other obfuscators introduce that cause Ildasm to break.
TOPThe 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 look even more uncomprehensible.TOP
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.TOP
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.TOP
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 2 dlls and 3 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.TOP