我们正在编写一个本地Windows应用程序（MFC），它将上传一些数据到我们的Web应用程序。 Windows应用程序将允许用户登录，之后它会定期上传一些数据到我们的网络应用程序。上传将通过简单的HTTP POST完成到我们的网络应用程序。我所关心的是我们如何确保上传实际上来自我们的应用程序，而不是来自curl或类似的东西。我想我们正在寻找某种公钥/私钥加密。但我不确定我们是否可以在我们的win应用程序可执行文件中嵌入一个公钥并完成它。或者这个公钥太容易提取并在我们的应用程序之外使用？如何确保HTTP上传来自真实的可执行文件
无论如何，我们正在构建双方（客户端和服务器），因此相当多的东西是一种选择，但它通过HTTP（S）工作。但是，我们不控制win（客户端）应用程序的执行环境，加上在其系统上运行应用程序的用户是唯一能够通过游戏系统获取内容的用户。
归根结底，这是不可能的，以证明申请者的身份时，这是你没有自己的机器上运行这种方式。您可以嵌入密钥，玩哈希和校验和，但是在一天结束时，任何依赖运行在别人机器上的代码都可能是伪造的。密钥可以被提取，代码可以被反向设计 - 通过默默无闻的所有安全。
把时间花在验证和数据清理工作，如果你真的想保护的东西，有一个客户端证书保证最终用户。其他任何事情都只是浪费时间和虚假的安全感。
我现在意识到你是对的，而这只会是一种虚假的安全感。但是，如果用户实际上是通过上传假冒/伪造数据尝试游戏系统的用户，那么客户端证书是否会有所帮助？ – nnc 2009-12-27 03:22:37
只有在你知道非常积极的是谁在这么做，如果他们正在危及系统（假设您设置的CRL/OCSP正确的颁发，并在验证服务器上的CA），您可以撤销其证书。 – nitzmahone 2009-12-27 03:51:24
对，控制客户的人可以做任何事情，包括绕过所有的安全措施。这可能采取修改程序内存变量的形式，这是很难防御的（实际上不可能），包括可能在VM中运行它并修改VM外部的内存（修改应用程序的地方不能被检测）。 的OP的最好的办法是尝试验证上传，这样没有什么不好的可能发生，即使垃圾被上传 - 这可能是有一天，由于客户端的错误，反正。 – MarkR 2009-12-27 16:55:53
既然你控制客户端，你还不如嵌入到应用的关键，并确保用户不具有读取访问应用程序图像 - 你需要的逻辑分离到2层 - 1，用户运行，另一个通过HTTP（S）连接到服务 - 因为用户总是可以读取他正在运行的应用程序。
如果我理解正确的，数据是在用户登录后自动发送 - 这听起来像是只需要该服务的一部分。
关于您可以做的最好的做法是使用HTTPS和客户端证书。推测与WinHTTP的界面。
但我不确定我们是否可以以某种方式在我们的win应用程序可执行文件中嵌入一个公钥并完成它。
如果客户要确定自己的服务器，它必须是嵌入式的私钥。
或者是否太容易提取和使用我们的应用程序？
如果不控制客户端应用程序的执行环境，什么你的应用程序可以做，可以分析，攻击者，做的是控制环境进行自动化和转载。
你可以把混淆层周围的通信过程，如果你一定要，但你永远不会解决问题。多人游戏多年来一直在努力打击欺诈行为，但最终它只是一场永远无法赢得的迷惑军备竞赛。暴雪有比你更多的资源，他们也无法管理它。
一旦分发了应用程序，您就无法控制二进制文件。如果所有签名和加密逻辑驻留在可执行文件中，则可以将其提取出来。当有足够的动力去做的时候，聪明的编程人员会弄清代码并建立可互操作的系统。这就是DRM不起作用的原因。
一个复杂的系统捆绑一键例如PC的MAC地址是肯定要失败。
不要相信一个特定的可执行文件或系统，而是信任你的用户。委托其中的每一个人使用受密码保护的私钥文件，并向他们解释该密钥是如何将其标识为服务上的内容提交者的。
基于这里的答案，我意识到这个问题没有真正的“解决方案”，因为用户是唯一一个通过游戏系统获得某些东西的人，所以我不认为带有密码的私钥有助于这个案例？ – nnc 2009-12-27 03:18:57
那么，如果用户认为没有任何损害*私人签名*别人及时上传，或者如果将他们的密钥集成到另一个应用程序是他们的优势，那么你可以做的不多。 – 2009-12-27 16:05:16
喜欢的：我有一些想法，但我不是一个真正的加密家伙。希望一个真正的人会漫步，并给出明确的答案。顺便说一句，如果你提出了一个策略，然后让社区对它进行评论，你可能会得到更好的答案。 – 2009-12-26 21:47:08
记住永远不要相信你的用户，他们是骗人的和恶意的。 – 2009-12-27 00:07:40