浅析手机抓包方法实践

0x00 摘要


在移动逆向分析以及 App 开发的时候,总会需要对其网络行为进行监控测试,本文总结一些抓包思路,并对其使用方法进行实践

笔者认为在抓包界,Wireshark 应该算是综合排名第一的工具(其实 Wireshark 自带的命令行工具 tshark 更牛逼)

本文总结记录了 5 种抓包方式,掌握其一即可进行实践,欢迎大家一起交流分享

0x01 基于 Wireshark


实验步骤:

1.1 在电脑主机上使用 猎豹 Wifi之类的工具,开启热点,将所要测试的手机连接该热点,记录其IP地址

1.2 使用 Wireshark 对以上 IP 地址进行捕获

Capture——Options

1.3 总结

该方法简单粗暴高效,可以将捕获的数据包随时保存下来,便于后续分析或者进行 PCAP 可视化分析。

关于命令行工具 tshark 在此不做赘述,感兴趣的读者自行研究。

0x02 基于 tcpdump


实验环境:

下载安装 Genymotion 安卓虚拟机,在该模拟器环境种进行实践操作(基于实体手机亦然,前提是 手机必须得 ROOT

笔者仅在 Android 系统下测试,未在 iOS 系统下实验

实验步骤:

2.1 说明

模拟器中自带的 tcpdump 工具,位于: /system/xbin/ 目录下

2.2 数据包捕获

可以通过 adb shell 命令在 CMD 模式下连接模拟器, su 到 root 模式进行抓包

tcpdump -vv -s 0 -i eth1 -w /sdcard/capture.pcap

参数说明:

  • -vv:获取详细的包信息(注意是两个 v 不是 w)
  • -s 0:不限数据包的长度,如果不加则只获取包头
  • -w xxx.pcap:捕获数据包名称以及存储位置(本例中保存在 sdcard 路径下,数据包名为 capture.pcap)
  • -i eth1:捕获制定的网卡(在 genymotion 虚拟机中,使用 busybox ifconfig 命令可以查看相关信息,一般 genymotion 的 ip 地址都为 10.xx.xx.x)
  • 如果你想指定捕获的数据包长度,可以使用 -c 参数(例如 -c 128)

捕获结束,直接按 Ctrl + C 即可

2.3 数据分析

将捕获到的数据包拖到本地使用 Wireshark 进行查看:

adb pull /sdcard/capture.pcap C:\tmp

TIPS:将数据包文件 push 到手机上命令为

adb push C:\tmp\capture.pcap /sdcard/

0x03 基于 Fiddler 4


实验步骤:

3.1 下载 FIddler 4

3.2 设置 Fiddler 4

打开Fiddler,Tools-> Fiddler Options (配置完成记得重启 Fiddler)

3.3 设置手机代理

首先,获取安装 Fiddler 4 的 PC 对应的 IP 地址(ipconfig):

确保手机和 PC 是连接在同一个局域网中!!!

下面对手机进行设置(笔者使用小米测试机):点击手机中“设置”——Wi-Fi——选择已经连接的wifi——代理设置改为手动

下载 Fiddler 的安全证书

使用手机浏览器访问: http://10.2.145.187:8888,点击”FiddlerRoot certificate”,然后安装证书即可。

至此,已经全部设置完毕。

3.4 数据包捕获

重新打开 Fiddler 4,然后打开手机中的浏览器,访问任意网址,Fiddler 抓包信息如下:

Enjoy!

0x04 基于 Charles


实验环境:

win7 + Charles v3.11

一般使用 Charles 都是基于 MAC OS ,笔者在 mac 平台以及 windows 平台均试验过,操作过程和思路基本一致,因此,本文以 win7 为测试环境

实验步骤:

4.1 捕获 http 数据包

手机设置代理:

打开 Charles 即可捕获数据包(Proxy —— Proxy Settings):

4.2 捕获 https 数据包

手机端安装证书:

Android 手机或者 iPhone 均可直接访问 http://www.charlesproxy.com/ssl.zip ,然后根据图示点击证书安装

设置 Charles:

选择 Proxy —— SSL Proxying Settings —— Locations —— Add

在弹出的表单中填写 Host 域名(也就是你想要抓包链接的主机名),以及对应的 Port 端口(此处相当于过滤作用)

当然,你可以采用更加粗暴的方式:使用通配符,例如你想要捕获所有的 https 包,这里也可以直接都为空,表示捕获所有的主机和端口;或者都分别填“*”星号,匹配所有的字符,捕获所有的 https。

0x05 基于 Burpsuite


实验步骤:

5.1 捕获 http 数据包

PC 端 Burpsuite 设置:

手机端代理设置方法同以上 3.3 4.1

打开 Burpsuite 即可捕获 http 数据包:

5.2 捕获 https 数据包

手机端设置好代理之后,使用浏览器访问: http://burp/

此处存在一个问题:下载的证书是 der 格式的,我们手机端安装的是 crt 格式的,需要使用 firefox 浏览器转一下格式:可以首先在 Brupsuite 中导出 der 格式证书,然后导入火狐浏览器,然后从火狐浏览器导出证书格式为 crt

打开火狐浏览器:工具——选项——高级——证书——查看证书

成功捕获 https 数据包

0x06 总结


  • 当我们停止捕获数据包时,将Fiddler 或 Charles 关闭,此时手机端是无法正常访问网络的,因为设置了代理,这时候需要将代理关闭,即可正常浏览网页
  • 对于大多数走代理的应用可以选择 Fiddler 或 Charles,无需 root,一次配置,终身使用;对于不走代理的 App 可以利用 tcpdump 捕包,然后使用 Wireshark 查看;最简单便捷的便是第一种方法 「0x01. 基于 Wireshark」
  • 以上所有工具各有优劣,读者可以根据工作环境,按需使用,个人觉得一般情况下使用 Wireshark + Fiddler 或者 Wireshark + Charles 即可完成各平台的抓包分析任务
  • 以上工具中只有BurpSuite可以对抓包过程进行交互式操作;Wireshark支持的协议最多,也更底层,功能强大,但过于沉重
  • 对于本文涉及的相关工具的安装、设置、破解、详细使用,不在本文讨论范围之内(Charles 免费版其实还比较厚道,如果重度需要,建议购买正版),本文旨在浅析捕获移动终端数据包的方法和思路

来源:http://drops.wooyun.org/tips/12467

作者:Ms4dam0n

iOS应用内支付的那些坑

我们在今年春节后上线了新的在线智能题库:猿题库。猿题库现在推出了公务员考试行测和申论2个产品,均包括web, iOS和Android三个平台。这次我们尝试做一个收费的产品,所以在iOS端集成了应用内支付(IAP)功能。在开发过程中和上线后,我们遇到了 IAP中的一些坑,在此分享给各位。

IAP 审核相关的坑

IAP开发的详细步骤我写在另一篇博客中了。在此主要介绍审核时遇到的问题。

IAP类型错误

由于我们是按月付费的产品,所以在设置IAP类型时,我没有经验,只是简单设置成了可重复消费(Consumable)的IAP项目。但是我不知 道,苹果对于这种按时间收费的产品,应该使用不可更新的定阅(Non-Renewing Subscription)类型。这个类型设置错误造成了我们app的一次审核被拒。

IAP验证逻辑

由于苹果在iOS5.0以下有IAP的bug,使得攻击者可以伪造支付成功的凭证。而iOS6.0的系统在越狱后同样可以伪造凭证,所以我们对于应用内支付,增加了服务器端的验证。服务器端会将支付凭证发给苹果的服务器进行二次验证,以保证凭证是真实有效的。

在我们公司的测试服务器中,我们会连接苹果的测试服务器()验证。

在我们部署在线上的正式服务器中,我们会连接苹果的正式服务器()验证。

我们提交给苹果审核的是正式版,我们以为苹果审核时,我们应该连接苹果的线上验证服务器来验证购买凭证。结果我理解错了,苹果在审核App时,只会 在sandbox环境购买,其产生的购买凭证,也只能连接苹果的测试验证服务器。但是审核的app又是连接的我们的线上服务器。所以我们这边的服务器无法 验证通过IAP购买,造成我们app的又一次审核被拒。

解决方法是判断苹果正式验证服务器的返回code,如果是21007,则再一次连接测试服务器进行验证即可。苹果的这一篇文档上有对返回的code的详细说明。

in-app_purchase

IAP上线后的遇到的情况

我们在服务器端增加了验证IAP是否有效的逻辑。在产品上线后,如我们所料,我们收到了大量的欺骗性购买,这些都被我们的服务器识别出来了,但是我们也遇到了以下这次没有想到的情况:

1、由于国内越狱用户的比例比较大(大概为50%),所以虽然我们服务器会验证购买凭证,但是每天有超过50%以上的凭证都是伪造的。同时由于苹果 的验证服务器在美国,凭证验证请求响应的时间比较慢,大量的伪造凭证发给苹果服务器,不知道会不会被苹果认为我们是在恶意进行DDOS。至少我们发现有些 时候,验证请求会超时。

2、由于国内有许多小白用户,他们的手机从购买时就被渠道商帮忙越狱过了并且安装了IAP free插件。所以对于这类用户,他们即使想付费购买,由于系统原有的IAP支付功能已经被破坏,所以他们是无法正常付费的。麻烦的是,他们会以为这是我 们的app的问题,转而给我们的客服打电话投诉。这让我们非常郁闷。

3、苹果的验证服务器有时候会出问题,我们发现本来约定好返回的JSON数据在有几次返回的居然是一个XML格式的文件。造成我们将正常的付费 IAP凭证验证失败。所以,在服务器记录下所有的验证凭证非常有必要,一来可以防止黑客多次提交同一个成功凭证的重放攻击,二来在需要时可以手工进行再验 证。

越狱手机可能被黑客窃取购买凭证!

我们发现有一部分用户反馈说已经收到苹果的扣费账单,但是我们从服务器的验证记录看,他上传的凭证却是虚假的。由于这些用户不太多,我们一开始以为 是用户在恶意欺骗我们,后来我们让他将苹果的付费账单邮件转发给我们,以及将itunes的购买记录截图转发给我们,我们越来越怀疑这里面有一个黑色的产 业链。越狱手机的正常购买凭证可能被黑客的恶意程序截获,具体的攻击方式我们讨论了一下,其实就是被中间人攻击,详细的过程如下:

1.越狱手机的在被破解后,可能从一些破解渠道安装了黑客的恶意程序。

2.黑客将越狱手机所有https请求都经过他的中间服务器。

3.当有支付请求时,黑客先将请求发给苹果服务器,待苹果将成功的凭证返回后,黑客将这个凭证替换成假的凭证,完全支付凭证的偷取。

或许有人会问,这个凭证拿来有什么用呢?很简单 ,因为苹果为了保护用户的隐私,支付凭证中并不包含任何用户的apple id信息,所以我们的app和服务器无法知道这个凭证是谁买的,而只能知道这个凭证是真的还是假的。于是黑客就可以用这个凭证,在另外的账号中通知我们完 成了购买,而发来的验证凭证又是真实的,所以我们的服务器就会误认为是黑客的账号完成了购买,继而把会员期算在黑客的账号上。

再举一个简单的例子,你拿500块钱买了顺风优选的500元购物券,由于这个购物券是不记名的,所以顺风优选无法知道是谁买的。如果这个购物券在发 放过程中被人掉包,那么偷购物券的人就可以拿这个偷来的真购物券来购物,而顺风优选的卡因为是不记名的,所以也无法查证这件事情。在这个例子中,购物券的 不记名和苹果的支付凭证无账号信息是同一个道理。

鉴于以上情况,考虑到越狱手机不但不能成功支付,还会有安全问题,所以我们在新版中取消了越狱手机中的IAP支付功能。

所以,请大家还是不要越狱自己的手机,iphone手机越狱后风险相当大。实在不值得为了免费玩几个游戏就丢掉安全性。

【编者按】本文转自猿题库、粉笔网开发工程师唐巧的博客。

AppStore苹果应用支付开发(In App Purchase)翻译

http://yarin.blog.51cto.com/1130898/549141

一、In App Purchase概览

Store Kit代表App和App Store之间进行通信。程序将从App Store接收那些你想要提供的产品的信息,并将它们显示出来供用户购买。
当用户需要购买某件产品时,程序调用StoreKit来收集购买信息。下图即为基本的store kit 模型:

Store Kit的API只是为程序添加In App Purchase功能的一小部分。你需要决定如何去记录那些你想要提交的产品,如何在程序中将商店功能展现给用户,
还要考虑如何将用户购买的产品提交。本章的剩余部分会展示整个流程。

Products
产品可以是任意一项你想要出售的特性。产品在iTunes Connect中被组织,这和你添加一个新的App是一样的。支持的产品种类共有四种:
1. 内容型。包括电子书,电子杂志,照片,插图,游戏关卡,游戏角色,和其他的数字内容。
2. 扩展功能。这些功能已经包含在App内部。在未购买之前被锁定。例如,你可以在一个游戏程序中包含若干个小游戏,用户可以分别来购买这些游戏。
3. 服务。允许程序对单次服务收费。比如录音服务。
4. 订阅。支持对内容或服务的扩展访问。例如,你的程序可以每周提供财务信息或游戏门户网站的信息。应该设定一个合理的更新周期,以避免过于频繁的
提示困扰用户。要记住:你将负责跟踪订阅的过期信息,并且管理续费。App Store不会替你监视订阅的周期,也不提供自动收费的机制。

In App Purchase为创建产品提供了一种通用的机制,如何操作将由你负责。当你设计程序的时候,有以下几点需要注意:

1. 你必须提供电子类产品和服务。不要使用In App Purchase 去出售实物和实际服务。
2. 不能提供代表中介货币的物品,因为让用户知晓他们购买的商品和服务是很重要的。

2. 服务器类型
使用这终方式,要提供另外的服务器将产品发送给程序。 服务器交付适用于订阅、内容类商品和服务,因为商品可以作为数据发送,而不需改动程序束。 例如,一个游戏提供的新的内容(关卡等)。 Store Kit不会对服务器端的设计和交互做出定义,这方面工作需要你来完成。 而且,Store Kit不提供验证用户身份的机制,你需要来设计。 如果你的程序需要以上功能,例如,纪录特定用户的订阅计划, 你需要自己来设计和实现。

图1-3 展示了服务器类型的购买过程。

1. 程序向服务器发送请求,获得一份产品列表。
2. 服务器返回包含产品标识符的列表。
3. 程序向App Store发送请求,得到产品的信息。
4. App Store返回产品信息。
5. 程序把返回的产品信息显示给用户(App的store界面)
6. 用户选择某个产品
7. 程序向App Store发送支付请求
8. App Store处理支付请求并返回交易完成信息。
9. 程序从信息中获得数据,并发送至服务器。
10. 服务器纪录数据,并进行审(我们的)查。
11. 服务器将数据发给App Store来验证该交易的有效性。
12. App Store对收到的数据进行解析,返回该数据和说明其是否有效的标识。
13. 服务器读取返回的数据,确定用户购买的内容。
14. 服务器将购买的内容传递给程序。

Apple建议在服务器端存储产品标识,而不要将其存储在plist中。 这样就可以在不升级程序的前提下添加新的产品。

在服务器模式下, 你的程序将获得交易(transaction)相关的信息,并将它发送给服务器。服务器可以验证收到的数据,并将其解码以确定需要交付的内容。 这个流程将在“验证store收据”一节讨论。

对于服务器模式,我们有安全性和可靠性方面的顾虑。 你应该测试整个环境来避免威胁。《Secure Coding Guide》文档中有相关的提示说明。

虽然非消耗性商品可以用内置模式来恢复,订阅类商品必须通过服务器来恢复。你要负责纪录订阅信息、恢复数据。
消耗类商品也可以通过服务器方式来纪录。例如,由服务器提供的一项服务, 你可能需要用户在多个设备上重新获得结果。
(这段翻译的比较生硬,因为我个人也没有机会把各种类型的服务跑一遍,后续会检查并修改。希望大家一起来看看,欢迎补充。)
取得产品信息

要在程序内部显示“商店”,需要从App Store得到信息来购建界面。 本章详细讲解如何从App Store获取产品信息。

向App Store发送请求

Store Kit提供了从App Store上请求数据的通用机制。 程序可以创建并初始化一个request对象, 为其附加delegate, 然后启动请求过程。请求将被发送到App Store,在那里被处理。 处理完成时, request对象的delegate方法将被异步调用,以获得请求的结果。 图2-1显示了请求的数据模型。

如果程序在请求期间退出,则需要重新发送请求。

下面讲解请求过程中用到的类:

SKRequest
SKRequest为request的抽象根类。

SKRequestDelegate
SKRequestDelegate是一个protocol, 实现用以处理请求结果的方法,比如请求成功,或请求失败。

发送获得产品信息的请求
程序使用products request来获得产品的信息。 要完成这一过程,程序需创建一个request对象,其中会包含一个产品标识的列表。之前提到过,你的程序既可以内置产品列表,又可以通过外部服务器来获得。

当发送请求时,产品标识会传送到App Store,App Store将会返回本地化信息(这些信息事先已经在iTunes Connect中设置好了),你将使用这些信息来购建内置商店的界面(显示商品名,描述,等等)。 图2-2显示了请求的过程。

SKProductsRequest
用来请求商品的信息。 创建时,我们将需要显示的商品列表加入该对象。

SKProductsRequestDelegate
该protocol定义了处理App Store响应的方法。

SKProductsResponse
SKProductsResponse对象为App Store返回的响应信息。里面包含两个列表(当然是NSArray了):一是经过验证有效的商品,
@property(nonatomic, readonly) NSArray *products
另外一个是无法被识别的商品信息:
@property(nonatomic, readonly) NSArray * invalidProductIdentifiers
有几种原因将造成商品标识无法被识别,如拼写错误(当然),被标记为不可出售(unavailable for sale),或是对商品信息的改变没有传送到所有App Store的服务器。(这个原因不是很清楚,再议)。

SKProduct
SKProduct对象包含了在App Store上注册的商品的本地化信息。
购买商品
当用户准备购买商品时,程序向App Store请求支付信息,然后App Store将会创建持久化的交易信息,并继续处理支付流程,即使用户重启程序,这个过程亦是如此。App Store同步待定交易的列表到程序中,并在交易状态发生改变时向程序发送更新的数据。

收集支付信息

要收集支付信息, 你的程序可以创建一个payment的对象,将它放到支付队列中,如图3-1所示。

1. 一个SKPayment的对象,包含了”Sword”的商品标识,并且制定购买数量为1。
2. 使用addPayment:方法将SKPayment的对象添加到SKPaymentQueue里。
3. SKPaymentmentQueue包含的所有请求商品,
4. 使用SKPaymentTransactionObserver的paymentQueue: updatedTransactions: 方法来检测所有完成的购买,并发送购买的商品。
5. 最后,使用finishTransaction:方法完成交易。

当payment的对象被添加到支付队列中的时候, 会创建一个持久保存的transaction对象来存放它。 当支付被处理后,transaction被更新。 程序中将实现一个观察者(observer)对象来获取transaction更新的消息。 观察者应该为用户提供购买的商品,然后将transaction从队列中移除。

下面介绍在购买过程中用到的几个类:
SKPayment
要收集支付信息,先要了解一下支付对象。 支付对象包含了商品的标识(identifier)和要购买商品的数量(quantity)(数量可选)。你可以把同一个支付对象重复放入支付队列,,每一次这样的动作都相当于一次独立的支付请求。

用户可以在Settings程序中禁用购买的功能。 因此在请求支付之前,程序应该首先检查支付是否可以被处理。 调用SKPaymentQueue的canMakePayments方法来检查。

SKPaymentQueue
支付队列用以和App Store之间进行通信。 当新的支付对象被添加到队列中的时候, Store Kit向App Store发送请求。 Store Kit将会弹出对话框询问用户是否确定购买。 完成的交易将会返回给程序的observer对象。

SKPaymentTransaction
transaction对象在每次添加新的payment到队列中的时候被创建。 transaction对象包含了一些属性,可以让程序确定当前的交易状态。

程序可以从支付队列那里得到一份审核中的交易列表,但更常用的做法还是等待支付队列告知交易状态的更新。

SKPaymentTransactionObserver
在程序中实现SKPaymentTransactionObserver的协议,然后把它作为SKPaymentQueue对象的观察者。该观察者的主要职责是:检查完成的交易,交付购买的内容,和把完成后的交易对象从队列中移除。

在程序一启动,就应该为支付队列指定对应的观察者对象,而不是等到用户想要购买商品的时候。 Transaction对象在程序退出时不会丢失。程序重启时, Store Kit继续执行未完成的交易。 在程序初始化的时候添加观察者对象,可以保证所有的交易都被程序接收(也就时说,如果有未完成的transaction,如果程序重启,就重新开始了,如果稍候再添加观察者,就可能会漏掉部分交易的信息)。
恢复交易信息(Transactions)
当transaction被处理并从队列移除之后,正常情况下,程序就再也看不到它们了。 如果你的程序提供的是非消耗性的或是订阅类的商品,就必须提供restore的功能,使用户可以在其他设备上重新存储购买信息。

Store Kit提供内建的功能来重新存储非消耗商品的交易信息。 调用SKPaymentQueue的restoreCompletedTransactions的方法来重新存储。对于那些之前已经完成交易的非消耗性商品,Apple Store生成新的,用于恢复的交易信息。 它包含了原始的交易信息。你的程序可以拿到这个信息,然后继续为购买的功能解锁。 当之前所有的交易都被恢复时, 就会调用观察者对象的paymentQueueRestoreCompletedTransactionsFinished方法。

如果用户试图购买已经买过的非消耗性商品,程序会收到一个常规的交易信息,而不是恢复的交易信息。但是用户不会被再次收费。程序 应把这类交易和原始的交易同等对待。

订阅类服务和消耗类商品不会被Store Kit自动恢复。 要恢复这些商品,你必须在用户购买这些商品时,在你自己的服务器上记录这些交易信息, 并且为用户的设备提供恢复交易信息的机制。
在程序中添加Store功能
本章为添加购买功能的指导

详细流程:

准备工作当然是添加StoreKit.framework了。
然后是具体的步骤:

1. 决定在程序内出售的商品的类型。
之前提到过,程序内可以出售的新feature类型是有限制的。 Store Kit不允许我们下载新的代码。 你的商品要么可以通过当前的代码工作(bundle类型),要么可以通过服务器下载(当然,这里下载的为数据文件,代码是不可以的)。 如果要修改源代码,就只能老实的升级了。

2. 通过iTunes Connect注册商品
每次添加新商品的时候都需要执行这一步骤。 每个商品都需要一个唯一的商品标识。 App Store通过这个标识来查找商品信息并处理支付流程。 注册商品标识的方法和注册程序的方法类似。

要了解如何创建和注册商品信息,请参考“iTunes Connect Developer Guide”文档。

3. 检测是否可以进行支付
用户可以禁用在程序内部支付的功能。在发送支付请求之前,程序应该检查该功能是否被开启。程序可在显示商店界面之前就检查该设置(没启用就不显示商店界面了),也可以在用户发送支付请求前再检查,这样用户就可以看到可购买的商品列表了。

例子:

  1. if([SKPaymentQueue canMakePayments])
  2. {
  3.     …//Display a store to the user
  4. }
  5. else
  6. {
  7.     …//Warn the user that purchases are disabled.
  8. }

4. 获得商品的信息
程序创建SKProductsRequest对象,用想要出售的商品的标识来初始化, 然后附加上对应的委托对象。 该请求的响应包含了可用商品的本地化信息。

  1. //这里发送请求
  2. – (void)requestProductData
  3. {
  4.     SKProductsRequest *request = [[SKProductsRequest alloc]initWithProductIdentifiers:
  5.     [NSSet setWithObject: kMyFeatureIdentifier]];
  6.     request.delegate = self;
  7.     [request start];
  8. }
  9. //这个是响应的delegate方法
  10. – (void)productsRequest: (SKProductsRequest *)request
  11. didReceiveResponse: (SKProductsResponse *)response
  12. {
  13.     NSArray *myProduct = response.products;
  14.     //生成商店的UI
  15.     [request autorelease];
  16. }

 

5. 添加一个展示商品的界面
Store Kit不提供界面的类。 这个界面需要我们自己来设计并实现。

6. 为支付队列(payment queue)注册一个观察者对象
你的程序需要初始化一个transaction observer对象并把它指定为payment queue的观察者。

上代码:

  1. MyStoreObserver *observer = [[MyStoreObserver alloc]init];
  2. [[SKPaymentQueue defaultQueue]addTransactionObserver: observer];

应该在程序启动的时候就添加好观察者,原因前面说过,重启后程序会继续上次未完的交易,这时就添加观察者对象就不会漏掉之前的交易信息。

7. 在MyStoreObserver类中执行paymentQueue: updatedTransactions: 方法。
这个方法会在有新的交易被创建,或者交易被更新的时候被调用。

  1. – (void)paymentQueue: (SKPaymentQueue *)queue updatedTransactions: (NSArray *)transactions
  2. {
  3.     for(SKPaymentTransaction * transaction in transactions)
  4.     {
  5.         switch(transaction.transactionState)
  6.         {
  7.             case SKPaymentTransactionStatePurchased:
  8.                 [self completeTransaction: transaction];
  9.                 break;
  10.             case SKPaymentTransactionStateFailed:
  11.                 [self failedTransaction: transaction];
  12.                 break;
  13.             case SKPaymentTransactionStateRestored:
  14.                 [self restoreTransaction: transaction];
  15.             default:
  16.                 break;
  17.         }
  18.     }
  19. }

 

上面的函数针对不同的交易返回状态,调用对应的处理函数。

8. 观察者对象在用户成功购买一件商品时,提供相应的内容,以下是在交易成功后调用的方法

  1. – (void) completeTransaction: (SKPaymentTransaction *)transaction
  2. {
  3.     //你的程序需要实现这两个方法
  4.     [self recordTransaction: transaction];
  5.     [self provideContent: transaction.payment.productIdentifier];
  6.     //将完成后的交易信息移出队列
  7.     [[SKPaymentQueue defaultQueue]finishTransaction: transaction];
  8. }

交易成功的信息包含transactionIdentifier和transactionReceipt的属性。其中,transactionReceipt记录了支付的详细信息,这个信息可以帮助你跟踪、审(我们的)查交易,如果你的程序是用服务器来交付内容,transactionReceipt可以被传送到服务器,然后通过App Store验证交易。(之前提到的server模式,可以参考以前的图)

9. 如果交易是恢复过来的(restore),我们用这个方法来处理:

  1. – (void) restoreTransaction: (SKPaymentTransaction *)transaction
  2. {
  3.     [self recordTransaction: transaction];
  4.     [self provideContent: transaction.payment.productIdentifier];
  5.     [[SKPaymentQueue defaultQueue] finishTransaction: transaction];
  6. }

这个过程完成购买的过程类似。 恢复的购买内容提供一个新的交易信息,这个信息包含了新的transaction的标识和receipt数据。 如果需要的话,你可以把这些信息单独保存下来,供追溯审(我们的)查之用。但更多的情况下,在交易完成时,你可能需要覆盖原始的transaction数据,并使用其中的商品标识。

10. 交易过程失败的话,我们调用如下的方法:

  1. – (void)failedTransaction: (SKPaymentTransaction *)transaction
  2. {
  3.     if(transaction.error.code != SKErrorPaymentCancelled)
  4.     {
  5.         //在这类显示除用户取消之外的错误信息
  6.     }
  7.     [[SKPaymentQueue defaultQueue] finishTransaction: transaction];
  8. }

 

通常情况下,交易失败的原因是取消购买商品的流程。 程序可以从error中读出交易失败的详细信息。

显示错误信息不是必须的,但在上面的处理方法中,需要将失败的交易从支付队列中移除。 一般来说,我们用一个对话框来显示错误信息,这时就应避免将用户取消购买这个error显示出来。

11. 组织好程序内“商店”的UI。当用户选择一件商品时, 创建一个支付对象,并放到队列中。

  1. SKPayment *payment = [SKPayment paymentWithProductIdentifier: kMyFeatureIdentifier];
  2. [[SKPaymentQueue defaultQueue] addPayment: payment];

如果你的商店支持选择同一件商品的数量,你可以设置支付对象的quantity属性

  1. SKMutablePayment *payment = [SKMutablePayment paymentWithProductIdentifier: kMyFeatureIdentifier];
  2. payment.quantity = 3;
  3. [[SKPaymentQueue defaultQueue] addPayment: payment];

下一步:
本章中所示代码可用于内置型商品模式(Built-in)。 如果你的程序要使用服务器来发布商品,你需要负责设计和执行iPhone程序和你的服务器之间的通信。服务器应该验证数据并为程序提供内容。

验证store的收据

使用服务器来交付内容,我们还需要做些额外的工作来验证从Store Kit发送的收据信息。

重要信息:来自Store的收据信息的格式是专用的。 你的程序不应直接解析这类数据。可使用如下的机制来取出其中的信息。

验证App Store返回的收据信息
当交易完成时,Store Kit告知payment observer这个消息,并返回完成的transaction。 SKPaymentTransaction的transactionReceipt属性就包含了一个经过签名的收据信息,其中记录了交易的关键信息。你的服务器要负责提交收据信息来确定其有效性,并保证它未经过篡改。 这个过程中,信息被以JSON数据格式发送给App Store,App Store也以JSON的格式返回数据。
(大家可以先了解一下JSON的格式)

验证收据的过程:

1. 从transaction的transactionReceipt属性中得到收据的数据,并以base64方式编码。
2. 创建JSON对象,字典格式,单键值对,键名为”receipt-data”, 值为上一步编码后的数据。效果为:

  1. {
  2.     “receipt-data”    : “(编码后的数据)”
  3. }

3. 发送HTTP POST的请求,将数据发送到App Store,其地址为:
https://buy.itunes.apple.com/verfyReceipt

4. App Store的返回值也是一个JSON格式的对象,包含两个键值对, status和receipt:

  1. {
  2.     “status”    : 0,
  3.     “receipt”    : { … }
  4. }

如果status的值为0, 就说明该receipt为有效的。 否则就是无效的。

App Store的收据
发送给App Store的收据数据是通过对transaction中对应的信息编码而创建的。 当App Store验证收据时, 将从其中解码出数据,并以”receipt”的键返回。 返回的响应信息是JSON格式,被包含在SKPaymentTransaction的对象中(transactionReceipt属性)。Server可通过这些值来了解交易的详细信息。 Apple建议只发送receipt数据到服务器并使用receipt数据验证和获得交易详情。 因为App Store可验证收据信息,返回信息,保证信息不被篡改,这种方式比同时提交receipt和transaction的数据要安全。(这段得再看看)

表5-1为交易信息的所有键,很多的键都对应SKPaymentTransaction的属性。
备注:一些键取决于你的程序是链接到App Store还是测试用的Sandbox环境。更多关于sandbox的信息,请查看”Testing a Store”一章。

Table 5-1 购买信息的键:

键名 描述
quantity 购买商品的数量。对应SKPayment对象中的quantity属性
product_id 商品的标识,对应SKPayment对象的productIdentifier属性。
transaction_id 交易的标识,对应SKPaymentTransaction的transactionIdentifier属性
purchase_date 交易的日期,对应SKPaymentTransaction的transactionDate属性
original_-transaction_id 对于恢复的transaction对象,该键对应了原始的transaction标识
original_purchase_-date 对于恢复的transaction对象,该键对应了原始的交易日期
app_item_id App Store用来标识程序的字符串。一个服务器可能需要支持多个server的支付功能,可以用这个标识来区分程序。链接sandbox用来测试的程序的不到这个值,因此该键不存在。
version_external_-identifier 用来标识程序修订数。该键在sandbox环境下不存在
bid iPhone程序的bundle标识
bvrs iPhone程序的版本号

 

 

 

 

 

 

 

 

 

 

 

测试Store功能
开发过程中,我们需要测试支付功能以保证其工作正常。然而,我们不希望在测试时对用户收费。 Apple提供了sandbox的环境供我们测试。

备注:Store Kit在模拟器上无法运行。 当在模拟器上运行Store Kit的时候,访问payment queue的动作会打出一条警告的log。测试store功能必须在真机上进行。

Sandbox环境
使用Sandbox环境的话,Store Kit并没有链接到真实的App Store,而是链接到专门的Sandbox环境。 SandBox的内容和App Store一致,只是它不执行真实的支付动作。 它会返回交易成功的信息。 Sandbox使用专门的iTunes Connect测试 账户。不能使用正式的iTunes Connect账户来测试。

要测试程序,需要创建一个专门的测试账户。你至少需要为程序的每个区域创建至少一个测试账户。详细信息,请查看iTunes Connect Developer Guide文档。

在Sandbox环境中测试
步骤:
1. 在测试的iPhone上退出iTunes账户
Settings中可能会记录之前登录的账户,进入并退出。

重要信息:不能在Settings 程序中通过测试账户登录。

2. 运行程序
当你在程序的store中购买商品后,Store kit提示你去验证交易。用测试账户登录,并批准支付。 这样虚拟的交易就完成了。

后台php代码示例:

  1. <?php
  2.     //服务器二次验证代码
  3.     function getReceiptData($receipt$isSandbox = false)
  4.     {
  5.         if ($isSandbox) {
  6.             $endpoint = ‘https://sandbox.itunes.apple.com/verifyReceipt’;
  7.         }
  8.         else {
  9.             $endpoint = ‘https://buy.itunes.apple.com/verifyReceipt’;
  10.         }
  11.         $postData = json_encode(
  12.             array(‘receipt-data’ => $receipt)
  13.         );
  14.         $ch = curl_init($endpoint);
  15.         curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
  16.         curl_setopt($ch, CURLOPT_POST, true);
  17.         curl_setopt($ch, CURLOPT_POSTFIELDS, $postData);
  18.        curl_setopt ($ch, CURLOPT_SSL_VERIFYPEER, 0);  //这两行一定要加,不加会报SSL 错误
  19.         curl_setopt ($ch, CURLOPT_SSL_VERIFYHOST, 0);
  20.         $response = curl_exec($ch);
  21.         $errno    = curl_errno($ch);
  22.         $errmsg   = curl_error($ch);
  23.         curl_close($ch);
  24.     //判断时候出错,抛出异常
  25.         if ($errno != 0) {
  26.             throw new Exception($errmsg$errno);
  27.         }
  28.         $data = json_decode($response);
  29.     //判断返回的数据是否是对象
  30.         if (!is_object($data)) {
  31.             throw new Exception(‘Invalid response data’);
  32.         }
  33.     //判断购买时候成功
  34.         if (!isset($data->status) || $data->status != 0) {
  35.             throw new Exception(‘Invalid receipt’);
  36.         }
  37.     //返回产品的信息           
  38.         return array(
  39.             ‘quantity’       =>  $data->receipt->quantity,
  40.             ‘product_id’     =>  $data->receipt->product_id,
  41.             ‘transaction_id’ =>  $data->receipt->transaction_id,
  42.             ‘purchase_date’  =>  $data->receipt->purchase_date,
  43.             ‘app_item_id’    =>  $data->receipt->app_item_id,
  44.             ‘bid’            =>  $data->receipt->bid,
  45.             ‘bvrs’           =>  $data->receipt->bvrs
  46.         );
  47.     }
  48.     //获取 App 发送过来的数据,设置时候是沙盒状态
  49.         $receipt   = $_GET[‘data’];
  50.         $isSandbox = true;
  51.     //开始执行验证
  52.     try
  53.      {
  54.          $info = getReceiptData($receipt$isSandbox);
  55.          // 通过product_id 来判断是下载哪个资源
  56.          switch($info[‘product_id’]){
  57.             case ‘com.application.xxxxx.xxxx’:
  58.                 Header(“Location:xxxx.zip”);
  59.             break;
  60.         }
  61.      }
  62.     //捕获异常
  63.     catch(Exception $e)
  64.     {
  65.         echo ‘Message: ‘ .$e->getMessage();
  66.     }
  67. ?>

注:支付订单中并没有玩家相关标识,如果CP方服务器需要将购买道具从后台发送到玩家账户,则可以通过Get或Post的方式传递其他字段信息到服务器。

如:

  1. $receipt   = $_GET[‘data’]; //苹果支付信息
  2. $userid   = $_GET[‘userid’]; //玩家标识
  3. $other   = $_GET[‘other’]; //其他透传信息

另外,订单协议中只有玩家购买的道具信息,没有此次该玩家消费的金额,需要CP方服务器于后台自行兑账。

在Sandbox中验证收据
验证的URL不同了:

  1. NSURL *sandboxStoreURL = [[NSURL alloc]initWithString:
  2. @“https://sandbox.itunes.apple.com/verifyReceipt”];