Mac App Store收据validation码?

想知道是否有人有新的Mac App Store的收据validation教程或工作代码? 关于迄今为止唯一可以find的引用是苹果公司关于这个主题的恒星文档和一个编译但是没有大量内联注释的开源项目,所以除非你是一个encryption专家,否则很难理解。

苹果文档仅适用于注册开发者:

https://developer.apple.com/devcenter/mac/documents/validating.html

Roddi的ValidateStoreReceipt(看起来很有希望,但是稀疏地logging):

https://github.com/roddi/ValidateStoreReceipt

也想知道为什么苹果不只是提供工作代码进行validation?

还有其他的好的参考吗?

很难为Mac App Store收据validation提供一个通用的解决scheme,主要是因为这是一个非常敏感的代码,难以绕过(参见Apple文档 )。

这些GitHub项目是了解接收validation中必须执行哪些步骤的非常好的起点:

  • NPReceiptVerification
  • ValidateStoreReceipt
  • AppReceiptParser

一旦你了解了必须做的事情,这里有一些build议:

  • 不要使用Objective-C类或方法。 Objective-C带有大量的元数据,而且它的dynamic特性将它暴露给运行时注入。
  • 只使用C函数调用。 即使你在CoreFoundation框架中需要更多的代码行,你也可以完成基础框架所能做的事情(NSString,NSArray,NSDictionary,…)。
  • 不要dynamic链接到OpenSSL库,因为它在Mac OS X Lion中已被弃用。 如果您想要使用OpenSSL ,请静态链接以确保拥有最新版本。
  • 使用系统函数进行密码学。 Mac OS X从10.5开始提供相同的function。 例如,要计算SHA-1散列,可以使用CC_SHA1函数。
  • 不要在您的代码中以明文forms放置string。 对它们进行编码或encryption。 如果你没有这样做,你会提示你的代码的位置。
  • 不要在你的代码中使用数字常量。 通过一些简单的操作(+, – ,/或*)在运行时计算它们。 再一次,如果你不这样做,你就暗示你的代码的位置。
  • 通过embeddedtesting和将NSApplicationMain调用到复杂循环中,避免简单的validationtesting。
  • 避免直接调用NSApplicationMain。 使用函数指针来隐藏调用。 如果你没有这样做,你会提示你的代码的位置。
  • 对于您的应用程序的每个版本,稍微修改validation代码,以便它永远不会相同。

请记住,收据validation是必要的,并不像看起来那么简单。 它可能会花费你很多的时间,你可能会更好地花在你的应用程序上。

所以我build议你看看这个应用程序: Receigen (免责声明:我是这个应用程序的开发者)。

为了在testing之后validation真实收据,请在main.m文件中更改以下代码行:

if (!validateReceiptAtPath(@"~/Desktop/receipt")) 

 #ifdef USE_SAMPLE_RECEIPT // defined for debug version NSString *pathToReceipt = @"~/Desktop/receipt"; #else NSString *pathToReceipt = [[[NSBundle mainBundle] bundlePath] stringByAppendingPathComponent:@"Contents/_MASReceipt/receipt"]; #endif if (!validateReceiptAtPath(pathToReceipt)) exit(173); //receipt did not validate 

在您的编译器设置中,您的debuggingconfiguration的“其他C标志”应该包含-DUSE_SAMPLE_RECEIPT

礼貌http://jesusagora.org/groups/futurebasic/0::53562:get:1read.html

请务必检查您是否正在validation您的应用的收据。 易于做错误的收据签名的所有encryption和validation。

看到http://pastebin.com/1eWf9LCg看起来像愤怒的小鸟错过了这一点,并留下他们开放给人们从一个免费的应用程序代替收据。;

Alan Quatermain也有代码在github上做这个。 https://github.com/AlanQuatermain/mac-app-store-validation-sample

不应该按原样使用,以避免自动删除。

我回顾了Alan Quartermain的代码,看起来不错。 有一些想法:

