小路的博客

iPhone 北京一卡通充值流程研究

一、研究背景

  • 苹果手机NFC概述：苹果公司也是NFC标准的推动者之一，苹果手机从iPhone 6开始搭载NFC芯片，用于Apple Pay的功能，但是对于iPhone手机上的NFC功能，经过调查与实践，有以下几个基本事实：

    • 对于所有iPhone，iOS系统不对第三方开发者提供有关写卡的API。
    • 对于运行iOS 11或更高版本的iPhone 7系列以及更新机型，苹果提供了一个名为Core NFC的框架，可以读取类型1-5的NFC标签，对于运行iOS 11以下的设备以及iPhone 6、iPhone 6s系列和iPhone SE，CoreNFC不可用。[1]
    • 对于所有运行iOS 11.3以及更高版本，支持NFC的iPhone，都可以使用公交卡功能，目前只支持北京和上海。
    • 对于iPhone 7系列以及更高版本的机型，在公交卡功能中可以在开新卡时，转移已有公交卡的余额，这个过程涉及到写卡，该功能对于iPhone 6、iPhone 6s系列和iPhone SE不可用。[2]
    • 对于越狱的设备，插件NFCWriter可以实现iPhone的 NFC标签读写和卡模拟，支持iOS 9和iOS 10。[3]

  • 因为手头没有iPhone 7以上的设备，同时也是主要研究手机和服务器的通讯，所以就把目光转向了充值流程，主要测试北京一卡通的虚拟卡充值过程。

  • 想要分析充值过程中的云侧数据，就必须要对iOS设备接收和发出的流量进行分析，才能进一步进行。对于PC机而言，分析流量主要有以下两种途径：

  • 第一种途径是通过Wireshark、tcpdump等软件进行流量抓取，此类软件是通过WinPcap，或者是NPcap/Nmap系列组件，进行流量的抓取与分析，这类流量分析软件可以分析的数据包种类很多，从TCP/IP体系结构模型的第二层以上，都可以进行抓取和分析。但是局限性是无法作为中间人进行拦截包操作，如果没有相应的证书私钥，是无法分析SSL的数据包的。

  • 第二种途径是通过burpsuite、charles等软件进行流量抓取，此类软件本质上来讲属于中间人，需要在目标设备上设置网络代理，诱导设备将全部流量发送至代理服务器，再通过运行在代理服务器上的此类软件进行抓包分析。这样一来，能分析的数据包就只有HTTP和HTTPS协议的数据包了。当然了，对于一般的和服务器交互，使用的协议也是以HTTP和HTTPS为主。在分析HTTPS数据包时，因为本身SSL具备抵抗中间人攻击的功能，所以我们还需要将抓包软件的根证书添加到操作系统或者浏览器的根证书信任存储区中。或者我们也可以使用HOOK框架，直接钩取验证服务器端SSL证书的方法。

