1

SmartAssembly has an official method of using single-file executables* (EXE) (introduced in .NET Core 3) in order to publish with their obfuscation tool.

We followed this method. The short of it is they use a clever, I won't say 'hack', but rather, 'method' of injecting the obfuscated assembly into the MSBuild / publish process (via the $(ProjectDir)\obj directory). This seems to work in that in generates a single .EXE file which executes as expected.

The issue we are running into is when we examine the resulting single file executable at a binary level, we are finding that it seems to contain copies of dependencies the main assembly references (which were supposed to be merged and obfuscated via SmartAssembly) in unobfuscated form! This outcome defeats the purpose of using an obfuscator.

Has anybody used SmartAssembly in this manner successfully?

UPDATE: There is a sample project here which illustrates this issue (this sample project is built to .netcoreapp3.1, so this is not a .net5.0-specific issue). This sample is a console application with a dependency on a class library. The obfuscation project is set to obfuscate and merge the class library into the console application.

This image shows a portion of a hex dump of the single EXE file which contains a string that's supposed to be obfuscated. In fact, the EXE contains the entire class library verbatim.

Finally, if you build and run the sample, it tries to print the name of an obfuscated type, and an obfuscated string, which comes out as its obfuscated type. Our conclusion at this point is this issue is likely caused by the publish process re-adding the unobfuscated dependencies back to the .EXE file.

Vince G.
  • 91
  • 1
  • 8
  • 1
    I know for one obfuscation used to be quite popular in .NET 2 days but please note for many contemporary apps **it can be problematic** particularly for _AoP, DI, ORMs_ or essentially _wherever dynamic proxies are being used_. Be sure to test your app thoroughly before _and after obfuscation_. –  Jun 03 '21 at 22:30
  • Thanks for the advice. This is a WinForms application that was originally written in the .NET 2 days but has been brought forward to .NET 5. We will keep those concerns in mind as we modernize it. – Vince G. Jun 03 '21 at 22:43
  • Hmmm...it's interesting that they inject themselves _in betwen the **build** and **publish** step_ and ultimately _prior_ to the SFE step. Even though it at first seems less optimal I agree it is mysterious why the duplicates. I might try the trial later –  Jun 03 '21 at 23:42
  • Oh! Did did you see this _["If you're running multiple consecutive builds of the same project **you should clean the project** before or after each build. Because SmartAssembly obfuscates the assembly into **obj** directory, the obfuscated version might be picked up by the build command next time **leading to double-obfuscation and other unexpected results** ."](https://documentation.red-gate.com/sa/building-your-assembly/using-smartassembly-with-single-file-executables-net-core-3)_. Do what they say and physically delete the `obj` folders. Don't do a **Build | Clean** –  Jun 03 '21 at 23:46
  • 1
    Yes, we saw that and followed the recommendation. – Vince G. Jun 03 '21 at 23:48
  • Darn...I got all excited. :) Maybe raise a ticket with them? –  Jun 03 '21 at 23:49
  • Yes, we have a support plan with them in effect and raised a ticket with them. – Vince G. Jun 04 '21 at 13:43

0 Answers0