CODEWITHSUNDEEP
c#.netobfuscation
ispiro
ispiro

Reputation: 27723

Ideas needed for manual obfuscation

I want to avoid my program being simple to have the license-verifier part removed from.

I don't want to use a commercial obfuscator because:

  1. Of the cost. And though they can do a better job than I – they too don't make it impossible to crack, just harder.
  2. It seems that sometimes obfuscators cause bugs in the generated code.

Obviously, I will be keeping an un-obfuscated copy for maintenance.

Upvotes: 0

Views: 732

Answers (3)

Maciej
Maciej

Reputation: 7971

I have some suggestions that you may find usefull.

First of course you can use free obfuscators like the one that comes with VisualStudio. It's better than nothing.

Second you can write your license verification code and once it's working fine, refactor it as much as you can, change class names, member variables, local variables and methods to something like c1, v1, l1, m1 and so on. That's basically what obfuscators do.

Third, do all of the above.

Fourth, write your licence verification in unmanaged code (C++, Delphi) and make it a DLL named something important like core.dll, net.dll etc. You can also put some decoy methods in there that would do nothing important. Make many calls to that DLL from multiple places of your code and pretend that you do something with the results of those calls.

Upvotes: 0

Jroc
Jroc

Reputation: 488

If your intent is to make it harder, but not impossible, one way is to have multiple code points that check your licence file is valid.

Lets say you have a licence file with some key like so

abc-def-fhi-asdf

So, four parts to the key. We would then create four different methods that check for the various parts of the key.

By doing this, and varying the methods used through the code (ideally, randomly choosing the verification method at runtime), you make it significantly more difficult to remove the validation.

on top of this, one method would be to have a publish process that inlined your verification method, subtly changing it each time it is called.

for example something like this:

*user clicks a common function
// [VALIDATION STUB]
*perform user action

The new publish process runs through the code, pulling out // [VALIDATION STUB] and replacing it with your validation code (before the code is compiled), which as I say should vary as much as possible each time.

The main thing to pull from my answer really is that obfuscation is hard, but not impossible. Especially if you resign yourself to the reality that the malevolent user will always break it eventually

Upvotes: 1

SouthShoreAK
SouthShoreAK

Reputation: 4296

I once had to hide a license verifier in code that the customer could modify. Conceivably, they could have removed it if they knew where to look. Here are some tricks that I used at the time.

  1. Give your verifier classes, assembly names, and variable names that look like they actually do something else.
  2. Call the verifier from multiple parts of the code.
  3. Add a randomizer to the call for verification so that sometimes it runs, and sometimes it doesn't. This will make it harder to know where the verification code is actually coming from.

I should add that all of this is defeatable and could cause serious maintenance headaches, but in my particular scenario it worked.

Upvotes: 2

Related Questions