Blocking DLL

[AmrMohammed]

What is the best way for blocking DLL for not publishing the code inside the library?

[Suzie999]

Not exactly sure what you're asking but as a guess I'd say write it in C or C++

[AmrMohammed]

Hi! I meant how to secure the source code of a properitery DLL in order to prevent knowing the existing code inside. Writing it in C++, C, VB or even Java will not secure the existing code inside because I can decompile it and I can see the whole code inside. For .Net languages you can decompile a DLL and expose its source code using .NET Reflector as an example

Thanks for your reply :)

[overwraith]

Essentially anything that you provide to customers will essentially be prone to reverse engineering, if this is what you are asking. There are techniques for making the reverse engineering process more difficult, like obfuscation, encryption, etc. These techniques make it more difficult, but not impossible to reverse engineer. You should not think that it is a waste of time, it is possible to make your binaries so complicated to reverse that virtually no one will want to partake in it. One technique for actually preventing the majority of people from being able to reverse engineer your code is to put in a call to a service on a server. If you put your proprietary code on the server then people can't reverse it unless they have access to the server.

[Suzie999]

"Writing it in C++, C, VB or even Java will not secure the existing code inside because I can decompile it and I can see the whole code inside."

Care to explain how you decompile and view the source of a C or C++ dll?

[pritaeas]

http://stackoverflow.com/questions/193896/whats-a-good-c-decompiler

Not addressing any legal issues you're gonna have...

[overwraith]

The question is how do you prove somebody decompiled your code unless they sell the product, pirate it. Is not illegal to download decompilers and use them on your own code to test your obfuscation methods, is only illegal if you use them in a disreputable manner. Using them on other peoples code, is illegal, usually copyright protected, but he's not going to get in trouble for downloading a decompiler/debugger. Just make sure it is actually a decompiler/debugger and not malware. Also make sure the "proprietary dll" is actually your company's and not someone else's.

[rubberman]

My advice? Just build optimized code and strip it before shipping. Trying to make it impossible to reverse engineer is a waste of time and resources. Yes, you could encrypt it, and require a proprietary key to decrypt it as it is loaded into memory, but once in memory, it is still vulnerable. We tried this once in the past, and the results, while pretty secure, was a serious PITA and we dropped it PDQ. That code runs most of the semiconductor, flat-panel display, and disc drive plants world wide, and we never in 20 years have seen anyone try to "steal" the code. It just isn't worth it!

If you have something really unique and solves problems in non-obvious ways, then patent it. That's the best protection for really original work. I know, I have one for adaptive systems as sole inventor. That patent is currently owned by Applied Materials, the 800lb gorilla of semiconductor equipment and software.

[overwraith]

I don't think it's a waste of time. At the very least you will make it harder to reverse engineer. Sure it is not impossible, but you may as well do it rather than not do it, especially if you have a tool that you can use in order to do it. It is just one more small step in the development process. Use tools to do it, don't try to implement code obfuscation techniques in your actual source code. Not doing it seems a little bit lazy to me.

[Suzie999]

So those decompilers just give you a load of assembly code and not really the c or c++ code then?

[overwraith]

From what I understand on the subject certain assembly language constructs can be linked to higher level C++/C# language constructs. So yes, you can determine what the original source code looks like if there is no obfuscation/cryption. Don't quote me 100 % though I am no reverser.

[deceptikon]

So yes, you can determine what the original source code looks like if there is no obfuscation/cryption.

For .NET to a certain extent. It won't match the original source since higher level constructs are represented internally with lower level constructs, but you can get close enough to have a fairly good view of the implementation.

For C++, it's compiled into machine code and the original is lost completely. So any decompilation will be nothing more than an educated guess at the original code as it builds new source from the machine code.

For .NET, I quite enjoy decompiling assemblies to see how they work. For C++, I don't bother with decompilers and instead use disassemblers and work through the assembly listing. I have yet to see a C++ decompiler that's worth a damn.

[Suzie999]

Just as I thought deceptikon, I recall looking into it back when I cared if someone could view my c++ source code from exe.

I concluded that it would take a hell of a lot of time and resources to reproduce anything which was similar to the original source.

I did learn from the adventure though, not to have passwords and such in code, except maybe for a simple application login which should then just be a one way hash of it to test against.