Ideas needed for manual obfuscation

Question

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:

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

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

Manual obfuscation can also cause bugs in the end result. With a far higher propability. — H H, Apr 18 '12 at 15:46
Duplicate? http://stackoverflow.com/questions/1857685/how-to-create-own-dotnet-obfuscator — Felix K., Apr 18 '12 at 15:47
If you look around you will find numerous free obfuscators. I Like [EAZObfuscator](http://www.foss.kharkov.ua/g1/projects/eazfuscator/dotnet/Default.aspx). It is very well integrated with VS — Steve, Apr 18 '12 at 15:50
@HenkHolterman Thanks for the warning. But I think that depends on how much obfuscating is done. As I wrote in the question, I just want to avoid it being _simple_ to crack. — ispiro, Apr 18 '12 at 15:53

score 2 · Accepted Answer · answered Apr 18 '12 at 15:51

2

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.

Give your verifier classes, assembly names, and variable names that look like they actually do something else.
Call the verifier from multiple parts of the code.
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.

answered Apr 18 '12 at 15:51

SouthShoreAK

4,176
2
26
48

Thanks. This is the type of answer I'm looking for. – ispiro Apr 18 '12 at 15:57
Not too difficult to trace through with a debugger. – Stephen Chung Apr 19 '12 at 01:03
Yes, but if the person you're trying to fool has a debugger and full access to your source, you probably need something stronger anyway. – SouthShoreAK Apr 19 '12 at 02:46

score 1 · Answer 2 · answered Apr 18 '12 at 15:52

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

Thanks. But I didn't understand the part about "have a publish process that inlined your verification method" – in what manner would that help? — ispiro, Apr 18 '12 at 16:00
By increasing the number places the code exists, it makes it harder for someone to crack it. The publish process would essentially be injecting your validation code (which at the moment might just be in one method, making it easy to break by removing that one method) into many places in the code. — Jroc, Apr 18 '12 at 16:02

score 0 · Answer 3 · answered Apr 18 '12 at 21:44

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.

Ideas needed for manual obfuscation

3 Answers3