您描述的场景与“远程证明”的概念非常相似。对此进行了大量的研究，主要有两个结果：

• 您需要一个信任锚（例如 TPM 或受信任的系统服务）来安全地测量您的应用程序并将结果报告给服务器。否则，您始终可以构建一个生成正确响应的模拟器[1]。

• 一旦您部署和使用了所有受信任的计算基础设施，您仍然无法比部署当今的标准防缓冲区溢出技术更有保证地防止甚至检测应用程序中的漏洞利用。

因此，如果您想在今天部署它，最好的选择是代码混淆。基本上，您想要实施一种复制保护机制，就像它已经实施和破坏了几十年一样。

[1] 有一些非常酷的进步利用客户端平台的计算和通信限制，但这仍然是科幻小说。

这个场景有什么缺陷？

这里的基本缺陷是您假设远程方遵守您的规则。

您有一个带有程序的服务器。

您收到下载请求。

此时您不知道远程下载器是谁或什么。

下载后，对手可以将其保存在任何他们喜欢的地方。他们可以尝试在多种调试器、仿真器或物理硬件中的任何一种中运行您的程序。对手在调试、反汇编、运行、修改或分析时阻止您的程序与任何远程系统通信是非常简单的。

有人能够反汇编算法以计算程序的哈希值，然后修改程序以将相同的值发送到服务器？

将哈希发送到服务器的基本问题是没有动机允许程序发送该哈希。

想象一个带有应用防火墙的标准设备。用户无需修改即可下载并运行您的程序。当您的程序尝试将哈希发送到服务器时，应用程序防火墙会弹出一个对话框，询问“应用程序您的应用程序正在尝试连接到互联网，您要允许这样做吗？” 用户没有动力说是。

现在想象一个对手修改了你的程序。他们在带有应用程序防火墙的标准设备中运行您的应用程序。现在，当应用程序防火墙弹出一个对话框。攻击者有动机不允许程序与服务器通信。

你认为这对某人来说仍然是很多工作，而且可能不值得吗？

远程验证软件的问题是一个已经研究了几十年的基本问题。有些方法适用于特定场景和潜在的攻击者。但是，没有通用的解决方案。

对于您的场景，一些远程用户可以完全控制目标硬件平台，应用程序二进制文件很容易反汇编，并且用户没有动机让您的应用程序与您的服务器通信，充其量您会检测到很少的总修改。在最坏的情况下，每一次修改都不会被报告，未修改的报告会给你一种错误的感觉，即没有人在修改你的软件。

关于扩展：

您提出的方案也很容易破解：我记录您的软件发送到服务器的哈希值，然后修改应用程序并在服务器请求时回复哈希值。即使您制定了挑战-响应式协议（以提供新鲜感），我也可以调试您的应用程序以了解您如何生成响应。这种攻击通常总是可能的，您的安全性完全取决于混淆和反调试技术的数量。您可能会以中等安全性欺骗 90% 的客户端，但请记住，它只需要一个人为您的程序发布“破解”，然后每个人都可以使用修改后的版本，将正确的哈希发送到您的服务器。

当前关于该主题的研究的关键词是“软件证明”或“安全移动代理”。这些机制只有在一些在实践中难以实现的相当强的要求下才是安全的（谷歌“关于软件证明的难度”和“基于 PUF 的证明”）。

在实践中解决此类问题的最佳方式，此时此地，是将服务的重要部分移至服务器。如果实际价值来自与服务器的通信，那么作弊的动机就会少得多。考虑在线游戏。也许您可以拥有一些“社交功能”，例如排名、聊天室或您从服务器提供的其他服务？

你可以让攻击者更难修改文件，但你不能阻止修改你最终泄露给攻击者的任何东西。

这是假设攻击者可以完全访问他的计算机。Trusted Computing Group和其他供应商正在做一些工作来限制所有者的能力。那些信任计算模块多用于游戏机和智能手机。但是，一旦这种保护被移开（例如手机被“root”），上面的段落就适用了。

这些修改包括发送到服务器的校验和。举一个值得注意的例子：在荷兰，Nedap 的首席执行官声称他们的投票计算机是一台专用的专用机器，只能用于选举，不能用于其他用途。WVSN 和 CCC 向其移植了一个开源国际象棋程序，以证明 CEO 错了。作为保护的一项特殊功能，投票计算机有一个按钮，用于计算程序的校验和并显示它以防止操纵。国际象棋程序确实显示了相同的数字。（Heise的德文文章）。

您可以通过使用许多不同的校验和而不是简单地使用它们而是作为计算的一部分来使其变得更加困难：Skype 使用校验和来计算JMP 的目标作为一种反调试技术。标准断点会修改被调试的程序，从而导致它跳转到错误的位置。Skype 最终通过以 oracle 运行第二个副本进行了逆向工程。（Skype中的银针）

另一个可能更适合您的目标的例子是 SecondLife。Second Life 是一款在线游戏，玩家可以在其中创建和销售自己的内容。尽管他们的 DRM 任何类型的信息，即发送给客户端（纹理、动画、声音），都被非法复制。只有保存在服务器上的信息（用户脚本）是安全的。我在是否有 DRM 技术可以有效防止盗版？