我一直在阅读Stack Overflow很长一段时间,但这是我发布的第一个问题。
我有用C#编写的跟踪程序,它收集有关本地计算机使用情况的信息并将它们发送到服务器。数据是XML格式的,每10分钟发送一次。
我的问题:无论我如何加密XML数据(无论是对称的还是非对称的),总有人可以反编译我的C#跟踪程序,找出我使用的密钥/证书/加密约定并编写另一个发送虚假报告的程序到服务器。
跟踪程序的工作原理是运行它的用户可能有兴趣发送虚假报告。
问题: 1)我如何确保(尽可能确保)数据是从真正的跟踪器而不是克隆/ faker发送的? 2)如何对代码进行严格的混淆,以至于恢复密钥/证书/加密约定变得难以置信?
我想在解决方案上花费很少或者最好没有钱(因此500美元的混淆器是不可能的。我是一名大学生,而且我很便宜:)。
提前致谢。
答案 0 :(得分:2)
作为Raph Koster once put it,撰写有关在客户端 - 服务器在线游戏中与黑客的斗争,
永远不要相信客户。永远不要在客户端放任何东西。客户掌握在敌人手中。永远不要忘记这一点。
不幸的是,对于几乎所有需要使用客户端处理能力的实际应用程序,必须将某些放在客户端上,因此可供恶意攻击者使用。必须提出的问题 - 与任何安全措施一样 - 是您准备花多少时间和金钱来减轻这种风险?
有些人喜欢向人们询问有关混淆或客户端许可机制的问题,“哦,没有意义,最终会被打破”。但这是错过了重点:这些措施的目的是将“最终”进一步推向未来,以至于对于一个不够坚定的攻击者来说,它将是“从不”。
例如:如果您的应用通过明文电子邮件发送其数据,那将会击败大约零攻击者。在rot13电子邮件中发送它可能会击败5%的攻击者。使用用户名作为密钥加密发送它会失败更多。使用免费的混淆器模糊发送代码会失败更多。使用商业级混淆器进行混淆会使失败更多。要求每个客户都有一个硬件加密狗,就会像人们所说的那样击败“除了最坚定的”攻击者之外的所有人 - 但这可能是一个无法容忍的代价。
从“我是大学生”我猜这不是最敏感的项目。使用免费的混淆器并使用一些特定于用户的信息作为密钥来处理发送的数据。那可能会。
答案 1 :(得分:1)
理论上,在不受信任的环境中运行时,应用程序根本无法保护自己。所以,第一个问题的答案是,“你永远不能确定数据是由真正的跟踪器发送的。”
在实践中,混淆会阻止攻击者达到某种程度。这一点取决于混淆的质量和攻击者的动机。因此,第二个问题的答案取决于攻击者是谁,他们有多能干,以及他们可能适用于这个问题的资源。对于一个无动于衷的外行人来说,“地狱/下一个不可能”的混淆可能对专家或可以聘请专家的人来说是微不足道的。
一些C#混淆器的答案 2 :(得分:1)
客户端用户是否拥有该计算机的管理员权限?这听起来像是由管理员安装的应用程序,但非管理员用户使用。如果是这样,也许您可以存储受普通用户保护的密钥或散列,并在管理员用户的上下文中运行应用程序。我不是很熟悉密钥库,但我希望所有版本的Windows(至少XP +)都可以使用这个功能。如果不是密钥库,则可能是位于属于admin用户的加密目录中的文件。
如果您的目标用户具有本地管理员权限,那么我真的不知道如何阻止他们。
答案 3 :(得分:1)
似乎相当无望。您的跟踪器可能依赖Windows来提供指标,例如最终调用GetUserName()/ GetTickCount()/ CollectPerformanceData()/ etc。因此,一个坏人只需要在任何感兴趣的Windows入口点捕获你的代码(不管它是多么混淆,而且不需要反编译),替换假数据,让你的代码继续它的快乐方式。
生命太短暂,无法击败那些砖墙。
答案 4 :(得分:1)
我们一直在使用硬件解决方案来提供所需的功能。
我一直在使用名为IronKey的产品,它是一种能够生成数字签名的硬件设备。当我们发布设备时,我们将公钥存储在我们的服务器上。当我们的客户端应用程序提交数据时,我们使用私钥生成签名,一旦我们收到数据,我们就可以验证它是否是使用公钥从正确的客户端发送的。
答案 5 :(得分:0)
1.另一种方法: 假设您不经常更改可执行文件。制作你的(HASH +加密)你的客户端可执行文件图像的DigSig并将其与之一起发送,这将验证您的客户端是真实客户端而不是修改版本。
但这不能阻止数据由完全不同的客户端发送,该客户端可以获取Digsig的可执行图像。