如何制作一个仅在有限时间内有效的Cocoa演示应用程序？

Question

如何制作一个仅在有限时间内有效的Cocoa演示应用程序？

macoscocoa

6

我使用了很多Cocoa演示应用，它们在3天或一个月左右后就停止工作。它们是如何实现的？最好的方法是什么？此外，有哪些限制？

- jasongregori

1

可能是实现30天试用期的重复问题，但我肯定希望Peter Hosey的答案能够保存下来。 - Rob Keniger

@RobKeniger 它会存活下去。只要它知道如何去爱...嗯，只要它没有低评分，就不会被删除。 - JasonMArcher

3个回答

5

通常，他们会在应用程序的用户默认设置中保存使用天数/小时数/其他某些内容的计数。由于更改应用程序的用户默认设置相当容易，因此有些人会向文件中写入一个简单的哈希值，该哈希值必须与使用天数的数字匹配。如果不匹配，则立即使构建过期，因为用户显然刚刚修改了该设置。其他人则保留多个使用天数计数器的副本。如果缺少其中之一，他们将根据其他位置中最低的数字进行恢复。

良好的位置是用户不会预期的隐藏文件，可能被命名为与其他应用程序或系统文件类似的名称。但是要小心，不要在整个文件系统上散布文件，这样会使其他应用程序看起来很糟糕。还值得考虑的是将资源写入文件的资源 fork 中，在这些天大多数人都不再查看（其中包括您的文件！另一个应用程序或系统可能会替换其文件并删除您的信息，或者可能使用相同的资源类型并导致冲突）。

很有可能，普通黑客会尝试编辑用户默认设置，然后放弃。专业黑客无论保护方案花费多少努力，都会继续前进，因此不值得花太多时间保护它。

一些应用程序开发者会生成一个带有过期日期的许可证密钥，并使应用程序在没有有效许可证密钥的情况下拒绝运行。Allan Odgaard撰写了一篇很好的文章，介绍如何使用OpenSSL（确保您这些天使用LibreSSL或CommonCrypto.framework，它们非常相似）对信息进行签名，以便将到期日期传递给用户，而用户无法编辑它：http://sigpipe.macromates.com/2004/09/05/using-openssl-for-license-keys/

- uliwitness

非常有趣。谢谢！ - jasongregori

0

根据您的想法，我使用椭圆曲线加密在Java中创建了一个简短的概念验证，用于生成UUID，并在启动时使用ECC对该UUID进行签名以创建注册密钥。如果有人需要，可以在此处找到代码1。

- David George

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Peter Hosey · Accepted Answer

（免责声明：我以前从未制作过试用版，只是研究过这个主题并使用了一堆。）

所有限制都源于用户的系统上的任何东西都可以被修改。所以：

- 精明的守财奴可能会修改您的应用程序可执行文件，以去除或否认您进行的任何检查。 - 您必须在某个地方存储使用的时间（或者更懒惰但不太用户友好的是他们开始使用您的应用程序的日期）。无论您将其存储在哪里，用户都必须能够更改它（因为您的应用程序以他们的身份运行），这意味着如果他们找到它，他们可以重置时钟。 - 如果您在沙箱中运行，则不可能实现，除非您将上述跟踪时间数据存储在用户默认设置或Keychain中，其中任何一个都可以视为公开可见，或请求临时例外豁免以便在文件系统上写入。有时限的试用版无论如何都不能在App Store中，但如果App Store或沙箱成为Mac OS X的将来版本所需的，您的时间限制将会破裂，我们只能希望它不会阻止用户完全使用您的应用程序。 - 还有处理付款的问题。一种方法是在App Store中出售应用程序，不带任何试用版执行代码，并自己分发一个始终执行时间限制的构建。如果您自己处理付款，则需要在用户系统上存储用户许可证的记录，并检查该许可证。然后，这也变得容易受到相同问题：用户可能会伪造许可证或“借用”（例如从Warez网站下载）其他人的许可证。

当然，好处是用户有一定的时间免费尝试应用程序，而不必付出任何代价，因此到达期限时（如果您的应用程序很好并满足了他们的需求），他们更有可能购买。

在试用期结束时，可以选择以下操作：

