保护 Delphi 应用程序中的字符串
我们有一个驱动 MS SQL Server 数据库的 Delphi 2006 应用程序。
我们发现了一个漏洞，可以将可执行文件加载到十六进制编辑器中并修改 SQL。
我们的长期计划是将此 SQL 移至 CLR 存储过程，但这还有一段路要走，因为我们的许多客户仍在使用 SQL 2000。
我们考虑过混淆字符串，有人推荐用于执行此操作的工具吗？
有没有更好的解决方案，也许是代码签名？
We have a Delphi 2006 application that drives a MS SQL Server database.
We have found a vulnerability where it is possible to load the executable into a hex editor and modify the SQL.
Our long term plan is to move this SQL to CLR stored procedures but this is some way off since many of our clients still use SQL 2000.
We've thought about obfuscating the strings, does anyone have a recommendation for a tool for doing this?
Is there a better solution, maybe code signing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
很抱歉直言不讳，但如果您正在考虑在可执行文件中应用“安全”措施，那么您就注定失败。任何加扰方案都无法留住普通黑客。
您还没有解释您的应用程序是如何设计的。数据库是由您托管还是驻留在您客户的场所？如果是后者，那么就忘记安全性并开始聘请律师以获得良好的保密合同，以便您的客户表现良好。如果是前者，那么使用存储过程是最简单的方法。
Sorry for being blunt, but if you are thinking of applying "security" measures in your executable you are doomed. No scrambling schema will retain an average hacker.
You also haven't explained how is your app designed. Is the database hosted by you, or resides in your client's premises? If the latter, then just forget about security and start hiring a lawyer to get a good confidentiality contract so your clients behave. If the former, then using stored procedures is the easiest way.
如果嵌入式 SQL 遭到黑客攻击，则意味着您的数据库是相当开放的，任何拥有 MSQRY32.EXE（即 MS Office）的人都可以获取您的数据。
如果您是供应商，那么您不能依赖在客户端启用 CLR。那么，为什么不在版本无关的数据库中使用非 CLR 存储过程和正确的权限呢？
If embedded SQL is being hacked, then it implies that your database is quite open and anyone with MSQRY32.EXE (that is, MS Office) can get your data.
If you are a vendor, then you can't rely on CLR being enabled at your clients. So, why not use non-CLR stored procedures and correct permissioning in the database that is version independent?
这不是一个漏洞。如果你的机器很容易让人在本地修改 EXE，那么这就是你的漏洞。
所有 EXE 都可能被黑客攻击，如果有人拥有本地管理员帐户访问权限，那么您的游戏在他们接近您的资源字符串之前就已经结束了。
This is not a vulnerability. If your machines are vulnerable to having people locally modify EXEs, that is your vulnerability.
All EXEs can be hacked, if someone has local admin account access, your game is over long before they get near your resource strings.
完全保护是不可能的，但你可以让“随意攻击”变得更加困难。我使用的简单系统是“ROT47”类型系统，它类似于 ROT13，但范围更广。然后代码如下所示：
这里的关键是我有一个包含字符串的注释，这样我就可以看到它，但更重要的是我在 FinalBuilder 构建脚本中运行的实用程序也可以看到它。这使我能够确保发布代码中的字符串始终是最新的。该实用程序在行中查找 {CODEME，如果找到，则知道要正确输出的数据的格式。
It will never be possible to protect completely, but you can make "casual attack" harder. The simple system that I use is a "ROT47" type system which is like ROT13 but wider ranging. The code then gets to look like the following:
The key here is that I have a comment which includes the string so both I can see it, but more importantly so can the utility that I run in my FinalBuilder build script. This allows me to ensure that strings are up-to-date at all times in release code. The utility looks for {CODEME in the lines, and if found knows the format of the data to output appropriately.
需要对应用程序进行深度重构的解决方案是使用多层方法 - 大部分 SQL 代码将位于应用程序服务器模块中，服务器上的代码应该比客户端 exe 受到更多保护。
A solution that would require a deep restructuring of the application would be to use a multi-tier approach - most the of the SQL code would be in the application server module, that being on a server should be more protected than a client side exe.
您不能加密所有查询并将它们放入资源文件中吗？
在运行时，首先您必须：
然后您只需像以前一样运行查询即可。
这应该不是什么大问题。当然，如果您没有将查询存储在某些资源/文件夹中，那么您需要稍微重构您的应用程序。但无论如何你都应该以某种有组织的方式存储它们。因此，您将在这里一石二鸟；-)
为了对字符串进行加密，您可以使用名为 DCPCrypt 的免费库。
Can't you encrypt all your queries and put them to the resource file?
During runtime, firstly you would have to:
Then you just run your query as before.
That should not be a big problem. Of course if you are not storing your queries in some resource / folder than you need to refactor your application a bit. But you should store them anyway in some organized manner. So you will be hitting a two birds with one stone here ;-)
For encryption of the strings you could use a free library called DCPCrypt.
我认为你应该使用 exe 打包程序 这使得任何人都很难使用十六进制修改内容编辑。
I think you should use a exe packer which makes it hard for anyone to modify the stuff using hex editor.
首先 - 分析你的威胁。谁在利用你的漏洞，为什么这是一个问题。然后采取相应行动。
如果您的应用程序是 win32 并且您的威胁是一些只是玩得开心的孩子，那么免费的 exe 加壳器（例如 upx）可能是解决方案。在 .NET 应用程序上，签名可能就是您想要的。
如果您需要更多，那么成本将会很高，并且开发应用程序也会更加困难。也许您甚至需要重组它。商业保护方案是可用的（也许使用加密狗？） - 甚至是将字符串存储在某些外部硬件上的保护方案。如果硬件不存在，则没有 SQL 字符串。但是，正如我所说，那更贵。
First - do an analysis of your threat. Who is using your vulnerability, why is this a problem. Then act accordingly.
If your application is win32 and your threat are some kids witch are just having fun, a free exe packer (e.g. upx) might be the solution. On .NET applications signing might be what you want.
If you need more than that, it's going to be expensive and it's going to be more difficult to develop your application. Perhaps you even need to restructure it. Commercial protection schemes are available (perhaps with dongle?) - even protection schemes where you store your strings on some external hardware. If the hardware is not present, no SQL-Strings. But, as I said, that's more expensive.
将数据库接口移至存储过程。 普通常规存储过程，无需任何 CLR。如果您已经有要放入的查询，这没什么大不了的。
如果您出于某种原因不想学习 T-SQL，只需将所有查询字符串移动到数据库并存储在应用程序单个查询中，其目的是仅从数据库中读取具有给定查询 ID 的 SQL 代码。
所有编码技巧都会产生很多麻烦，但不会提供任何真正的安全性，因为必须使用可逆加密（由问题的性质决定）并且所有解码密钥也放置在应用程序可执行文件中。
Move DB interface to stored procedures. Normal regular stored procedures without any CLR. It's not a big deal if you already have queries to put inside.
If you don't want to learn T-SQL for some reasons, simple move all you query string to database and store in application single query, which purpose is reading SQL code with given query ID from database only.
All tricks with encoding produces a lot of troubles, but don't give any real security because must use reversable encrypting (dictated by the nature of the problem) and all keys for decoding placed in application executable too.
有一些“保护”套件可以在运行之前加密和/或验证您的 exe。搜索“加密 exe”或“验证 exe”等可能会有所帮助。通常它们是付费软件，但价格低于 100 美元。
其原理与 exe 加壳器相同（并且有一些缺点，例如更便宜的防病毒启发式有时会对它们做出反应，内存负载略有增加），只是更注重安全性。还有一个问题是，对于大多数 exe 加壳程序来说，都存在解包程序。
我使用 dinkeydongle 的产品，但这种产品也与硬件加密狗相连，因此这可能是您通往远方的桥梁。
There are "protection" suites that encrypt and/or validate your exe before running. searching for "encrypt exe" or "validate exe" or so will probably help. Usually they are payware, but sub $100.
The principle is the same as an exe packer (and has some of its downsides, like cheaper antivirus heuristics sometimes reacting on them, a slightly elevated memory load), just more focussed on security. A problem is also that for most exe packers, depackers exist.
I use dinkeydongle's wares, but that is a kind that also ties into an hardware dongle, so that might be a bridge to far for you.