为加密狗附加系统编写什么代码才能提供更好的安全性？
我开发了一个软件（使用 C 和 Python），我想用加密狗对其进行保护，以便复制和逆向工程变得足够困难。我的加密狗设备附带一个 API，它提供以下功能：
- 检查加密狗是否存在
- 检查正确的加密狗
- 写入加密狗中的内存位置
- 从加密狗中的内存位置读取等（我认为其余的不太好..）
我能做什么放在源代码中，使其变得更难破解。加密狗提供商建议，我应该在循环中或事件之后检查加密狗是否存在，或者我应该以高效的方式使用加密狗内存。但如何呢？我不知道饼干是怎么裂开的。请透露一些信息。提前致谢。
PS：请不要建议混淆。我已经这么做了。
I have developed a software piece (with C and Python) which I want to protect with dongle so that copying and reverse engineering becomes hard enough. My dongle device comes with an api which provides these:
- Check dongle existence
- Check proper dongle
- Write into a memory location in dongle
- Read from a memory location in dongle etc. (I think the rests aren't that good..)
What I can do in the source code so that it becomes harder to crack. Dongle provider suggested that, I should check proper dongle existence in a loop or after an event, or I should use the dongle memory in an efficient way. But how? I have no idea how crackers crack. Please shed some light. Thanks in advance.
P.S: Please don't suggest obfuscating. I have already done that.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
首先，要认识到加密狗只会提供一点点障碍。知道自己在做什么的人只需删除对加密狗的调用，并为调用的任何结果输入“true”。每个人都会告诉你这一点。但您可以添加一些障碍！
我会找到你的代码的关键部分，一些很难或很难知道的东西，一些需要领域知识的东西。然后将这些知识放到钥匙上。着色器例程就是这样的一个例子。着色器例程是发送到图形卡以实现特定效果的文本文件；一个非常简单的亮度/对比度过滤器将需要不到 500 个字符来实现，并且您可以将其存储在大多数加密狗的用户空间中。然后，您将该信息放在密钥上，并且仅使用密钥中的信息来显示图像。这样，如果有人试图简单地删除您的加密狗，您程序中的所有图像都将被涂黑。需要有人拥有您的程序的副本，从密钥中获取文本文件，然后修改您的程序以包含该文本文件，然后知道该特定文件将是显示图像的“正确”方式。实施细节取决于您的部署平台。例如，如果您在 WPF 中运行程序，您可以将 directx 例程存储到您的密钥上，然后从密钥加载该例程并将效果应用到应用程序中的所有图像。然后破解者必须能够拦截该 directx 例程并正确应用它。
另一种可能性是使用密钥的随机数生成例程来开发 UID。一旦有人删除加密狗功能，所有生成的 UID 将被清零。
不过，最好的办法是将特定于域的功能放到加密狗上（例如整个 UID 生成例程）。不同的厂商在这方面会有不同的能力。
这些聪明才智会给你带来多大的障碍？实际上，这取决于您的程序的受欢迎程度。您的程序越受欢迎，人们就越有可能想要破解它，并投入时间来这样做。在这种情况下，如果您特别擅长加密狗编码，您可能会有几天的时间。如果您的程序不是那么受欢迎（例如只有几百个客户），那么只需加密狗的存在就足以起到威慑作用，而无需采取任何聪明的措施。
First of all, realize that the dongle will only provide a little bit of an obstacle. Someone who knows what they're doing will just remove the call to the dongle and put in a 'true' for whatever result that was called. Everyone will tell you this. But there are roadblocks you can add!
I would find a key portion of your code, something that's difficult or hard to know, something that requires domain knowledge. Then put that knowledge onto the key. One example of this would be shader routines. Shader routines are text files that are sent to a graphics card to achieve particular effects; a very simple brightness/contrast filter would take less than 500 characters to implement, and you can store that in the user space on most dongles. Then you put that information on the key, and only use information from the key in order to show images. That way, if someone tries to just simply remove your dongle, all the images in your program will be blacked out. It would take someone either having a copy of your program, grabbing the text file from the key, and then modifying your program to include that text file, and then knowing that that particular file will be the 'right' way to display images. Particulars of implementation depend on your deployment platform. If you're running a program in WPF, for instance, you might be able to store a directx routine onto your key, and then load that routine from the key and apply the effect to all the images in your app. The cracker then has to be able to intercept that directx routine and apply it properly.
Another possibility is to use the key's random number generation routines to develop UIDs. As soon as someone removes the dongle functionality, all generated UIDs will be zeroed.
The best thing to do, though, is to put a domain specific function onto the dongle (such as the entire UID generation routine). Different manufacturers will have different capabilities in this regard.
How much of a roadblock will these clevernesses get you? Realistically, it depends on the popularity of your program. The more popular your program, the more likely someone will want to crack it, and will devote their time to doing so. In that scenario, you might have a few days if you're particularly good at dongle coding. If your program is not that popular (only a few hundred customers, say), then just the presence of a dongle could be deterrent enough without having to do anything clever.
破解者将通过嗅探应用程序和加密狗之间的流量来破解，并禁用任何测试加密狗存在的代码或编写代码来模拟加密狗（例如，通过重放记录的流量），以看起来更容易的方式进行破解。
测试代码的混淆，以及以不同方式执行测试的许多分散的代码片段，以及在空间和时间上将测试的效果（禁用/降级功能、显示警告等）与测试本身分开，使得前者方法比较难。
在每次测试中，根据每次运行创建的随机数或什至可能在运行之间保存的随机数来改变加密狗的内容，这样天真地记录和重放流量就不起作用，这将使后一种方法变得更加困难。
然而，利用所描述的系统，模拟加密狗仍然很简单，所以迟早会有人这样做。
如果您有能力在加密狗内执行代码，则可以将执行对您的应用程序至关重要的功能的代码移动到那里，这意味着破解者必须重新导出代码或破坏加密狗的物理安全性 - 这是一个更昂贵的建议（尽管仍然可行；意识到不存在完美的安全性）。
Crackers will crack by sniffing the traffic between your app and the dongle and either disabling any code that tests for dongle presence or writing code to emulate the dongle (e.g. by replaying recorded traffic), whichever looks easier.
Obfuscation of the testing code, and many scattered pieces of code that perform tests in different ways, as well as separating spatially and temporally the effect of the test (disabling/degrading functionality, displaying a warning etc.) from the test itself make the former method harder.
Mutating the content of the dongle with each test based on some random nonce created each run or possibly even preserved between runs, so that naively recording and replaying the traffic does not work, will make the latter method harder.
However, with the system as described, it is still straightforward to emulate the dongle, so sooner or later someone will do it.
If you have the ability to execute code inside the dongle, you could move code that performs functions critical to your application there, which would mean that the crackers must either rederive the code or break the dongle's physical security - a much more expensive proposal (though still feasible; realise that there is no such thing as perfect security).
如何使用简单的加密狗最大限度地提供保护？
如果您生成的文件格式存在信封程序，请将 API 与信封程序一起使用。这是一个非常基本的规则。因为我们的信封器已经配备了一些反调试和混淆方法，以防止常见的新手黑客放弃对程序进行黑客攻击。也不建议仅使用信封器，因为一旦黑客可以破坏其他程序中的信封器保护，他们也可以破坏您的程序。
在应用程序的很多地方调用加密狗 API。例如，首次启动时、打开文件时、打开对话框时以及处理任何信息之前。即使什么也没做，也可能会进行一些随机检查。
使用多个函数来保护程序。不要仅仅使用查找功能来查找插入的加密狗。
使用多个 dll/库（如果适用）来调用加密狗功能。如果一个 dll 被黑客攻击，那么软件的其他部分仍然会使用另一个 dll 的功能。例如，将sdx.dll复制为print.dll、open.dll等名称，然后用不同的名称定义每个dll的函数调用。
如果您使用 dll 文件调用加密狗功能，请将其与可执行文件绑定在一起。有相当多的程序能够做到这一点；例如 PEBundle。 3
我在 PRLOG 上找到了这篇文章，发现它对于使用简单的加密狗实现最大程度的保护非常有用。也许此链接可能会帮助您
最大化保护为您的软件配备简单的加密狗
How to maximize protection with a simple dongle?
Use API together with Enveloper if an enveloper exists for your resulting file format. This is a very basic rule. Because our enveloper is already equipped with some anti-debugging and obfuscating methods to prevent common newbie hackers to give up hacking the program. Only using enveloper is also not recommended, because once a hacker can break the enveloper protection in other program, they can also break yours.
Call dongle APIs in a LOT of places in your application. For example when first start up, when opening a file, when a dialog box opens, and before processing any information. Also maybe do some random checking even when there's nothing done at all.
Use more than one function to protect a program. Do not just only use find function to look for a plugged dongle.
Use multiple dlls/libraries (if applicable) to call dongle functions. In case one dll is hacked, then there are still other parts of the software that uses the functions from another dll. For example, copying sdx.dll to print.dll, open.dll, and other names, then define the function calls from each dll with different names.
If you use a dll file to call dongle functions, bind it together with the executable. There are quite some programs capable of doing this; for example PEBundle. 3
I have got this article on PRLOG and found it quite useful on maximizing protection with a simple dongle. Maybe this link may help you
Maximizing Protection with a Simple Dongle for your Software
您可以在应用程序中实现许多检查点。
我不知道你是否使用HASP，但不幸的是，可以模拟加密狗。
You can implement many check points in your application.
I don't know if you use HASP, but unfortunatelly, dongles can be emulated.
您可能想考虑使用 Dinkey Dongles 进行复制保护。
这似乎是一个非常安全的系统，并且文档为您提供了使用该系统提高整体安全性的提示。
http://www.microcosm.co.uk/dongles.php
You may want to look into using Dinkey Dongles for your copy protection.
It seems a very secure system and the documentation gives you tips for improving your overall security using the system.
http://www.microcosm.co.uk/dongles.php
讽刺的是，您要阻止的不是用户的盗版，而是供应商的盗窃。互联网已经成为一个无法无天的地方，供应商可以随意窃取和转售您的软件。在某些情况下您拥有法律追索权，而在其他情况下则没有。
正如前面所说，没有什么是万无一失的。此外，您的安全性越复杂，就越有可能给合法用户带来麻烦或问题。
我想说最安全的应用程序始终是最靠近服务器的应用程序。可悲的是，用户担心它是间谍软件。
如果您对加密狗进行了很多不同的调用，那么破解者可能只会模拟您的加密狗 - 或者找到单点故障（更改一两个字节是很常见的，并且您的所有调用都是无用的）。这是一个双赢的局面。
作为 PECompact 的作者，我总是告诉客户，他们不能依赖任何东西来保护他们的软件——因为如果专门的破解者跟踪它，它就可以而且将会被破解。你做得越难，对他们来说挑战（乐趣）就越大。
了解这些事实后，我个人在我的软件上使用了非常少的保护技术。
Ironically, the thing you want to discourage is not piracy by users, but theft by vendors. The internet has become such a lawless place that vendors can steal and resell your software at will. You have legal recourse in some cases, and not in others.
Nothing is fool-proof, as previously stated. Also, the more complex your security is, the more likely it is to cause headaches or problems for legitimate users.
I'd say the most secure application is always the one tied closest to the server. Sadly, then users worry about it being spyware.
If you make a lot of different calls to your dongle, then maybe the cracker will just emulate your dongle -- or find a single point of failure (quite common to change one or two bytes and all your calls are useless). It is a no-win situation.
As the author of PECompact, I always tell customers that they can not rely on anything to protect their software -- as it can and will be cracked if a dedicated cracker goes after it. The harder you make it, the more of a challenge (fun) it is to them.
I personally use very minimal protection techniques on my software, knowing these facts.
使用智能卡+通过卡中存储的秘密功能加密/解密工作文件。那么软件可以被盗版，但它将无法打开正确加密的工作文件。
Use smartcard + encrypt/decrypt working files through secret function stored in card. Then software can be pirated, but it will not able to open properly encrypted working files.
我想说的是，如果有人想破解你的软件保护，他们就会这么做。当你说“足够努力”时，“足够”应该如何解释？
加密狗可能会阻止您的普通用户复制您的软件 - 因此从这个意义上说，它已经“足够”了。但任何觉得有必要并能够绕过加密狗的人都可能能够绕过您设计的任何其他方案。
I would say that if someone wants to crack your software protection, they will do so. When you say 'hard enough' - how should 'enough' be interpreted?
A dongle will perhaps prevent your average user from copying your software - so in that sense it is already 'enough'. But anyone who feels the need and is able to circumvent the dongle will likely be able to get past any other scheme that you engineer.