在您无法控制的系统上验证客户端基本上是不可能的。

这并不意味着它不能做到足够的程度。例如，电子书阅读器通常会尝试确保客户是真实的。他们（似乎）这样做的方式足够安全，可以抵御他们的威胁。足以保护核机密？不，但对于他们的威胁环境来说已经足够了。

弄清楚该控件对您的应用程序的重要性，并确定您将实施的补偿控件以限制在有人遇到拆解然后模仿您的应用程序的麻烦时造成的损害。不要从黑/白、可能/不可能的角度去思考；考虑可接受和可实现的安全性。

根本不可能验证您的客户端的未修改版本是否连接到您的服务器。

...除非您采取必要措施来确保它。这意味着客户端防篡改硬件。

当您的代码在客户端计算机上运行时，计算机所有者可以运行调试器并使用任意值随时修改客户端代码。“调试器”可以是一个成熟的虚拟机。如果你想避免这种情况，你可以尝试参与一个精心设计的捉迷藏游戏，在其中你想象额外的检测系统，攻击者使用他们自己的工具变体来对抗这些。这是人们试图设计反作弊软件解决方案（例如PunkBuster）的问题；这也是想要销售视频点播服务同时阻止客户将视频保存在本地然后发布到各种文件共享平台上的人们的问题。

总而言之，这些保护措施效果不佳，即使要保护的数据与某些游戏中的额外生命一样微不足道。

为了避免这种情况，你必须让你的代码在受保护的硬件上运行，这将保护自己免受假定所有者的深入检查。这是游戏机、支付终端和智能卡的模型。

TPM是一种折衷的尝试：在普通 PC 中运行的防篡改模块；这里的假设是普通用户会发现修改硬件太难了，例如，在不通过 TPM 模块（例如 CPU）监督下的部分的情况下读取和写入所有 RAM。

如果客户端没有这样的硬件，您尝试做的事情将无法正常工作。除非更改客户端代码没有任何价值，甚至没有人尝试过。这一切都取决于这里所涉及的东西的价值。

您可以尝试加密混淆（如果存在）

加密混淆是在某种意义上使程序源代码不可读的地方。然后，您可以将加密密钥硬编码到程序中。您还希望服务器为您的程序提供随机种子，因为计算机无法被信任。这种方法的唯一问题是密码混淆是它还没有被实现，而且只有某些意义是可能的。

我也曾与我工作的公司处理过这样的问题。经过数周的努力，答案是不可能的。

这就是为什么：

您基本上遇到了“受信任的客户”问题。客户端代码在用户的 PC 上运行，用户可以完全控制其来源的 PC。用户可以更改程序在磁盘上的字节数，在某些情况下甚至在内存中。如果您要尝试对代码执行散列或校验和，他可以简单地更改进行验证的代码并使其返回“未修改”。这是一种烟雾缭绕的策略。

您可以尝试使恶意用户的事情变得更加困难，但是没有实际的方法可以实现您的期望。并非没有它成为一个大头痛。