-3

I'm developing a WPF solution in visual studio, inside the foresaid solution there are two projects, one (client) is the main WPF application and the other one (dllproject) is a simple project that produces, upon build, a dll that's used inside my main client.

I'm adding my dllproject as a reference in my client, and referencing it via using statement.

using dllproject;
using System.Windows;

now the question is, I need to protect the software from reverse engineering because the dll contains confidential algorithms and so on... What would be the best approach?

Obviously, I can't just encrypt my dll and hoping is still usable. Actually, I'm protecting the software using themida.

FabioEnne
  • 732
  • 1
  • 14
  • 43
  • Does this answer your question? [Obfuscation of .NET exe/dll](https://stackoverflow.com/questions/4304086/obfuscation-of-net-exe-dll) – Sinatr Apr 15 '21 at 13:27
  • 1
    _"I need to protect the software from reverse engineering because the dll contains confidential algorithms and so on"_ one $ for every time, I've heard that ... – Fildor Apr 15 '21 at 13:27
  • 3
    ^^ If you don't want clients to reverse engineer, don't give them binaries. Make it a cloud service. – Fildor Apr 15 '21 at 13:28
  • 2
    You can _encrypt_ a DLL, but it's not usable in that format, so you will need to decrypt it before you can load it into your process. Then, you'll need to dynamically load it and use it (rather than simply using `using`). You'll also have the problem of how do you protect the key material on the client side (you'll need to have the key available to the client for the decryption). There is no good solution for that (except in cases where all the clients are in a trusted domain - and then you should be worried about protecting the software. Put your confidential stuff on a web site. – Flydog57 Apr 15 '21 at 13:29
  • Yep, best way to protect that is to just not give it out. Cloud based all the way. – Wellerman Apr 15 '21 at 13:29
  • since you need to _decrypt_ it to use it, wherever you ship it, you have to ship all information required to decrypt it as well, so you can save yourself the trouble of encrypting it, since it does not provide you with _any_ security. the best you can do is to _obfuscate_ it. – Franz Gleichmann Apr 15 '21 at 13:29
  • @Oakley I would be very happy, but unfortunately, this dll allows custom communication via custom protocol with a physical device, so I can't put it up on cloud. – FabioEnne Apr 15 '21 at 14:06
  • Well, then what exactly is so top secret? The protocols themselves? I highly doubt that. Obfuscating would be merely "security by obscurity" (quite literally). Which is a bad idea. – Fildor Apr 15 '21 at 15:10
  • @Fildor thanks for the time you took to replay me..that's why a was looking to encrypt the dll :D – FabioEnne Apr 15 '21 at 15:13
  • I think you need to speak to a security specialist. I have the strong suspicion you are trying to hide the wrong thing. You can always "secure" algorithms by sw-patents and contracts and what have you. But if you want your Hardware only be spoken to by your software, you need to find a way to ensure that, so that everybody can know _how_ you do it but they still cannot do it (with reasonable effort). – Fildor Apr 15 '21 at 15:59

1 Answers1

2

There is no bulletproof way to protect any code that is distributed from being decompiled.

You should always assume that any code you expose publicly can be decompiled and reverse engineered regardless of any obfuscation attempts you have made.

Confidential algorithms and other business critical stuff should stay behind your corporate firewalls or in a trusted cloud service, i.e. you should move any such secrets from the client side to the server side and don't distribute it along with your application.

Fildor
  • 14,510
  • 4
  • 35
  • 67
mm8
  • 163,881
  • 10
  • 57
  • 88
  • @Fildor Unfortunately, this DLL contains algorithms that allow communications in/out with a physical device, so no way for me to put it on clouds... – FabioEnne Apr 15 '21 at 14:04