- 完全锁定用户无法使用应用程序。 - 去除功能。 Acorn就是这样做的。 - 让他们打开文档，但不能保存或打印。（您可以阻止屏幕截图，但祝您好运处理错误报告。） - 让他们保存或（如果适用）打印，但以某种方式降低全部或部分文档的质量。对于视觉创作，例如图像，可以使用水印。对于音频，您可以将采样率限制为不愉快的20 kHz或更低。（在这里有一个案例，即拥有自己的专有格式，您始终以无损方式处理，仅将导出降级到诸如TIFF、JFIF或AIFF之类的常见格式。） Fission就是这样做的。 - 只是不停地提醒他们。（可以与上述任何一种结合使用。） - 提醒他们并延迟用户解除它的能力。您甚至可以根据用户未付款的时间长短增加延迟。

一个好的替代试用期的方法是提供一个独立的“免费”版本，具有较少的功能或带有广告。这在两个应用商店上特别常见。

另一个需要考虑的因素是试用期是“使用天数”还是“自首次使用以来的天数”。后者更容易实现，因为你只需要记录第一次使用的日期并进行减法计算即可。前者更加用户友好，因为它不会惩罚用户仅仅是因为他们在31天后启动应用程序一次，花了五分钟玩了一下然后回来进行真正的试用。

你也可以限制启动次数。与从第一次使用以来的天数实现起来一样简单，但不会惩罚仅仅试用一次的用户。

有些用户就是不愿意付费。有些用户会几乎不遗余力地阻止付费。

因此，你需要把握平衡。你需要提供一个基本的难度水平，使得最懒最小气的人不能简单地通过defaults write com.example.yourapp DaysSinceFirstUse -int 0来永远使用你的应用程序，同时也不要让你的应用程序过于麻烦（更不用说付费）以至于用户不使用。

那么以下是一些不要做的事情：

试图强制要求用户在购买时输入许可证上的用户名与他们帐户或通讯录中的姓名相同。任何人的名字都有十几种不同的写法，并且有些人有多个名字（通过婚姻、别名、法定名称更改、多种语言、星际迷航等等），所以这样的检查或任何类似的检查都是无效的，只会让更多合法的用户受到困扰而不能遏制盗版。
扣押用户的数据。请参考我先前关于专有格式的价值的说明，你需要始终无损地处理输出。如果你确实在试用期间始终降低输出，请在应用程序的启动对话框中明确提示“这是试用版本”。
要求互联网连接。并非每个人都有可以连接到任意服务器的互联网，也并非每个人都随时拥有互联网连接。从游戏业界中学习：不要疏远你的用户。
安装任何运行在后台和/或与你的应用程序分开的版权执行软件。用户会因此恨你。

至于如何做到，以下是我推荐的方法：

实现“实际使用天数”检查。这可以成为一个卖点。当试用版明确表示使用此类检查时，我感到很温暖。
我建议将其存储为小时数。在启动时，从任何存储位置获取当前小时数。添加两个小时并将其写回（以防止用户强制退出应用程序来规避此项检查）。退出时，将自启动以来实际使用小时数添加到最初读取的数字中，并将修订后的数字写回。
将其存储在Application Support中的不可见文件中。对其进行加密（同样，您希望防止轻松盗版），但不要浪费太多时间来让它无懈可击。请记住，您的应用程序必须包含所有内容，既能加密（以跟踪）又能解密（以执行检查），因此坚定不移（且受过教育）的小气鬼无论如何都可以破解它。
在启动时，从任何存储位置获取当前小时数并测试是否超出限制。（如果您采用了我的立即添加两个小时的建议，请在测试限制之后执行此操作。）30天是30×24=720小时。如果超过限制，执行试用已过期的措施。
如果您自己销售软件，请使用对称公钥加密进行许可证文件。我认为AquaticPrime就是这么做的。你用你的私钥加密许可证，并在应用程序中分发公钥，应用程序使用公钥解密并检查许可证。实际上不可破解。您通过电子邮件将许可证文件发送给客户，使用他们在购买时提供的电子邮件地址。（告诉他们他们将通过电子邮件收到许可证，以便他们不输入虚构的地址。）
- 如果这样做，请确保在试用期结束之前和之后测试输入许可证。
- 仅在没有许可证时进行试用检查。
如果您可以在App Store中销售您的应用程序，我建议您仅这样做。如果您还想自己分发试用版，请不要放置任何许可代码，因此试用检查将无条件进行。当然，App Store版本不需要（也不能有）试用检查。
观看此视频。（注意：它早于苹果的App Store。）