c++ dll protection

[dinosaur]

Whats the best way to ensure that a dll written in c++ can only be accessed by "authorized" applications? I thought about a password but information is so easy to get out of dotnet apps ... not that I'm looking for military strength protection ... just something easy/free and would take a more than trivial effort to crack.

Thanks in advance for any guidance.

[hanst99]

Sorry but why would you even want to do that? That completely defeats the purpose of having a dll in the first place.

[dinosaur]

the dll has (actually will have) some algorithms I want to protect. I am using a dll because these algorithms are common across several applications.

[hanst99]

The thing is - how is the dll supposed to know where it's functions are being called from? I really don't think that it's worth the effort either - I doubt there is a reliable way to do this - but even if there was, what would be in for you? If your dll has a function to cure cancer, why not let people who want to use it? Other than that, a patent would be a better approach - with technical measures you wouldn't stop any determined cracker. Alright, you won't stop a determined cracker with a patent either, but why would you care if some dude uses your dll in his backyard?

I know that I am not really aware of the actual situation you are in, but I can't really imagine any reason why you want to obfuscate your code that badly - I just have troubles seeing how that would benefit you.

[3hM2Nwbp]

Sounds like you need debugger protection. Google execryptor

Don't count on it 100% though, unpacking the "protected" code isn't really difficult for a seasoned pirate, or anyone who can follow a tutorial.

-or-
If you're worried that a DLL written in (native) C++ can be recovered after compilation from the binary file, that can't happen, and the only way that someone could use your DLL is to obtain your public interface.

[m4ster r0shi]

Encrypt your DLL after you build it. When your application needs it, decrypt it, use it, then encrypt it again.

[dinosaur]

Thanks Luc ... that looks like it might work for me. Sorry, I am new to C ... is it impossible find the calling conventions to c dll functions from just the dll itself? that is comforting. I suppose if all that i compiled/obfuscated in the calling apps then that would be good enough.

hanst99: I understand your points, and I appreciate your comments. There are some specifics to my situation not worthy of a lengthy discussion ... just suffice it to say I feel like it's something I need.

Thanks to both of you ... your help is really appreciated!

[dinosaur]

m4ster r0shi, I like that idea! thanks!

[modoran]

Encrypt your DLL after you build it. When your application needs it, decrypt it, use it, then encrypt it again.

This is extremely naive approach, once unencrypted exists on disk could be easily copied to another location while your application is running. No even need to crack your encrypting scheme.
Even if you unpack your DLL in a obscure directory it is extremely easy to find location of all modules loaded by a process.

[S6k9GNh0]

The algorithm itself is something that should be encrypted, not the dll it's in.

[m4ster r0shi]

Hmmm... I wonder if the following is possible...

Initially, your dll is encrypted. When you need it, you decrypt it, load it and get pointers to the functions you need. Then, you reserve memory in your address space using VirtualAlloc, copy your functions' code using Read/WriteProcessMemory and adjust your pointers. Then, you unload the dll and decrypt it again.

This way, the dll only stays in decrypted state for some ms.
However, it can be tricky to implement something like this if your functions use static/global data.

[sohguanh]

Assume DLL is written in C++ and C++ pride itself on being fast in execution during run-time. Adding this layer of decrypt and then encrypt for usage is going to take some time isn't it? Are all this effort justifiable just to protect your code ? If a DLL is slow I doubt it will be used by other developers in the near future.

[simeonz]

I am not expert, but most stuff is crackable. The main problem is that usually some part is exclusively responsible for the protection. This makes the job relatively easy, because you only have to find and remove/disarm/trace the protection (even if it encrypts/decrypts in the extreme case).

I am just speculating here, but IMO better reliability can be achieved by crippling the algorithm. Say, some exported function foo() works on a set of values D. You can invent additional argument, such that foo() is now defined for only D, key, when key is correct. This is very easy to pass, in the sense that one simply needs to capture key. Key could be the address of some function in the calling executable that you distribute to trusted authorized parties in a static library. The static library can be stolen.

In all cases, inside men or client passwords will always give out your secret. I mean, if you sell the secret, it is not a secret.

Regards

[Duthomhas]

You are wasting your time to do all this super complex stuff.

If you want to make sure only your applications can use your DLL, then use some process initialization to get a key, or token, that you can use to access other functions in the DLL. Once the session closes the key becomes invalid.

Google around "public key encryption" if you want something really hardy -- but for your purposes you may only need a simple magic number.

Google around "DLLMain" for more on DLL loading and unloading.

The other option would be to simply use static linkage with your special algorithms.

Good luck!