BpmDj… my brainchild… bringing in no money… So I am looking for free tools.
In order to figure out how much information assemblies throw around, just have a look at https://www.jetbrains.com/decompiler/ It basically returns me the original source code, including all variable names and everything else that could have been thrown out. Therefore, an obfuscator is really necessary. http://www.dotnetstuffs.com/best-free-obfuscator-to-protect-net-assemblies/ had a list of interesting possibilities.
Dotfuscator (A Lead to Sell)
The microsoft site refers to ‘DotFuscator’; and let me tell you.. the community edition is bullshit. The entire thing is one big lead to sell you their product. It starts with a forced registration (you have to give a valid emailaddress). Then when you are in the application, you only see advertisment, not a lot of real useful obfuscation going on. And lastly, when I ran it on BpmDj it wasn’t even able to go through it because ofg ‘mixed assemblies’ I am sure I could set up a joint project with preemtive solutions, in which I would of course pay them, but honestly… don’t bother with this bullshit. The community edition doesn’t do what it pretends it will do.
Obfuscar (No XAML)
Obfuscar tries to map as many input names to as few output names as possible. ‘Massive overloading’ as they call it. https://code.google.com/archive/p/obfuscar/
At first glance this seems a dead end.. Last release was 11 years ago. However stack overflow posts still discuss it in 2018. Ha no, it seems to have moved to https://github.com/obfuscar/obfuscar
Amazingly enough, after getting a simply configuration it actually ran through the entrire shebang of assemblies and generated 1 output. That output could even start ! Yet it did hang at the splashscreen. Attaching a debugger showed that all threads had been started properly, so I assume either I access a dynamic resource by name (I do have some explicit invokes laying around), or the XAML bindings were seriously fucked up. This is something I should test somewhat further, because if this works we are done.
Oh the horror. The default configuration doesn’t actually obfuscate shit. All identifiers were still present, despite the fact that it claims it had a ‘mapping’. Probably it kept all public properties public as they were without renaming them.
A list of options for the Obfuscar xml file
InPath = Environment.ExpandEnvironmentVariables(vars.GetValue("InPath", ".")); OutPath = Environment.ExpandEnvironmentVariables(vars.GetValue("OutPath", ".")); LogFilePath = Environment.ExpandEnvironmentVariables(vars.GetValue("LogFile", "")); MarkedOnly = XmlConvert.ToBoolean(vars.GetValue("MarkedOnly", "false")); RenameFields = XmlConvert.ToBoolean(vars.GetValue("RenameFields", "true")); RenameProperties = XmlConvert.ToBoolean(vars.GetValue("RenameProperties", "true")); RenameEvents = XmlConvert.ToBoolean(vars.GetValue("RenameEvents", "true")); KeepPublicApi = XmlConvert.ToBoolean(vars.GetValue("KeepPublicApi", "true")); HidePrivateApi = XmlConvert.ToBoolean(vars.GetValue("HidePrivateApi", "true")); ReuseNames = XmlConvert.ToBoolean(vars.GetValue("ReuseNames", "true")); UseUnicodeNames = XmlConvert.ToBoolean(vars.GetValue("UseUnicodeNames", "false")); UseKoreanNames = XmlConvert.ToBoolean(vars.GetValue("UseKoreanNames", "false")); HideStrings = XmlConvert.ToBoolean(vars.GetValue("HideStrings", "true")); Optimize = XmlConvert.ToBoolean(vars.GetValue("OptimizeMethods", "true")); SuppressIldasm = XmlConvert.ToBoolean(vars.GetValue("SuppressIldasm", "true")); XmlMapping = XmlConvert.ToBoolean(vars.GetValue("XmlMapping", "false")); RegenerateDebugInfo = XmlConvert.ToBoolean(vars.GetValue("RegenerateDebugInfo", "false"));
At least when setting the KeepPublicApi to false, some obfuscation happened.
https://stackoverflow.com/questions/28031859/rename-an-internal-class-with-obfuscar has a nice example of a config file. Now, from what I see, the BAML is used to quickly figure out which elements of the UI refer to classes by name. That is obviously smart, yet I would like to rename the XAML entries as well.
I also figured out that the BAML/XAML tree is still stored in the assembly as it was present in the original solution, so no reordering takes places in any way. Not a total failure, but not great either because of this.
Finally something that is not a landing page. Huray ! Last update… 26 January 2019.. still it might work and it is open source. The projecct has indeed be discontinued since 1. July 2016.
In any case, a run of it did behave similarly as Obfuscar. The application started and didn’t get further,probably because of the missing DLL’s. I might need to fix that problem if no obfuscator gets through it. In any case, the XAML was effectively gone after obfuscating; or the dotPeek decompiler stopped trying. I am not entirely sure what it is yet.
After spending some hours on this problem, the problem seems to be in the renaming strategy used. I am not yet sure whether I will blame confuserex or my own program, given that Obfuscar had exactly the same error as this one. Then again maybe they both are based on the same source, so they might both be suffering from the same bug.
In any case, performing a ‘none’ protection did not damage the original assembly, which is already a good sign. Also nice was that there was a debug protection in place which caused the applciation to bark when a debugger tries to connect.
Skater Light (Does not obfuscate at all)
Also Skater is a piece of software to buy. They do have a free version, named SkaterLight. Oddly enough… this feels a lot like chinese spyware. Seriously.
- it worked at the first attempt. So I was a bit skeptical… I decompiled the generated assembly and lo and behold the thing was just not obfuscated whatsoever.
- after installing it, it actually ran with elevated privileges (I know that because I could not read the generated assembly)
- Eazfuscator (not free) – Next is Eazfuscator because they seem very eager to actually deal with the WPF/XAML issue. Oh well.. forget it. Not free anymore. This is the point where I considered whether it would be possible to use a decompile tool to decompile an obfuscator, remove the licensing restrictions and continue. There is a certain beauty to this approach: if the obfuscator sucks, then we can easily do that, which makes it pointless to actually use then
- CodeFort (disappeared) – was mentioned as another option which works well with XAML. Yet, latest udpate on the twitter feed was 2010 and the domain itself became a lnading page.
- Agile.NET (non free)
- FXProtect (disappeared)
- ILProtector (not free) – has gone commercial since version 2.0.17
- Babel.NET (not free) – https://www.babelfor.net/downloads/
- SharpObfuscator (abandonded 2007) – was at https://archive.codeplex.com/?p=sharpobfuscator
- Goliath.NET (not free)
- .NET Reactor (not free) Nice page
- .NETGuard (not free)
- Smart Assembly (excessive pricing)
- CodeVeil – encrypts the DLL before executing it. In the end this might be a better option than ‘obfuscating’ it. Drawback is of course that we have a single point of failure. Another drawback is that it is a chinese product and only a trial version.
- CryptoObfuscator (not free)
- Rummage (fair pricing)
- Xenocode (abandonded)
- DeepSea Obfuscator
The link https://github.com/de4dot/de4dot/tree/master/de4dot.code/deobfuscators is interesting because it lists existing obfuscators 1) that can be deobfuscated 2) were sufficiently know to bother deobfuscating 3) how difficult each one is