3

We are developing a Desktop Application (Windows Service) with C#. And we are trying to protect our intellectual property and this is why we decided to .Net Reactor

Initially, it looked like a powerful tool. When obfuscating I've selected all available options except of 'Native exe file'. (Necrobit, Anti ILDASM, Anti Tampering, Control Flow obfuscation, Obfuscation, String Encryption, Compress & Encrypt Resources)

I tried to use DotPeek to check the results and was happy with the results

But it turned out that there is a tool out there that can easily deobfuscates all assemblies (for apparent reasons I'm not going to mention what is it the tool). But I'm curious if anyone has faced similar type of problem. Does anyone know a reliable way to protect C# code that will be running on clients desktops/servers

**Please don't suggest to rewrite the app using C++

Stanislav
  • 165
  • 1
  • 15
  • 1
    `Does anyone know a reliable way to protect C# code that will be running on clients desktops/servers` Have it not run on their servers (e.g. on the cloud). – mjwills Jan 26 '19 at 12:45
  • 4
    You can't (ultimately) protect any code that will run on the user's machine. A persistent enough cracker can reverse engineer anything. – eddiewould Jan 26 '19 at 12:51
  • 1
    (rewriting in c++ wouldn't help you) – eddiewould Jan 26 '19 at 12:52
  • @eddiewould yea, that is true. We realize that we won't be able to achieve 100% protection. If computer can read, apparently person who is sitting in front of it can do that as well. The question is more how we can make it harder? It's painful to realize that it can be deobfuscated within 15 seconds C++ would make the process much more complicated (but, of course, doesn't mean 100% protection) – Stanislav Jan 26 '19 at 13:01
  • 2
    *"(for apparent reasons I'm not going to mention what is it the tool)"* because the "bad guys" don't know about it? Hint, the bad guys know more about deobfuscated that you, that is what they do. You protect intellectual property in court. – zaph Jan 28 '19 at 01:10
  • https://stackoverflow.com/questions/506282/protect-net-code-from-reverse-engineering – Chris Jan 28 '19 at 01:52
  • You can always rewrite some portion in C++ to make it harder to understand some part of the code. Also the tool won't recover original variable names and things like that if the were renamed during obfuscation, so it can still be hard to find out the code that you really want to protect. Also, remember that if you were able to write that code once, a larger company might be able to copy most of your idea without any code, – Phil1970 Jan 28 '19 at 02:26
  • 3
    Try obfuscator, which uses virtualization to protect the application. I can advise ArmDot (www.armdot.com/). It converts original code into an array of bytes that is interpreted by special virtual machine. Each time you apply ArmDot, it creates a new version of virtual machine and uses a new set of instructions to represent the original code. – redeye Jan 28 '19 at 17:48
  • "rewriting in c++ wouldn't help you" -- While it's true that a determined individual _can_ reverse-engineer C++, it's often **orders of magnitude** more difficult than it is with .NET/IL. Reverse-engineering native assembly can be so labor-intensive that it's not worth anyone's time. – Scott Smith May 18 '21 at 08:42

2 Answers2

4

In general, the cost of writing software is many orders of magnitude greater than paying for a license to use it. Similarly, it is expensive to maintain. Thus, in most cases, the value of the intellectual property is low compared to the operations cost. Thus, few, if any, users are going to be sophisticated enough and economically advantages enough to reverse-engineer your software for any purpose they might have.

Also, in general, if you hand out physical access to something, whether it’s a phone, a computer, or a compiled piece of software, you no longer have any expectation of security of whatever that is.

Therefore, I think your efforts are misguided. If there is a particularly valuable algorithm or approach, consider hosting on a server as an API, or pursing a patent. If you must distribute this special piece, secure strong non disclosure agreements with your clients. Make it economically risky for them to try to benefit from reverse-engineering.

theMayer
  • 15,456
  • 7
  • 58
  • 90
0

Option 1)

Extract out an important part (or several - the more the better) of your program to run remotely on your servers - would mean the user would need to be connected to the internet to run your program. Don't just add a remote key check because a cracker will just NOP that out. Instead, run a non-trivial algorithm there.

Option 2)

Build a hardware dongle & distribute it with your software. Again, implement one or more key algorithms on the dongle rather than just a key check.

Option 3)

After compiling, compress the resulting DLLs as an archive THEN encrypt it. You will then use assembler to write a hand-coded "loader" (which attempts to hide what it's doing). Note that the loader will need to include the decryption key somewhere, however there are things you can do to hide it better. The idea being to hide the fact that it's running on the .NET framework (will certainly beat all the off the shelf decryption tools). It won't however disuade crackers (who will see that the process in memory is .NET & will dump the process).

HTH

eddiewould
  • 1,555
  • 16
  • 36
  • You could combine these approaches too for additional protection (protection coming in the form of making more "hoops to jump through" for the cracker) – eddiewould Jan 28 '19 at 00:09
  • The attacker will just use a debugger to examine the running code in memory. – zaph Jan 28 '19 at 01:08
  • 3
    This is kind of like putting your finger in the dam. There’s no way it’s going to work in the long run, and you’ll kill yourself doing it. – theMayer Jan 28 '19 at 01:20
  • @zaph - I did make that point. You're never going to beat someone determined - the best you can do is put up a padlock - it will stop casual theives but will not stop someone determined. – eddiewould Jan 28 '19 at 02:36