我如何确保有人没有发送虚假数据？
我阅读 Stack Overflow 已经有一段时间了，但这是我第一个发布的问题。
我有一个用 C# 编写的跟踪程序，它收集有关本地计算机使用情况的信息并将其发送到服务器。数据采用 XML 格式，每 10 分钟发送一次。
我的问题：无论我如何加密 XML 数据（无论是对称还是非对称），有人总是可以反编译我的 C# 跟踪程序，找出我使用的密钥/证书/加密约定，并编写另一个向服务器发送虚假报告的程序。
跟踪程序的工作原理是假设运行该程序的用户可能有兴趣发送虚假报告。
问题： 1）我如何确保（尽可能确保）数据是从真实的跟踪器而不是克隆/伪造者发送的？ 2）我怎样才能将代码混淆得足够严重，以至于恢复密钥/证书/加密约定变得地狱/几乎不可能？
我想在解决方案上花很少的钱或最好不花钱（所以 500 美元的混淆器是不可能的。我是一名大学生，而且我很便宜:)
提前致谢。
I've been reading Stack Overflow for quite some time, but this is my first posted question.
I have this tracking program written in C# which collects information about local computer usage and sends them to a server. The data is XML-formatted, sent once per ~10 minutes.
My problem: no matter how I encrypt the XML data (be it symmetric or asymmetric), someone could always decompile my C# tracking program, figure out the key/certificate/encryption conventions I use and write another program that sends fake reports to the server.
The tracking program works under the assumption that the user running it may be interested in sending fake reports.
Questions:
1) how can I make sure (as sure as possible) that the data is send from the real tracker instead of a clone/faker ?
2) how can I obfuscate the code badly enough that recovering keys/certificates/encryption conventions becomes hell/next to impossible ?
I want to spend little or preferably no money on the solution (so 500$ obfuscators are out of the question. I'm a university student and I'm cheap :)
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
正如 Raph Koster 曾经说过的，写的是客户端中与黑客的战斗-服务器网络游戏，
不幸的是，对于几乎所有需要使用客户端处理能力的实际应用程序来说，必须在客户端上放置一些东西，因此恶意攻击者可以利用这些东西。与任何安全措施一样，必须提出的问题是您准备花费多少时间和金钱来减轻这种风险？
有些人喜欢向询问混淆或客户端许可机制的人指出，“哦，没有意义，它最终会被打破”。但这没有抓住要点：此类措施的目的是将“最终”推向更远的未来，以至于对于不确定的攻击者来说，这将是“永远”。
例如：如果您的应用程序通过纯文本电子邮件发送数据，那么攻击者大约为零。通过 rot13 电子邮件发送大约可以击败 5% 的攻击者。使用用户名作为密钥加密发送它会失败更多。使用免费的混淆器混淆发送代码会失败更多。使用商业级混淆器进行混淆会失败更多。正如人们常说的那样，要求每个客户端都拥有一个硬件加密狗将击败“除了最坚定的”攻击者之外的所有攻击者，但这可能是一个难以忍受的成本。
从“我是一名大学生”来看，我猜这不是有史以来最敏感的项目。使用免费的混淆器并使用一些特定于用户的信息作为密钥来加密发送的数据。大概就可以了。
As Raph Koster once put it, writing about the battle against hackers in client-server online games,
Unfortunately, for pretty much any real-world application that requires that the processing power of the client is used, something has to be put on the client, and therefore because available to a malicious attacker. The question that has to be asked - as with any security measure - is how much time and money are you prepared to spend mitigating this risk?
Some people like to point out to people asking about obfuscation or client-side licensing mechanisms, "oh there's no point, it will be broken eventually". But this is to miss the point: that the purpose of such measures is to push that 'eventually' further into the future, to the point that for an insufficiently-determined attacker, it will be 'never'.
For example: if your app sent its data by plaintext email, that would defeat approximately zero attackers. Sending it in rot13 email would defeat maybe 5% of attackers. Sending it encrypted using the username as a key would defeat more. Obfuscating the sending code with a free obfuscator would defeat more. Obfuscating with a commercial-grade obfuscator would defeat more. Requiring each client to have a hardware dongle would defeat 'all but the most determined' attackers, as people like to say - but this would probably be an intolerable cost.
From "I'm a university student" I'm guessing this isn't the most sensitive project ever. Use a free obfuscator and cnrypt the sent data using some user-specific information as the key. That'll probably do.
理论上，应用程序在不受信任的环境中运行时根本无法保护自身安全。因此，第一个问题的答案是：“您永远无法确定数据是由真正的跟踪器发送的。”
实际上，混淆会在一定程度上阻止攻击者。该点由混淆的质量和攻击者的动机决定。因此，第二个问题的答案取决于攻击者是谁、他们的能力如何以及他们可能会使用哪些资源来解决这个问题。对于一个没有动力的外行来说“地狱/几乎不可能”的混淆对于专家或可以聘请专家的人来说可能是微不足道的。
以下是一些 C# 混淆器的列表。
In theory, an application simply cannot secure itself when running in an untrusted environment. So, the answer to the first question is, "You can never be sure that data are sent by the real tracker."
In practice, obfuscation will thwart attackers up to a point. The point is determined by the quality of the obfuscation and the motivation of the attacker. So, the answer to the second question depends on who the attacker is, how capable they are, and what resources they might apply to this problem. Obfuscation that is "hell/next-to-impossible" for an unmotivated layman to to unravel might be trivial for an expert, or someone who can hire an expert.
Here is a list of some C# obfuscators.
客户端用户是否拥有机器的管理员权限？这听起来像是由管理员安装但由非管理员用户使用的应用程序。如果是这样，也许您可以存储您的密钥或哈希以防止普通用户访问，并在管理员用户的上下文中运行该应用程序。我不太熟悉密钥存储，但我希望所有版本的 Windows（至少 XP+）都可以使用此功能。如果不是密钥存储，则可能是位于属于管理员用户的加密目录中的文件。
如果您的目标用户具有本地管理员权限，那么我真的不知道如何阻止他们。
Will the client user have administrator rights over the machine? It sounds like the kind of app that would be installed by an admin, but used by non-admin users. If so, maybe you could store your key or hash protected from normal users, and run the app in the context of the administrator user. I'm not really familiar with the key store, but I'd expect all versions of Windows (at least XP+) would have this functionality available. If not the key store, then maybe a file located in an encrypted directory belonging to the admin user.
If your target user has local admin rights, then I really don't see how you can stop them.
看起来相当无望。您的跟踪器可能依赖于 Windows 来提供指标，例如通过最终调用 GetUserName()/GetTickCount()/CollectPerformanceData()/等。因此，坏人只需在任何感兴趣的 Windows 入口点捕获您的代码（无论它有多模糊，也无需反编译），替换假数据，然后让您的代码继续正常运行。
人生苦短，没必要用头撞那些砖墙。
It seems fairly hopeless. Your tracker probably relies on Windows to provide the metrics, such as by ultimately calling GetUserName()/GetTickCount()/CollectPerformanceData()/etc. So, a bad guy just has to trap your code (regardless of how obfuscated it is, and without bothering to decompile) at any Windows entrypoint of interest, substitute the fake data, and let your code continue on its merry way.
Life's too short to beat your head against those kinds of brick walls.
我们一直在使用硬件解决方案来提供所需的功能。
我一直在使用一种名为 IronKey 的产品，它是一种能够生成数字签名的硬件设备。当我们发行设备时，我们将公钥存储在我们的服务器上。当我们的客户端应用程序提交数据时，我们使用私钥生成签名，一旦我们收到数据，我们就可以使用公钥验证它是否是从正确的客户端发送的。
We have been using a hardware solution to provide this required functionality.
I have been working with a product called IronKey, it is a hardware device that is capable of generating digital signatures. When we issue the device we store the public key on our server. when our client application submits data we generate a signature using the private key, once we receive the data we can verify that it was sent from the correct client using the public key.
1.另一种方法：
假设您不经常更改可执行文件。对您的客户端可执行文件映像进行 DigSig（哈希+加密）并将其一起发送，这将验证您的客户端是否为真实客户端，而不是修改后的版本。
但这不能阻止数据由完全不同的客户端发送，该客户端可以获取可执行映像的 Digsig。
1.Another approach:
Assuming you don't change your executable often. make a DigSig of your(HASH+Encrypt) your client executable file image and send it along with, that would authenticate your client as the real client and not a modified version.
But this cannot prevent data being sent by a totally different client which can aquire the Digsig of your Executable image.