In these sort of circumstances, I don't really think it matters what you do. If you have some kind of protection it will stop 90% of your users. The other 10% - if they don't want to pay for your software they'll pretty much find a way around protection no matter what you do.
If you want something a little less obvious you can put a file in System32 that sounds like a system file that the application checks the existence of on launch. That can be a little harder to track down.
just be cool about the license. explain up front that this is your passion and a child of your labor. give people a chance to do the right thing. if someone wants to pirate it, it will happen eventually. i still remember my despair seeing my books on bittorrent, but its something you have to just deal with. Don't cave to casual piracy (what you're doing now sounds great) but don't cripple the thing beyond that. I still believe that there are enough honest people out there to make a for-profit coding endeavor worth while.
Don't have the evaluation based on "days since install", instead do number of days used, or number of times run or something similar. People tend to download shareware, run it once or twice, and then forget it for a few weeks until they need it again. By then, the trial may have expired and so they've only had a few tries to get hooked on using your app, even though they've had it installed for a while. Number of activation/days instead lets them get into a habit of using your app for a task, and also makes a stronger sell (i.e. you've used this app 30 times...).
Even better, limiting the features works better than timing out. For example, perhaps your photography app could limit the user to 1 megapixel images, but let them use it for as long as they want.
Also, consider pricing your app at $20 (or $19.95). Unless there's already a micropayment setup in place (like iPhone store or XBoxLive or something) people tend to have an aversion to buying things online below a certain price point (which is around $20 depending on the type of app), and people assume subconciously if something is inexpensive, it must not be very good. You can actually raise your conversion rate with a higher price (up to a point of course).
I am facing the very same problem with an application I'm selling for a very low price as well.
Besides obfuscating the app, I came up with a system that uses two keys in the registry, one of which is used to determine that time of installation, the other one the actual license key. The keys are named obscurely and a missing key indicates tampering with the installation.
Of course deleting both keys and reinstalling the application will start the evaluation time again.
I figured it doesn't matter anyway, as someone who wants to crack the app will succeed in doing so, or find a crack by someone who succeeded in doing so.
So in the end I'm only achieving the goal of making it not TOO easy to crack the application, and this is what, I guess, will stop 80-90% of the customers from doing so. And afterall: as the application is sold for a very low price, there's no justification for me to invest any more time into this issue than I already have.
EDIT: You can make your current licensing scheme considerable more difficult to crack by storing the registry information in the Local Security Authority (LSA). Most users will not be able to remove your key information from there. A search for LSA on MSDN should give you the information you need.
Opinions on licensing schemes vary with each individual, more among developers than specific user groups (such as photographers). You should take a deep breath and try to see what your target user would accept, given the business need your application will solve.
This is my personal opinion on the subject. There will be vocal individuals that disagree.
The answer to this depends greatly on how you expect your application to be used. If you expect the application to be used several times every day, you will benefit the most from a very long trial period (several month), to create a lock-in situation. For this to work you will have to have a grace period where the software alerts the user that payment will be needed soon. Before the grace period you will have greater success if the software is silent about the trial period.
Wether or not you choose to believe in this quite bold statement is of course entirely up to you. But if you do, you should realize that the less often your application will be used, the shorter the trial period should be. It is also very important that payment is very quick and easy for the user (as little data entry and as few clicks as possible).
If you are very uncertain about the usage of the application, you should choose a very short trial period. You will, in my experience, achieve better results if the application is silent about the fact that it is in trial period in this case.
Though effective for licensing purposes, "Call home" features is regarded as a privacy threat by many people. Personally I disagree with the notion that this is any way bad for a customer that is willing to pay for the software he/she is using. Therefore I suggest implementing a licensing scheme where the application checks the license status (trial, paid) on a regular basis, and helps the user pay for the software when it's time. This might be overkill for a small utility application, though.
For very small, or even simple, utility applications, I argue that upfront payment without trial period is the most effective.
Regarding the security of the solution, you have to make it proportional to the development effort. In my line of work, security is very critical because there are partners and dealers involved, and because the investment made in development is very high. For a small utility application, it makes more sense to price it right and rely on the honest users that will pay for the software that address their business needs.
There's not much point to doing complicated protection schemes. Basically one of two things will happen:
Your app is not popular enough, and nobody cracks it.
Your app becomes popular, someone cracks it and releases it, then anybody with zero knowledge can simply download that crack if they want to cheat you.
In the case of #1, it's not worth putting a lot of effort into the scheme, because you might make one or two extra people buy your app. In the case of #2, it's not worth putting a lot of effort because someone will crack it anyway, and the effort will be wasted.
Basically my suggestion is just do something simple, like you already are, and that's just as effective. People who don't want to cheat / steal from you will pay up, people who want to cheat you will do it regardless.
If you are hosting your homepage on a server that you control, you could have the downloadable trial-version of your software automatically compile to a new binary every night. This compile will replace a hardcoded datetime-value in your program for when the software expires. That way the only way to "cheat" is to change the date on your computer, and most people wont do that because of the problems that will create.
通过这种方式，您可以在服务器端存储唯一 ID，并拒绝多次生成到期日期。 不确定使用什么作为唯一 ID，但应该有某种方法可以从 Windows 获取有用的东西。
One way to do it that's easy for the user but not for you is to hard-code the expiry date and make new versions of the installer every now and then... :)
If I were you though, I wouldn't make it any more advanced than what you're already doing. Like you say it's only $10, and if someone really wants to crack your system they will do it no matter how complicated you make it.
You could do a slightly more advanced version of your scheme by requiring a net connection and letting a server generate the trial key. If you do something along the lines of sign(hash(unique_computer_id+when_to_expire)) and let the app check with a public key that your server has signed the expiry date it should require a "real" hack to bypass.
This way you can store the unique id's serverside and refuse to generate a expiry date more than once or twice. Not sure what to use as the unique id, but there should be some way to get something useful from Windows.
发布评论
评论（10）
在这种情况下，我认为你做什么并不重要。 如果你有某种保护措施，它会阻止 90% 的用户。 另外 10% - 如果他们不想为您的软件付费，无论您做什么，他们几乎都会找到绕过保护的方法。
如果你想要一些不那么明显的东西，你可以在 System32 中放置一个听起来像系统文件的文件，应用程序在启动时检查它是否存在。 追踪起来可能有点困难。
In these sort of circumstances, I don't really think it matters what you do. If you have some kind of protection it will stop 90% of your users. The other 10% - if they don't want to pay for your software they'll pretty much find a way around protection no matter what you do.
If you want something a little less obvious you can put a file in System32 that sounds like a system file that the application checks the existence of on launch. That can be a little harder to track down.
只要对许可证保持冷静即可。 预先解释一下，这是你的激情所在，也是你的劳动成果。 让人们有机会做正确的事。 如果有人想盗版，那最终就会发生。 我仍然记得在 BitTorrent 上看到我的书时的绝望，但这是你必须面对的事情。 不要屈服于随意的盗版（你现在所做的听起来很棒），但也不要削弱除此之外的东西。
我仍然相信有足够多的诚实的人让以营利为目的的编码努力值得。
just be cool about the license. explain up front that this is your passion and a child of your labor. give people a chance to do the right thing. if someone wants to pirate it, it will happen eventually. i still remember my despair seeing my books on bittorrent, but its something you have to just deal with. Don't cave to casual piracy (what you're doing now sounds great) but don't cripple the thing beyond that.
I still believe that there are enough honest people out there to make a for-profit coding endeavor worth while.
不要根据“安装后的天数”进行评估，而是根据使用的天数或运行的次数或类似的内容进行评估。 人们倾向于下载共享软件，运行一两次，然后几周后就忘记它，直到再次需要它。 到那时，试用版可能已经过期，因此他们只尝试了几次就迷上了您的应用程序，即使他们已经安装了一段时间。 相反，激活次数/天数可以让他们养成使用您的应用程序执行任务的习惯，并且还可以进行更强劲的销售（即您已使用此应用程序 30 次...）。
更好的是，限制功能比超时效果更好。 例如，也许您的摄影应用程序可以将用户限制为 1 兆像素的图像，但让他们想用多久就用多久。
另外，请考虑将应用定价为 20 美元（或 19.95 美元）。 除非已经有小额支付设置（例如 iPhone 商店或 XBoxLive 等），否则人们往往会厌恶在低于某个价格点（大约 20 美元，具体取决于应用程序类型）的网上购买商品，并且人们会下意识地假设：东西便宜，一定不是很好。 实际上，您可以通过更高的价格来提高转化率（当然在一定程度上）。
Don't have the evaluation based on "days since install", instead do number of days used, or number of times run or something similar. People tend to download shareware, run it once or twice, and then forget it for a few weeks until they need it again. By then, the trial may have expired and so they've only had a few tries to get hooked on using your app, even though they've had it installed for a while. Number of activation/days instead lets them get into a habit of using your app for a task, and also makes a stronger sell (i.e. you've used this app 30 times...).
Even better, limiting the features works better than timing out. For example, perhaps your photography app could limit the user to 1 megapixel images, but let them use it for as long as they want.
Also, consider pricing your app at $20 (or $19.95). Unless there's already a micropayment setup in place (like iPhone store or XBoxLive or something) people tend to have an aversion to buying things online below a certain price point (which is around $20 depending on the type of app), and people assume subconciously if something is inexpensive, it must not be very good. You can actually raise your conversion rate with a higher price (up to a point of course).
我也以非常低的价格出售的应用程序面临着同样的问题。
除了混淆应用程序之外，我还设计了一个使用注册表中两个密钥的系统，其中一个用于确定安装时间，另一个用于实际的许可证密钥。 这些密钥的命名模糊，丢失密钥表明安装被篡改。
当然，删除两个密钥并重新安装应用程序将再次开始评估时间。
我认为无论如何这并不重要，因为想要破解该应用程序的人会成功地做到这一点，或者成功地做到这一点的人会找到破解方案。
所以最终我只是实现了让破解应用程序变得不那么容易的目标，我猜这将阻止 80-90% 的客户这样做。 毕竟：由于该应用程序的售价非常低，我没有理由在这个问题上投入更多的时间。
I am facing the very same problem with an application I'm selling for a very low price as well.
Besides obfuscating the app, I came up with a system that uses two keys in the registry, one of which is used to determine that time of installation, the other one the actual license key. The keys are named obscurely and a missing key indicates tampering with the installation.
Of course deleting both keys and reinstalling the application will start the evaluation time again.
I figured it doesn't matter anyway, as someone who wants to crack the app will succeed in doing so, or find a crack by someone who succeeded in doing so.
So in the end I'm only achieving the goal of making it not TOO easy to crack the application, and this is what, I guess, will stop 80-90% of the customers from doing so. And afterall: as the application is sold for a very low price, there's no justification for me to invest any more time into this issue than I already have.
编辑：您可以通过将注册表信息存储在本地安全机构 (LSA) 中，使当前的许可方案更加难以破解。 大多数用户将无法从那里删除您的关键信息。 在 MSDN 上搜索 LSA 应该会为您提供所需的信息。
对许可方案的看法因人而异，更多的是开发人员的看法，而不是特定用户群体（例如摄影师）的看法。 鉴于您的应用程序将解决的业务需求，您应该深呼吸并尝试看看您的目标用户会接受什么。
这是我对这个问题的个人看法。 会有一些直言不讳的人表示不同意见。
这个问题的答案很大程度上取决于您期望如何使用应用程序。 如果您希望每天使用该应用程序多次，那么您将从很长的试用期（几个月）中获益，以创建锁定情况。 为此，您必须有一个宽限期，在此期间软件会提醒用户很快需要付款。 在宽限期之前，如果软件对试用期保持沉默，您将获得更大的成功。
您是否选择相信这个相当大胆的声明当然完全取决于您。 但如果您这样做，您应该意识到您的应用程序使用的频率越低，试用期应该越短。 同样非常重要的是，付款对于用户来说非常快速和容易（尽可能少的数据输入和尽可能少的点击）。
如果您对应用程序的使用非常不确定，您应该选择非常短的试用期。 根据我的经验，如果应用程序对在这种情况下处于试用期的事实保持沉默，您将获得更好的结果。
尽管“Call home”功能对于许可目的有效，但许多人认为这是对隐私的威胁。 就我个人而言，我不同意这样的观点，即这对于愿意为他/她正在使用的软件付费的客户来说是不利的。 因此，我建议实施一种许可方案，其中应用程序定期检查许可证状态（试用、付费），并在适当的时候帮助用户支付软件费用。 不过，这对于小型实用程序应用程序来说可能有点过分了。
对于非常小的，甚至简单的实用程序应用程序，我认为没有试用期的预付款是最有效的。
关于解决方案的安全性，您必须使其与开发工作量成正比。 在我的工作中，安全性非常重要，因为涉及到合作伙伴和经销商，而且开发投资非常高。 对于小型实用程序应用程序来说，合理定价并依赖诚实的用户为满足其业务需求的软件付费更有意义。
EDIT: You can make your current licensing scheme considerable more difficult to crack by storing the registry information in the Local Security Authority (LSA). Most users will not be able to remove your key information from there. A search for LSA on MSDN should give you the information you need.
Opinions on licensing schemes vary with each individual, more among developers than specific user groups (such as photographers). You should take a deep breath and try to see what your target user would accept, given the business need your application will solve.
This is my personal opinion on the subject. There will be vocal individuals that disagree.
The answer to this depends greatly on how you expect your application to be used. If you expect the application to be used several times every day, you will benefit the most from a very long trial period (several month), to create a lock-in situation. For this to work you will have to have a grace period where the software alerts the user that payment will be needed soon. Before the grace period you will have greater success if the software is silent about the trial period.
Wether or not you choose to believe in this quite bold statement is of course entirely up to you. But if you do, you should realize that the less often your application will be used, the shorter the trial period should be. It is also very important that payment is very quick and easy for the user (as little data entry and as few clicks as possible).
If you are very uncertain about the usage of the application, you should choose a very short trial period. You will, in my experience, achieve better results if the application is silent about the fact that it is in trial period in this case.
Though effective for licensing purposes, "Call home" features is regarded as a privacy threat by many people. Personally I disagree with the notion that this is any way bad for a customer that is willing to pay for the software he/she is using. Therefore I suggest implementing a licensing scheme where the application checks the license status (trial, paid) on a regular basis, and helps the user pay for the software when it's time. This might be overkill for a small utility application, though.
For very small, or even simple, utility applications, I argue that upfront payment without trial period is the most effective.
Regarding the security of the solution, you have to make it proportional to the development effort. In my line of work, security is very critical because there are partners and dealers involved, and because the investment made in development is very high. For a small utility application, it makes more sense to price it right and rely on the honest users that will pay for the software that address their business needs.
制定复杂的保护方案没有多大意义。 基本上会发生以下两种情况之一：
您的应用程序不够流行，没有人破解它。
你的应用程序变得流行，有人破解它并发布它，那么任何零知识的人如果想欺骗你，都可以简单地下载该破解程序。
你的应用程序变得流行
在#1 的情况下，不值得在该方案上投入大量精力，因为您可能会让一两个额外的人购买您的应用程序。 在#2的情况下，不值得付出很多努力，因为无论如何都会有人破解它，而努力就会被浪费。
基本上我的建议是做一些简单的事情，就像你已经做的那样，而且同样有效。 不想欺骗/偷窃你的人会付出代价，想要欺骗你的人无论如何都会这么做。
There's not much point to doing complicated protection schemes. Basically one of two things will happen:
Your app is not popular enough, and nobody cracks it.
Your app becomes popular, someone cracks it and releases it, then anybody with zero knowledge can simply download that crack if they want to cheat you.
In the case of #1, it's not worth putting a lot of effort into the scheme, because you might make one or two extra people buy your app. In the case of #2, it's not worth putting a lot of effort because someone will crack it anyway, and the effort will be wasted.
Basically my suggestion is just do something simple, like you already are, and that's just as effective. People who don't want to cheat / steal from you will pay up, people who want to cheat you will do it regardless.
如果您将主页托管在您控制的服务器上，则可以让可下载的软件试用版每晚自动编译为新的二进制文件。 当软件过期时，此编译将替换程序中的硬编码日期时间值。 这样，“作弊”的唯一方法就是更改计算机上的日期，而大多数人不会这样做，因为会产生问题。
If you are hosting your homepage on a server that you control, you could have the downloadable trial-version of your software automatically compile to a new binary every night. This compile will replace a hardcoded datetime-value in your program for when the software expires. That way the only way to "cheat" is to change the date on your computer, and most people wont do that because of the problems that will create.
尝试共享软件入门工具包。 它是我的 Microsoft 开发的，可能还有一些您想要的其他功能。
http://msdn.microsoft.com/en-us/vs2005/aa718342。 ASPX
Try the Shareware Starter Kit. It was developed my Microsoft and may have some other features you want.
http://msdn.microsoft.com/en-us/vs2005/aa718342.aspx
如果您打算继续开发软件，您可以考虑赎金模型：
http://en.wikipedia .org/wiki/Street_Performer_Protocol
本质上，您对软件进行改进，然后在发布它们之前请求一定数量的捐赠（没有任何 DRM）。
If you are planning to continue developing your software, you might consider the ransom model:
http://en.wikipedia.org/wiki/Street_Performer_Protocol
Essentially, you develop improvements to the software, and then ask for a certain amount of donations before you release them (without any DRM).
一种对用户来说很容易但对你来说不那么容易的方法是硬编码到期日期并时不时地制作新版本的安装程序......:)
如果我是你，我就不会这么做比你已经在做的更先进的。 就像你说的，只要 10 美元，如果有人真的想破解你的系统，无论你把它搞得多么复杂，他们都会这么做。
您可以通过需要网络连接并让服务器生成试用密钥来实现您的方案的稍微高级版本。 如果您按照 sign(hash(unique_computer_id+when_to_expire)) 进行操作，并让应用程序使用公钥检查您的服务器是否已签署到期日期，则应该需要“真正的”黑客才能绕过。
通过这种方式，您可以在服务器端存储唯一 ID，并拒绝多次生成到期日期。 不确定使用什么作为唯一 ID，但应该有某种方法可以从 Windows 获取有用的东西。
One way to do it that's easy for the user but not for you is to hard-code the expiry date and make new versions of the installer every now and then... :)
If I were you though, I wouldn't make it any more advanced than what you're already doing. Like you say it's only $10, and if someone really wants to crack your system they will do it no matter how complicated you make it.
You could do a slightly more advanced version of your scheme by requiring a net connection and letting a server generate the trial key. If you do something along the lines of sign(hash(unique_computer_id+when_to_expire)) and let the app check with a public key that your server has signed the expiry date it should require a "real" hack to bypass.
This way you can store the unique id's serverside and refuse to generate a expiry date more than once or twice. Not sure what to use as the unique id, but there should be some way to get something useful from Windows.