How can I hide the details within my .NET executable?

Question

If I have a simple CRUD app executable in .NET, what prevents a user from loading it into RedGate Reflector and viewing all the contents, including db connection strings, passwords, etc?

Can I protect against this in any way?

Answer 1

Obfuscation would be an option. But I guess you cannot hide e.g. password strings completely. That's really unsafe.

Answer 2

You can make it hard to do so (obfuscation, string encryption, etc.) but it will never be impossible to reverse-engineer as long as the user has access to the executable.

Answer 3

No, the best you can do is obfuscate the assembly to make it harder to read and understand but other than that there is not way to stop someone from using Reflector or ILDASM to view the IL in your assembly.

Remember that the CLR needs to be able to read this assembly as well so if the CLR can read the assembly, so can anyone else.

Answer 4

including db connection strings, passwords

Define security in the database engine: limit users, limit machines from which users can connect, limit what users can do, and/or specify that users may interact with the database only via defined "stored procedures".

Answer 5

It depends what you want to protect.

If it's DB connection string with passwords, then don't store them, Example: set up IIS App Pool to run a limited service account to connect to the database and the trusted security. Assuming decent database security, knowledge of servername etc is useless.

Answer 6

Obfuscation is never the right answer. Maybe you're going about this the wrong way.

There are several ways I can think of so that the connection string is either not available or not important.

You could put your database behind a web service so that the connection string to the database would only be known to the web service. Of course, you'd need another way to restrict access to the web service, such as using login credentials.

Or, you could give each user their own SQL login name/password. That way, they would know their own userid/password but it would be easy to "turn it off" from the database. This also gives you much better control over each person's access to the database itself... like what tables/views they have access to, and what type of access.

Answer 7

You should consider using .NET code protection tools, obfuscation often yields many issues related to usage of reflection API, XML serialization or other .NET facilities and therefore enforced you to go through additional QA cycles to make sure your code wasn't broken. My company uses a .NET code protection called CliSecure (http://www.secureteam.net) solution that dynamically integrates with the .NET framework to provide per method decryption capabilities and minimize risk to decrypted code in memory.