二、网络数据包的获得

  • 在我们这次课题的场景中，要想实现抓包，有两种解决方案：第一是使用charles软件进行中间人抓包分析，同时将其根证书导入到iOS系统中，从而实现HTTPS流量的分析。第二是使用越狱后的iOS设备，在设备上安装OpenSSH和tcpdump进行抓包。因为手头没有已经越狱的iOS设备，所以我们选择了第一种方法，具体操作可以参考我的其他文档。但是在实施过程中发现，在iOS 11和iOS 12系统中，部分系统App是可以忽略用户的根证书信任设置的，也就是说，即使我们设置了信任charles的根证书，也无法实现对于系统App的抓包。经过实践，无法抓包的App/功能有以下几个（可能不全面）：
    • 系统设置 Apple ID 管理页面
    • 系统设置 iCloud 管理页
    • 系统设置 Apple 系统更新
    • App Store
    • Apple Pay 应用内付款
    • 系统设置 Apple 系统反馈
  • 可以看出，基本都是比较敏感的App，所以我们无法实现抓取Apple Pay应用内付款的数据包，当然也包括使用Apple Pay为北京一卡通充值的数据包。实际上Apple Pay交易应用到了苹果A系列处理器中的Secure Engine（安全隔区），还是比较安全的[4]。所以在本次实训中我们也没有尝试去分析此部分。
  • 但是在实际操作中发现，在钱包App中为北京一卡通充值，主要有两个阶段，首先是进行标准的Apple Pay支付流程，这个流程是无法进行抓包的，第二个阶段是进入“正在更新卡片，更新完毕后即可使用Apple Pay”的阶段，这个阶段我们推测是在和发卡方进行数据传输，也就是我们真正需要关注的部分。所以我们决定首先使用无中间人的网络完成Apple Pay交易，在交易完成后立即切换到有中间人的网络，完成更新卡片的操作，实现对钱包App充值北京一卡通的抓包。我们最终完成了这一操作，得到了这部分流量。
  • 同时我们还在App Store下载了北京一卡通App，使用该App对手机内置的北京一卡通虚拟卡进行充值，这部分抓包就相对容易了，因为第三方App都是会遵循我们的根证书信任设置的，所以我们也顺利获得了使用支付宝支付、微信支付对北京一卡通进行充值的流量。

三、流量分析

  • 首先先直接列出一些结论：
    • iPhone和服务器之间传输的数据是JSON格式。
    • 无论是使用系统钱包App还是使用北京一卡通官方App进行充值，和服务器交互的方式都相同，有区分交易渠道的字段。
    • iPhone与虚拟卡交互的指令是从服务器上下载的。
    • iPhone与虚拟卡交互的指令执行结果会回送给服务器。
    • iPhone总计使用POST请求服务器三次。
  • 在分析了流量之后，我们尝试对数据包进行重放，但是并没有成功。分析主要原因还是因为我们没能找到taskId的产生来源。
  • 具体的流量分析结果详见Word文档。

四、一些其它发现

  • 我曾经尝试了这样的操作，类似于抓取系统钱包App充值北京一卡通时候的操作，只不过在第二步，我没有信任根证书。也就是说，在第一阶段Apple Pay交易完成后，进入第二阶段更新卡片的操作时，开始中间人攻击，这时候更新卡片的操作会停止，即使在网络恢复之后，也不会重试更新卡片，结果就是损失了本次充值的余额。但是好在北京一卡通方面每日凌晨似乎会进行对账，这笔钱会在第二天凌晨通过银行退款系统返还。但是我在测试在阶段二断开网络连接的情况下，更新卡片的操作停止，再连接到网络，更新卡片的操作依旧会重新尝试，最终完成充值操作。我相信这是一个苹果方面的编码疏忽。关于此问题，已经报送给Apple Feedback。（因为我用的是iOS 12 Public Beta）

五、还能做什么

  • 分析上海一卡通的充值流程
  • 分析开新卡时的数据流量：这个操作有些难度，因为这个操作同样是在系统App中进行的，部分操作无法抓包。
  • 分析吸卡模式开新卡时的数据流量是否与正常方式相同：这个操作有些难度，因为这个操作同样是在系统App中进行的，部分操作无法抓包。
  • 逆向分析北京一卡通App iOS版：因为隔壁小组对Android端充值北京一卡通的流量进行了分析，其使用的接口和iOS端不同，所以如果想了解iOS上充值北京一卡通的流程，只能对iOS版本进行逆向。App Store分发的App都进行了比较严重的混淆，同时还对可执行文件进行了加密，所以难度也比较大。我尝试逆向了北京一卡通App Android端，使用了梆梆安全的壳，有时间的话也可以研究一下。
  • 在越狱过的iPhone上再次进行流量分析：因为不越狱的手机理论上无法抓取系统App的HTTPS流量。苹果在iOS 11.3才加入了北京和上海的公交卡功能，目前公开资料显示可以越狱的最高版本iOS是11.3.1，所以该方案理论上是可操作的。[4]

六、参考文献