这里的最后一个参数可能/应该是一个编译的要求,说明代码必须由你的证书签署,而不是其他人。

当开发者将应用程序提交给商店进行批准时,签名证书如下:

 3rd Party Mac Developer Application: me Apple Worldwide Developer Relations Certification Authority Apple Root CA 

应用程序从App Store交付给最终用户后,签名证书如下所示:

 Apple Mac OS Application Signing Apple Worldwide Developer Relations Certification Authority Apple Root CA 

另外,我build议只在收据丢失时退出(173),但是其他一切都是按顺序的。

你可以尝试NPReceiptVerification 。 这是将收据validation添加到您的应用程序的最简单的方法。 您只需将类文件添加到您的项目中,设置版本和包标识符,并自动处理其他所有内容。

我build议将代码validation例程作为C函数来实现,而不是ObjC方法。

这种技术使得(有点)更难find收据检查代码,因为更less的方法名被编译到二进制文件中。

你可以参考RVNReceiptValidation它很容易实现。 只需要在RVNReceiptValidation.m文件和应用程序的版本中设置Bundle id RVNReceiptValidation.m 。 记得要从苹果获得收据,你必须从Finder启动应用程序。 此类还有助于实施InApp购买。

我会详细说明priller的答案。 如果Apple为validation过程提供了一个代码示例,那么对于坏人来说,使用已编译的应用程序并扫描相应validation过程的代码将非常容易。 如果您使用Apple的标准代码示例,那么坏人将确切地知道编译的代码是什么样的。 一旦坏人发现代码的一部分,修改应用程序的编译代码,只是跳过收据validation阶段是非常微不足道的,渲染整个事情是无用的。

所有这一切,一个坚定的黑客可能会绕过任何保护你的地方,无论你做什么。 游戏行业(例如)花费了大量时间来保护他们的软件,破解版本似乎总是可用的。

从Apple Docs创build样本收据时,请确保在“结束”之后不要包含任何额外的字符,否则uudecode将失败。

是的,在他们的文档中说:“重要的是你要使用一种独特的解决scheme。”

roddi的ValidateStoreReceipt之前为我工作,但它不再工作。 我写了关于解决scheme的博客文章: http : //vinceyuan.blogspot.com/2012/07/validate-mac-app-store-receipt-2012.html

复制在这里:roddi的代码仍在工作。 你不需要改变它。 (只需要获得最新版本)按照以下步骤(需要互联网):

  1. 从Mac App Store应用程序注销。
  2. 从项目设置中删除USE_SAMPLE_RECEIPT标志 – >预处理器macros。
  3. 编译你的项目
  4. 在Finder中find这个应用程序
  5. 在Finder中双击它运行。 不要在Xcode中运行它。
  6. 操作系统会要求您使用您的Apple IDlogin。 不要使用真实的iTunes帐户login。 您需要使用testing帐户login。 find它或在iTunesconnect网站上创build它。
  7. 操作系统会说“你的应用程序坏了,在App Store下载”。 忽略此消息。 如果您在Finder中显示此应用程序的“显示包装内容”,您将看到有一个文件_MASReceipt /收据。 操作系统安装了开发收据。 我们不再需要旧的样品收据。 这就是为什么我们删除USE_SAMPLE_RECEIPTdebugging标志。

完成。 你现在可以debugging你的应用程序。

即使使用NPReceiptValidation,您仍然应该validation包括签名证书在内的应用程序包的安全性。 这在WWDR对开发者的build议中有记载。

解决scheme: http : //itunes.apple.com/us/app/apptight-pro-app-store-code/id427083596?mt=12

NPReceiptValidation的一个潜在的问题是Cocoa对象上的方法select器很容易被劫持。 这是扩展应用程序最stream行的方式。

这是另一个协助进行应用内购买分析的工具:

http://itunes.apple.com/us/app/pkcs-7viewer/id547539804?mt=12