SeeUnsharp .NET Obfuscator takes care to remove all unnecessary metadata from your assembly that could give clues about where to find what. This includes renaming types, methods and more to something entirely meaningless, using the same names over and over again, and deleting purely descriptive metadata like property and constant entries altogether. Strings are encoded and hidden away from their usage to prevent finding a code location by a message displayed on the screen or written to a file. And to hide away places that make calls to cryptography or I/O calls, these calls are redirected and renamed as well.
What’s left of each method is essentially the dots, brackets and semicolons with nothing in between.
Rename any of the types, methods and other parts of the code
class DbConnector
→
class A
ConnectToServer(host)
→
B(x)
GetState()
→
C()
Using either numeric, unreadable, invisible, or shuffled names
123
あえがき
GetServer
Overloading methods to the fullest extent possible by the runtime
Delete properties, constants, and other unnecessary metadata
Encode all literal strings in method bodies (and even your own attributes*)
Redirect suspicious method calls for added security
(Check and monitor the process for manipulation and debuggers*)
Maintaining .pdb debug symbols for crash analysis support
*) Not available yet; will be included in a future update.
Unique productivity features
Stack trace de-obfuscation integrated in FieldLogViewer, your one-stop field debugging solution (free & open-source)
Simple setup: just one portable executable file, simple to integrate in automated build server setups
Knows a lot about what better not to touch, like WPF, Entity Framework, [Serializable], or INotifyPropertyChanged
There are a few things that make SeeUnsharp .NET Obfuscator unique. It’s designed to be really easy to integrate into existing build scripts. No lengthy installation procedures or external dependencies, just a single portable executable file. There’s also a module available to use SeeUnsharp with the PowerShell build framework.
In-the-field logging and error diagnostics is fully supported with FieldLog, a fast and comprehensive logging tool for .NET applications. Stack traces captured with exceptions can automatically be deobfuscated back to their original names to understand where an error occured.
The built-in exclusion rules allow you to start obfuscating your application with no further configuration. Only when you add more special WPF classes or use reflection, you may need to define rules. Exclusions can be specified through the standard ObfuscationAttribute directly in the code or with more general patterns in a parameter file. These patterns make it easier to cover whole sets of classes or members, like all your custom Attribute classes from a certain namespace. They also allow you to apply partial obfuscation instead of none at all when some property or constant may be renamed but not deleted.
How you can use it
Prepare your code by adding appropriate obfuscation annotations
(Build a text-based parameter file with the GUI configuration builder*)
Integrate SeeUnsharp with its command-line interface in your build process
*) Not available yet; will be included in a future update.