如何隐藏 .NET 可执行文件中的详细信息？
如果我在 .NET 中有一个简单的 CRUD 应用程序可执行文件，那么是什么阻止用户将其加载到 RedGate Reflector 并查看所有内容，包括数据库连接字符串、密码等？
我可以以任何方式防止这种情况发生吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
不，您能做的最好的事情就是混淆程序集，使其更难以阅读和理解，但除此之外，无法阻止某人使用 Reflector 或 ILDASM 查看程序集中的 IL。
请记住，CLR 也需要能够读取该程序集，因此如果 CLR 可以读取该程序集，那么其他任何人都可以。
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.
混淆永远不是正确的答案。也许你的处理方式是错误的。
我可以想到多种方法，使连接字符串要么不可用，要么不重要。
您可以将数据库放在 Web 服务后面，以便只有 Web 服务知道数据库的连接字符串。当然，您需要另一种方法来限制对 Web 服务的访问，例如使用登录凭据。
或者，您可以为每个用户提供自己的 SQL 登录名/密码。这样，他们就会知道自己的用户名/密码，但很容易从数据库中“关闭它”。这还使您可以更好地控制每个人对数据库本身的访问...例如他们可以访问哪些表/视图以及什么类型的访问。
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.
您可以使其变得困难（混淆、字符串加密等），但只要用户有权访问可执行文件，逆向工程就永远不可能。
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.
定义数据库引擎中的安全性：限制用户、限制用户可以连接的计算机、限制用户可以执行的操作和/或指定用户只能通过定义的“存储过程”与数据库交互。
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".
这取决于你想保护什么。
如果它是带有密码的数据库连接字符串，则不要存储它们，示例：设置 IIS 应用程序池以运行有限服务帐户来连接到数据库和受信任的安全性。假设数据库安全性良好，服务器名称等知识是没有用的。
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.
您可以将密码和连接字符串放入哈希表或 xml 中，然后加密您的数据，制作一个 zip 文件，其中密码隐藏在文本文件中，并通过速记隐藏在图像后面。所有的解压缩和读取都会在读取后在内存中进行释放、刷新内存、调用收集器、在使用连接字符串并填充清理变量后。仅将需要的数据保留在内存中，使用内存时要小心。
You can put your passwords and connection strings in an hashtable or xml then encrypt your data, make an zip file with a password hidden in text file hidden with stenography behind an image. All your unzip and reading make in memory after making a read make a release, flush of memory, call the collector, after using your connection strings and fill clean your variables. Keep only the data you need in memory, be careful in using ram.
混淆将是一个选项。但我想你不能完全隐藏密码字符串。那样真的很不安全。
Obfuscation would be an option. But I guess you cannot hide e.g. password strings completely. That's really unsafe.