Is there any way for converting reference dll to non-reference dll in visual studio

Question

I have a DLL file (cf.dll) in my project. It has some methods for encrypting and decrypting a string To/From a file.

My "cf.dll" have some methods for:

write "mystring" ---to-->> new encrypted dll

and

read encrypted dll ---to--->> "mystring"

Now i want publish my project, but if end user use my dll in his/her visual studio (by reference to dll), he/she can decrypt my encrypted files.

Another hand i need this dll in my published project because my project use theirs methods some times.

Now my question is: How can i change this published dll (cf.dll) to a none-reference dll, for prevent any hack by it.

---

Edit (more details):

What i want to do:

I want encrypt some connection strings (as a DataTable) to a file and read this file agin.

I have a dll file for doing this work. it is cf.dll. it has some methods for encrypting and decrypting.

Encryption workflow>

DatatTable ------to------>> Xml as String ------by cf.dll methods to------>> enc.dll

Decryption workflow

enc.dll ------by cf.dll methods to------>> Xml as String ------to------>> DataTable

Everything is working properly and encrypted file (enc.dll) is created.

But if the end user use my magic DLL (cf.dll) in a new project in the visual studio (by reference to it), he/she can decrypt my encrypted file (enc.dll) and hack my program.

So, i want to prevent this hack by changing my DLL (cf.dll) to a none-reference DLL OR use another safe solution.

---

Edit:

My Table Columns for keeping connection string data:

Server    DbName    DbUser    DbPass    FileName

But may i ask save another DataTable by this encryption mechanism. so please help me by a solution for saving any string, not only a ConnectionString. I want a very secure encrypted file from any data. in my solution i conver each object to a string then use my dll methods for save it as a encrypted file (i can do it nice, my problem described above).

Answer 1

That's a really nice question RAM. Some solutions to your problem:

1) Don't make a separate assembly (DLL), but put the code of your DLL in your EXE and make the encryption/decryption function of your DLL "internal" (so that no-one can use it from outside the EXE). Then use a free tool like Eazfuscator to obfuscate your EXE (because, if you don't, your code will be easy to decompile and read).

2) You could put the DLL in your EXE's resources (perhaps encrypted too). Then perhaps you can find a way to get it from there and load it into memory for your app to use. But this is quite complex thing to do if you are a beginner and I'm not 100% sure if it's doable in .NET (I haven't done it myself). However, I think it's doable.

3) The fact is that, if your code executes on the client's machine, there's not much you can do to prevent people from analysing it. The best you can do is to make it a little (or much) difficult for them to do it. E.g. you can add a lock mechanism in your DLL that requires the caller to respond to a random question. If he responds correctly, you execute the decryption. If not, throw an exception, return null or, even better, return a wrong output. The random question could be an integer that your DLL will generate on initialization and the EXE should process this integer to generate a new integer based on some "secret" algorithm. Then the EXE will "feed" this into the DLL somehow and it's functionality would be "unlocked".

4) Perhaps you could use reflection to analyse the caller assembly in order to find characteristics or even the author signature (if you put one in your EXE). That way, you could execute the decryption if the EXE is signed by your private key and the signature is valid. But that's a bit complex too.

5) I think there are tools called "EXE packers" that pack your EXE and DLLs into one EXE file and protect them at some degree. I haven't used one of those yet.

6) You can move the encryption/decryption process on a web site that will ask for authentication in a complex manner, similar to the one described in (3) for the DLL. This may keep your encryption algorithm safe, but the authentication process could still be analysed and hacked.

I would suggest the 3rd solution since it's the most easy to implement. The 4th (using signed code) is the most secure one but it takes a lot of knowledge to implement it (knowledge that even I don't have right now).

Have a nice coding! :)

Answer 2

Surprisingly you can not archieve your goal by using a .NET Assembly.

You could even obfuscate your code and it would still be decompilable and reusable. There's nothing which can prevent that. You can rise the bar, but someone - if she want's - will be able to get the information you are trying to hide.

(Have you seen copy-protection mechanisms that really work besides doing something crucial online?)

Always think of the following: If you want to hide information from a user DO NOT DELIVER that information. Everything else is just protection through obfuscation, wich can be cracked with more or less effort.

Answer 3

You cannot make your dll "non-reference dll", but you can hide all your classes/methods with "internal" keyword (instead of public). This means that this classes/methods can be used only inside of current dll or in DLL/EXE which were specified with InternalVisibleTo attribute. So nobody can use them directly, but you should know that this is managed code, so anybody can take a look inside of your DLL and extract your keys for decryption and write the same code as you have in your dll.