PreEmptive aims to change the perception that obfuscators are only name-mangling tools for source code. The Mayfield Village, Ohio-based company knows too well that simply renaming code structures with obfuscation during the last phases of development won't prevent hackers from decompiling and searching through .Net and Java binary code to find weaknesses.
According to PreEmptive, most attacks happen inside companies via identity theft or by employees having access to clean binaries so they can search on strings and other code elements to find intrusion points into data tiers. Companies that make the right security decisions don't overlook that fact.
To gain the most from obfuscation, IT managers should implement enterprisewide controls and manage them consistently across their organizations rather than putting practices in systems only when illegal activities are detected or, worse, just to slow down hacker infiltration on key Web applications.
However, obfuscation can have some negative implications for source code. For instance, by restructuring flow control on code logic, overall application performance can be affected considerably. What's more, renaming can add complexity to debugging, reflective code and incremental patches. Dotfuscator provides some solutions to these problems by generating various configuration files.
Since PreEmptive's free Dotfuscator Community Version is embedded in Microsoft' Visual Studio, .Net developers will immediately be able to familiarize themselves with Dotfuscator Professional. Once installed, output assemblies from Visual Studio projects are pumped right into Dotfuscator.
Dotfuscator takes internal .Net debugging files, which associate variables and code lines with assemblies, and synchronizes them with obfuscated assemblies so the line numbers match up. That's how Dotfuscator can make debugging work. Essentially, Dofuscator generates map files that match original source-code fields with obfuscated fields.
Dotfuscator map files are in XML format and can be transformed into human-readable HTML. A good side effect of renaming code is that it immediately shrinks assemblies. By reducing the string heap within assemblies by 40 percent to 60 percent, applications load faster, which directly affects performance.
