decompiling .NEt "security"

K

kinar

Newcomer
Joined
Jan 23, 2007
Messages
2
copied from xtremevbtalk.net after I noticed this site

Hello, I tried searching on this but was unable to find anything useful

I am fairly new to .NET but not at all new to programming (VC++, VB, primarily).

The biggest concern I have with .NET is that applications and forms can be decompiled using applications such as Reflector.

I know that in VC++ using .NET you can "protect" your code from this so that they are compiled to Native code rather than CLR.

Is this also possible with VB?

Do I need to write all of my critical code in c++ dlls and link them in?

a simple list of "Suggested reading" would be greatly appreciated.
 
Then your DLLs would be the first things I reverse. :p

The answer to your question depends on exactly what your goal is in "protecting" your code. IOW, why do you want to stop people from using reflector on it?
 
You can use an obfuscator on compiled .Net assemblies to make them harder to understand (to a human) once you decompile them. An obfuscator won't make your code any more secure, but it will help ensure that someone doesn't strait up rip it off (at least not easily anyway).

There are also tools that can compile a .Net assembly into native code but they are likely not free.
 
IngisKahn said:
Then your DLLs would be the first things I reverse. :p

The answer to your question depends on exactly what your goal is in "protecting" your code. IOW, why do you want to stop people from using reflector on it?
Click to expand...

ok, firstly, I realise that anything can be reverse engineered. And I realise that I used 2 taboo words in a single post here (security and decompile).

However, I currently maintain a couple systems where we dont want to publish our protocol used in our client/server communication. And once again, while I will agree that anyone with a trial of ethereal can figure it out with a bit of work, it is an entirely different subject than if we were to publish it in a word doc on our website.

which, as I understand it (and have tested briefly) distributing anything in .NET is essentially doing just that. Anyone with a free copy of reflector can output the entire source of our app. In using VC++, I can "hide" parts of this in unmanaged code but in VB I have not found a way todo the same. And for the last time (in this post) I realise that it is only literally "hiding" it, but that is much better (in our case) than publishing it.

kinda like using a condom...Its protection, not a cure

as for...
mskeel said:
You can use an obfuscator on compiled .Net assemblies to make them harder to understand (to a human) once you decompile them. An obfuscator won't make your code any more secure, but it will help ensure that someone doesn't strait up rip it off (at least not easily anyway).

There are also tools that can compile a .Net assembly into native code but they are likely not free.
Click to expand...
I did find a couple of these (remotesoft / thinstall) but unfortunately paying thousands of dollars is not an option. A search for a free (or lowcost) solution did not return any results. I may just have to stick with VS6 for these projects where protection matters.

Unless anyone else has some suggestions.
 
There are many options you can take. Your best bet is an obfuscator. Obfuscated code is harder to reverse than native code. Of course, that costs money.

A cheap and easy way (at least where a single run thru Reflector won't give you the source) would be to encrypt a dll that implements some interface defined in another assembly preferably. You can then at runtime decrypt this dll to memory and load it (Assembly.Load). They’ll have to put some effort into getting the code now.

Remember too that what Reflector gives you is only its interpretation of the source code. A lot of the branching and looping code is messed up, you lose local variable names, and all comments go out the window.
 
If you encrypt the DLL you will lose a fair amount of compile-time/design-time support from the IDE and compiler. It can work, but I don't think it would be worth the trouble.

I was under the impression that there were free obfuscators out there, but it seems that all the ones advertised as free are "free to try." I think that 2007 versions of VS will come with a simple obfuscator, but don't quote me on that. Short of that, there are obfuscators as cheap as $150, if not less.
 
marble_eater said:
If you encrypt the DLL you will lose a fair amount of compile-time/design-time support from the IDE and compiler. It can work, but I don't think it would be worth the trouble.
Click to expand...

I'm not sure what you mean.
Your encrypted DLL would be implementing a public interface. One cast and you're back in buisness.
 
Let's put this in perspective for a second

Two quick things.

First, I know you think you have a need to protect your intellectual property, but in my experience, the vast majority of people who will use your product don't know the first thing about reverse engineering anything with reflector or otherwise. Of those very, very few people who do know, well over 99% of them simply don't care enough to bother. I know it sounds like a threat, but when you really think about it, the actual threat is minuscule. People tend to make a mountain out of a mole hole when they first learn about IL.

Second, if there really, really, really is a genuine need to "protect" your IP, then you have to use the right tools for the job. If money is an issue, you can't afford the tools to properly protect .Net code, and you are already comfortable with VC++ then the solution should be fairly obvious. Take advantage of .Net where you can and put your sensitive IP in a VC++ dll you load at runtime and the problem (at least from an IL perspective) is solved.

Don’t make things harder than they need to be. Building great software is already hard enough.
 
IngisKahn, you know that an interface is not the same as a class definition. An interface is an intermediate step with certain restrictions.

It is no huge undertaking, but one would need to search the assembly for the needed type and use reflection to instantiate it. This gets to be a pain if you are working with more complex classes or object models, but this isn't even a big issue. You lose inheritance (you gain interface inheritance, but lose class inheritance). Modifications and additions to the class must be reflected in the interface (otherwise there is no design-time or compiler support for new members). You would also have to duplicate code comments if you use them. In other words, you have to define your class interface twice to make it work.

I didn't say that it was an impossible solution or that it wasn't viable. All I said was "It can work, but I don't think it would be worth the trouble."
 
Back
Top