保护Delphi应用程序中的字符串

Question

我们有一个驱动MS SQL Server数据库的Delphi 2006应用程序。

我们发现了一个漏洞，可以将可执行文件加载到十六进制编辑器中并修改SQL。

我们的长期计划是将此SQL移至CLR存储过程，但由于我们的许多客户端仍使用SQL 2000，因此这有一段距离。

我们考虑过混淆字符串，是否有人建议使用此工具？

是否有更好的解决方案，可能是代码签名？

Answer 1

对不起直言不讳，但如果您考虑在可执行文件中应用“安全”措施，则注定要失败。没有加扰模式将保留普通黑客。

您还没有解释您的应用是如何设计的。数据库是由您托管还是驻留在您的客户端？如果是后者，那么就忘记安全性并开始聘请律师以获得良好的保密合同，以便客户行事。如果是前者，那么使用存储过程是最简单的方法。

Answer 2

如果嵌入式SQL被黑客入侵，那么它意味着您的数据库已经完全打开，任何拥有MSQRY32.EXE（即MS Office）的人都可以获取您的数据。

如果您是供应商，那么您不能依赖于在您的客户端启用CLR。那么，为什么不在与版本无关的数据库中使用非CLR存储过程和正确的权限呢？

Answer 3

这不是漏洞。如果您的计算机容易让人们在本地修改EXE，那就是您的漏洞。

如果某人拥有本地管理员帐户访问权限，则所有EXE都可能被黑客入侵，您的游戏在接近资源字符串之前已经过了很长时间。

Answer 4

永远不可能完全保护，但你可以更难以“随意攻击”。我使用的简单系统是一个“ROT47”型系统，就像ROT13，但范围更广。然后代码如下所示：

frmLogin.Caption := xIniFile.ReadString(Rot47('$JDE6>' {CODEME'System'}),

这里的关键是我有一个包含字符串的注释，所以我都可以看到它，但更重要的是我可以在我的FinalBuilder构建脚本中运行的实用程序。这允许我在发布代码中始终确保字符串是最新的。该实用程序在行中查找{CODEME，如果找到则知道要正确输出的数据格式。

Answer 5

需要对应用程序进行深度重组的解决方案是使用多层方法 - 大多数SQL代码都在应用程序服务器模块中，在服务器上应该比客户端更受保护旁边的exe。

Answer 6

我认为您应该使用exe packer，这使得任何人都难以使用十六进制编辑器修改内容。

Answer 7

首先 - 对您的威胁进行分析。谁在使用您的漏洞，为什么这是一个问题。然后采取相应的行动。

如果您的应用程序是win32并且您的威胁是某些孩子女巫只是玩得开心，那么自由exe包装工（例如upx）可能就是解决方案。在.NET应用程序上签名可能就是你想要的。

如果您需要更多，那将会很昂贵，而且开发您的应用程序会更加困难。也许你甚至需要重组它。可以使用商业保护方案（可能使用加密狗？） - 甚至是将字符串存储在某些外部硬件上的保护方案。如果硬件不存在，则不使用SQL-Strings。但是，正如我所说，那更贵。

Answer 8

您无法加密所有查询并将其放入资源文件吗？ 在运行时，首先你必须：

1. 从资源加载查询字符串。
2. 解密。

然后你就像以前一样运行你的查询。

这应该不是一个大问题。当然，如果您没有将查询存储在某个资源/文件夹中，那么您需要稍微重构一下您的应用程序。但是你应该以一种有组织的方式存储它们。所以你将在这里一石二鸟： - ）

对于字符串的加密，您可以使用名为DCPCrypt的免费库。

Answer 9

1. 将DB接口移至存储过程。 Normal regular stored procedures没有任何CLR。如果你已经有问题要进去，这不是什么大问题。

2. 如果由于某些原因不想学习T-SQL，可以简单地将所有查询字符串移动到数据库并存储在应用程序单个查询中，其目的是仅从数据库读取具有给定查询ID的SQL代码。

所有带编码的技巧都会产生很多麻烦，但不提供任何真正的安全性，因为必须使用可逆加密（由问题的性质决定）和所有用于解码的解码密钥可执行的。

Answer 10

有“保护”套件可在运行前加密和/或验证您的exe。搜索“加密exe”或“验证exe”左右可能会有所帮助。通常它们是付费软件，但低于100美元。

原理与exe打包程序相同（并且有一些缺点，比如更便宜的防病毒启发式有时会对它们做出反应，内存负载略微增加），更侧重于安全性。问题还在于，对于大多数包装商而言，存在拆包商。

我使用的是dinkeydongle的商品，但这种商品也与硬件加密狗有关，所以这可能是你的桥梁。