我们正在编写一个本机 Windows 应用程序 (MFC)，它将向我们的 Web 应用程序上传一些数据。Windows 应用程序将允许用户登录，然后它会定期将一些数据上传到我们的网络应用程序。将通过简单的 HTTP POST 上传到我们的 Web 应用程序。我担心的是我们如何确保上传实际上来自我们的应用程序，而不是来自 curl 或类似的东西。我想我们正在研究某种公钥/私钥加密。但我不确定我们是否可以以某种方式将公钥嵌入到我们的 win 应用程序可执行文件中并完成它。或者该公钥是否太容易在我们的应用程序之外提取和使用？
无论如何，我们正在构建双方（客户端和服务器），所以几乎任何东西都是一种选择，但它必须通过 HTTP(S) 工作。但是，我们不控制 win（客户端）应用程序的执行环境，而且在他/她的系统上运行应用程序的用户是唯一可以通过游戏系统获得收益的用户。
最终，当应用程序在您不拥有的机器上运行时，无法以这种方式证明应用程序的身份。您可以嵌入密钥、使用哈希和校验和，但归根结底，任何依赖于在其他人机器上运行的代码的东西都可能被伪造。可以提取密钥，可以对代码进行逆向工程——这一切都是通过默默无闻来保证安全的。
花时间进行验证和数据清理，如果您真的想保护某些东西，请使用客户端证书保护最终用户。其他任何事情都只是浪费时间和虚假的安全感。
您能做的最好的事情就是将 HTTPS 与客户端证书一起使用。大概是用WinHTTP的接口。
但我不确定我们是否可以以某种方式将公钥嵌入到我们的 win 应用程序可执行文件中并完成它。
如果客户端要向服务器标识自己，它必须是嵌入的私钥。
或者这是否太容易在我们的应用程序之外提取和使用？
如果您不控制客户端应用程序的执行环境，那么您的应用程序可以做的任何事情都可能被控制该环境的攻击者分析、自动化和复制。
如果必须，您可以在通信过程周围放置一些混淆层，但您永远无法解决问题。多人游戏多年来一直试图这样做以打击作弊，但最终这只是一场永远无法获胜的混淆军备竞赛。暴雪的资源比你多得多，他们也管不了。
分发应用程序后，您无法控制二进制文件。如果所有签名和加密逻辑都驻留在您的可执行文件中，则可以将其提取出来。当有足够的动机时，聪明的编码人员会找出代码并构建可互操作系统的系统。这就是 DRM 不起作用的原因。
例如，将密钥与 PC 的 MAC 地址绑定的复杂系统肯定会失败。
不要信任特定的可执行文件或系统，但要信任您的用户。将受密码保护的私钥文件委托给他们每个人，并向他们解释该密钥如何将他们识别为服务内容的提交者。
由于您正在控制客户端，因此您不妨将密钥嵌入应用程序中，并确保用户没有对应用程序映像的读取权限 - 您需要将逻辑分为 2 层 - 1 即用户运行，另一个通过 HTTP(S) 连接到服务 - 因为用户将始终对他正在运行的应用程序具有读取权限。
如果我理解正确，数据会在用户登录后自动发送 - 这听起来像是只需要服务部分。