2

We are developing desktop application and we use Wix toolset to create .msi installer.

We use ".Net Reactor" to obfuscate and protect C# code. But we also have several Custom Actions (in the .msi) that we would like to protect as well.

So the question is if we need to worry about protecting these and if so what would be the best way to protect them? do we need to obfuscate all dlls that Custom Actions project depends on?

Stanislav
  • 165
  • 1
  • 15
  • This is a question that can be answered only by your company. Does the CA contain some relevant IP that need to be protected? – Klaus Gütter Jan 19 '19 at 13:52
  • 1
    An .msi can be disassembled (it's a database). A custom action DLL can be disassembled to the same extent that any other DLL can be disassembled. – Tom Blodget Jan 20 '19 at 09:37
  • Very nicely put. I am unsure about how much an assembly can be disassembled? I hear debug mode assemblies contain a lot of information and release mode quite a bit. – Stein Åsmul Jan 20 '19 at 13:20

1 Answers1

0

No Sensitivity, No Problem: I second what Klaus said: does this code contain anything sensitive? Usually the sensitive aspects would revolve around licensing or keys of some sort that you want to protect. Be sure to compile Release mode binaries (would be nuts not to - runtime requirements would also not be met on normal machines).

Protecting Sensitive Information: I wrote a whole check list some time ago on the issue of avoiding the distribution of sensitive information with your deployment solution: How do I avoid distributing sensitive information in my MSI by accident? (one of those sprawling answers that go off the rails while you write - might still be worth a skim).

Native Code: If you have major concerns for sensitivity, I would compile a C++ custom action instead of a managed code custom action to make things more "down to the metal". This is also great for ensuring minimal runtime dependencies (static linking).

Open Source: Quite frankly I would consider open sourcing my whole setup code if no sensitivity is present. Is users have a problem the can debug themselves - though the benefit of that in many cases can be pie-in-the-sky. You can close-source single custom actions that need sensitivity. I would use open source as a sales argument - yes, you can see our setup source to tweak to your environment if need be.

A setup is like a resume: it is only there as a vehicle to deliver something else of value? It has no value in and of itself. You want a sale of your software first and foremost? And security of course. Allowing users to compile their own setup from your sources could also lead to problems - of course. Do you want to support a self-compiled setup?

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164