【问题标题】:Strategies for battling iOS in-app purchase piracy?与 iOS 应用内购买盗版作斗争的策略?
【发布时间】:2013-05-16 15:24:04
【问题描述】:

我的应用使用应用内购买,我与 Apple 验证交易收据。这向我表明,许多用户正试图通过提交虚假交易收据来盗版应用内购买机制,这些收据提供的产品 ID 为com.zeptolab.ctrbonus.superpower1(来自“割绳子”)。当然,我不会让他们使用带有假收据的应用内购买项目。与 iOS 盗版作斗争并试图让这些人付出或受苦的策略是什么?

【问题讨论】:

  • 受苦了,哈哈。你可能最好不要因为它而失眠。
  • 我被引导到这篇文章是因为我注意到出现了具有相同 SKU 的虚假购买收据。

标签: iphone ios in-app-purchase piracy-prevention piracy


【解决方案1】:

真正防止这种情况的唯一方法是通过您自己的服务器控制一切。即使是臭名昭著的“com.zeptolab.ctrbonus.superpower1”收据也是苹果自己的验证端点会告诉你的实际有效收据。交易完成后,应用程序应将交易数据发送到您控制的服务器,并且:

  1. Validate the receipt with Apple 来自您自己的服务器。
  2. 如果 Apple 表示没问题,请从 Apple 的响应中解析 product_id 字段,并确保它是您应用中的产品 ID。
  3. 如果前两项通过,则返回数据以告知您的应用在哪里下载您的内容(如果是托管内容)。

即使这样也有缺陷,尤其是当您的 IAP 内容只是在设备上但“锁定”时。有一些方法可以从您的服务器重定向验证调用,以使您的应用认为您的服务器说“一切正常!”。如果您的 IAP 内容是远程托管的,这将更加困难,因为如果他们首先不知道内容的位置,就不能轻易地用内容的位置来欺骗响应。

对于大多数人来说,所有这一切的问题在于,控制自己的服务器和远程内容会变得很昂贵,更不用说需要编写自己的验证逻辑了。你越难让这些黑客成功,你付出的代价就越大,所以你必须权衡你愿意花多少时间、精力和金钱来让他们“受苦” vs 你赚了多少和/或损失了多少。请记住,一次“盗版”IAP 不一定等于一次销售损失,因此很难衡量您可能因此而损失多少。

【讨论】:

  • 如果来自我的服务器的响应是加密签名的,那么他们就不能重定向,因为签名不会验证(不拆卸和修改应用程序,但这可以很容易地禁用购买检查本身)。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2021-01-17
  • 1970-01-01
  • 2011-09-17
  • 2015-03-13
  • 1970-01-01
相关资源
最近更新 更多