我想将配置文件绑定到我的可执行文件。我想通过在可执行文件中存储文件的MD5哈希来做到这一点。除了可执行文件之外，任何人都应该修改文件。
基本上如果有人在程序之外修改此文件，程序将无法再次加载它。
编辑：该程序处理信用卡信息，因此能够以任何方式更改配置可能是潜在的安全风险。该软件将分发给大量客户。理想情况下，客户端应具有直接绑定到可执行文件的配置。这有望使黑客无法获得虚假配置。
配置仍然需要编辑，但不能为每个客户编制单独的副本。
重要的是这是动态的。这样我就可以在配置发生变化时将哈希绑定到配置文件中。
答案 0 :(得分：11)
更好的解决方案是将MD5存储在配置文件中。但是MD5不仅仅是配置文件中的MD5，而是在MD5中包含一些秘密的“键”值，如固定的guid。
write(MD5(SecretKey + ConfigFileText));
然后您只需删除该MD5并重新扫描该文件（包括您的密钥）。如果MD5是相同的，那么没有人修改它。这可以防止有人修改它并重新应用MD5，因为他们不知道你的密钥。
请记住，这是一个相当弱的解决方案（正如您所建议的那样），因为他们可以轻松跟踪您的程序以找到密钥或MD5的存储位置。
更好的解决方案是使用公钥系统并签署配置文件。再次这是弱的，因为这将需要私钥存储在他们的本地机器上。几乎任何包含在本地PC上的东西都可以通过足够的努力来绕过。
如果您真的想将信息存储在可执行文件中（我不鼓励），那么您可以尝试在EXE结尾处附加信息。这通常是安全的。修改可执行程序是病毒之类的行为，大多数操作系统安全性也会试图阻止你。如果您的程序位于Program Files目录中，并且您的配置文件位于Application Data目录中，并且该用户以非管理员身份登录（在XP或Vista中），则您将无法更新EXE。 / p>
更新：如果您将密钥存储在用户的计算机上（必须），我不在乎您是使用非对称加密，RSA还是Quantum加密除非您通过Web服务进行路由，否则用户可以找到您的密钥，即使这意味着在运行时检查CPU上的寄存器！你只是给自己买一个中等程度的安全性，所以坚持使用简单的东西。为了防止修改我建议的解决方案是最好的。为了防止读取，然后对其进行加密，如果您在本地存储密钥，则使用AES Rijndael。
更新：也可以在安装时生成FixedGUID / SecretKey，并将其存储在注册表中的“秘密”位置。或者，您可以在每次从硬件配置中使用它时生成它。然后你变得越来越复杂了。如何执行此操作以允许适度级别的硬件更改将采用6种不同的签名，并对配置文件进行6次哈希处理 - 每次一次。将每个值与第二个秘密值组合在一起，如上面提到的GUID（全局或安装时生成）。然后，当您检查时，分别验证每个哈希。只要他们有6个中的3个（或任何你的容忍度），那么你接受它。下次编写时，使用新硬件配置对其进行哈希处理。这允许他们随着时间的推移慢慢更换硬件并获得一个全新的系统。 。 。也许这是一个弱点。这一切都归结为你的宽容。根据更严格的公差，存在各种变化。
更新：对于信用卡系统，您可能需要考虑一些真正的安全性。您应该保留安全和加密顾问的服务。需要交换更多信息。他们需要分析您的具体需求和风险。
此外，如果您希望使用.NET安全性，则需要首先使用非常好的.NET混淆器（just Google it）。 .NET程序集是一种易于反汇编和获取源代码并阅读所有秘密的方法。听起来不像是破纪录，但任何依赖于用户系统安全性的东西从一开始就存在根本性的缺陷。
答案 1 :(得分：1)
出于纯粹的好奇心，如果文件已被更改，你有什么理由不想加载文件？
为什么不保留可执行文件中编译的所有配置信息？为什么要打扰外部文件呢？
<强> 修改
我刚刚阅读了关于这是信用卡信息计划的编辑。这提出了一个非常有趣的挑战。
我认为，对于这种安全级别，某些非常重要的加密是必要的，但我不知道如何以这样的方式处理这种事情，即加密机密不能仅从中提取可执行文件。
是否有可能针对某种在线资源进行身份验证？
答案 2 :(得分：1)
我建议你使用非对称密钥加密来加密你的配置文件，无论它们存储在哪里，都在可执行文件内。
如果我没记错的话，RSA就是变种之一。
有关它的解释，请参阅维基百科上的Public-key cryptography
将“阅读”键存储在可执行文件中，并为自己保留“写入”键。所以没有人可以修改配置。
这有以下优点：
请对如何正确实施它们进行一些研究。
答案 3 :(得分：-2)
只需创建一个包含md5哈希的const字符串并将其编译到您的应用程序中...您的应用程序可以在验证配置文件时引用此const字符串