第19章 CarPlay协议逆向分析

课程目录第19章 CarPlay协议逆向分析

第19章 CarPlay协议逆向分析：协议栈、iAP2、认证芯片与破解思路

说实话，CarPlay的逆向分析，是我这几年做过最头疼、也最有成就感的事情之一。

你可能觉得，不就是个投屏吗？手机连上车机，把界面映射过去不就完了？

嗯，如果你真这么想，那说明你还没被苹果的“黑盒”毒打过。

CarPlay不是简单的屏幕投射。它是一整套协议栈，从物理层到应用层，层层加密、层层校验。我当年第一次抓包分析时，看着满屏的乱码，差点把逻辑分析仪摔了。

这一章，我就带你把这些“黑盒”一层层剥开。

19.1 CarPlay协议栈的整体架构

先看一张图，这是我个人习惯——动手之前，先把全局框架理清楚。

你看，从底层到顶层，一共四层。但真正让开发者头疼的，是第二层——会话层里的iAP2协议。

为什么？因为苹果把几乎所有核心逻辑都塞进了iAP2。认证、音视频流控制、触控反馈……全走这个协议。

19.2 iAP2协议深度解析

iAP2，全称是 iPod Accessory Protocol 2。名字里带个“iPod”，但实际是苹果所有外设通信的基石。

我当年第一次接触iAP2，是在一个车机项目上。客户说：“你帮我把CarPlay跑起来。”我心想，不就是调个SDK吗？结果发现，苹果根本没公开iAP2的文档。

嗯，那就只能逆向。

19.2.1 iAP2的报文结构

iAP2的报文，说白了就是一组一组的TLV（Type-Length-Value）。

字段	长度（字节）	说明
Sync Byte	2	固定为 0xFF 0xFE，用于帧同步
Length	2	整个报文长度（含头部）
Type	1	报文类型（0x00~0xFF）
Payload	可变	具体数据内容
Checksum	1	异或校验

举个例子，我抓到一个典型的iAP2报文：

FF FE 00 0C 12 48 65 6C 6C 6F 00 00 00 00 00 00 3A
|--Sync--|Len=12|Type=0x12|----Payload: "Hello"----|CS=0x3A|

这里Type=0x12，代表这是一个“设备信息请求”。Payload里就是具体的参数。

我的经验：抓iAP2报文，别用普通的USB分析仪。我推荐用带硬件触发功能的逻辑分析仪，比如Saleae Logic Pro。不然你会在海量数据里迷失方向。

19.2.2 关键的iAP2会话流程

CarPlay启动时，iAP2会走这么几步：

设备发现：车机广播自己的iAP2能力，手机回应。
认证握手：手机要求车机证明自己是“合法配件”。
会话建立：认证通过后，协商音视频参数、触控模式等。
数据传输：开始传输实际的CarPlay UI画面和音频。

这里面，第二步是最难啃的骨头。

19.3 认证芯片与MFi体系

苹果的MFi（Made for iPhone）认证，核心就是一颗小小的芯片。

这颗芯片长什么样？我拆过好几个车机模块，里面那颗芯片通常是 NXP的LPC11U35 或者 TI的MSP430，封装成特殊的SOP-8或者QFN-20，上面打着苹果的专属Logo。

核心要点：认证芯片内部存储了苹果颁发的私钥和证书。车机必须通过这颗芯片与手机完成双向认证，否则手机拒绝任何iAP2通信。

认证过程大致是这样的：

手机生成一个随机数，发给车机。
车机把随机数传给认证芯片，芯片用私钥签名后返回。
手机用苹果公钥验证签名。通过，则认证成功。

你可能会问：那我把认证芯片的通信协议模拟出来，不就能绕过吗？

嗯，我当年也是这么想的。结果发现，苹果在芯片和车机主控之间，还加了一层加密通道。你截获的数据全是密文，没有芯片内部的密钥，根本解不开。

警告：不要试图物理拆解认证芯片。苹果在芯片内部集成了防篡改机制，强行读取会导致芯片自毁。我见过有人用聚焦离子束（FIB）去切芯片，结果芯片直接烧了。

19.4 私有协议的破解思路

说完了认证，咱们聊聊更“野”的路子——私有协议破解。

CarPlay除了iAP2，还有一套私有协议，用于传输音视频流和触控事件。这套协议没有公开文档，完全靠逆向。

我个人习惯的破解思路分三步：

19.4.1 第一步：抓包与协议识别

用USB分析仪抓取车机和手机之间的所有USB Bulk传输数据。你会发现，大部分数据包都带有固定的头部魔数（Magic Number）。

比如，CarPlay的视频流数据包，头部通常是 0x01 0x02 0x03 0x04 这四个字节。音频流则是 0x0A 0x0B 0x0C 0x0D。

把这些魔数找出来，你就知道哪些包是干什么的了。

19.4.2 第二步：协议字段分析

找到特定类型的包之后，开始分析内部字段。我常用的方法是“差分对比法”：

发送一个触控事件（比如点击屏幕左上角），抓包。
再发送一个触控事件（点击屏幕右下角），抓包。
对比两个包的差异，找出表示X、Y坐标的字段。

我曾经用这个方法，花了三天时间，把CarPlay的触控协议摸了个七七八八。说白了，就是暴力枚举加对比。

19.4.3 第三步：重放与验证

分析出字段含义后，写一个简单的脚本，构造伪造的数据包发送给车机。如果车机有响应，说明你猜对了。

// 伪代码示例：构造一个触控点击包
uint8_t touch_packet[] = {
    0x01, 0x02, 0x03, 0x04,  // 魔数
    0x00, 0x01,              // 包类型：触控事件
    0x01, 0x2C,              // X坐标：300
    0x00, 0xF0,              // Y坐标：240
    0x01,                    // 动作：按下
    0x00                     // 保留
};
send_usb_bulk(touch_packet, sizeof(touch_packet));

避坑指南：我曾经在重放测试时，不小心把坐标写成了负值，结果车机直接死机了。后来发现，CarPlay的坐标范围是0~65535，超出这个范围会触发异常处理。所以，测试时一定要做边界检查。

19.5 破解的边界与法律风险

说到这里，我得泼一盆冷水。

逆向分析CarPlay协议，技术上可行，但法律上风险极高。苹果的MFi认证受《数字千年版权法》（DMCA）保护，破解认证芯片可能构成“规避技术保护措施”的违法行为。

我认识的一位同行，因为破解CarPlay协议做第三方车机，被苹果法务发了律师函，最后赔了一大笔钱和解。

所以，我的建议是：

学习目的：随便逆向，没问题。自己搭实验环境，跑通协议，涨涨经验。
商业目的：老老实实走MFi认证。虽然流程繁琐、费用不低，但至少睡得安稳。

嗯，这一章的内容就到这里。CarPlay的协议栈很深，iAP2只是冰山一角。下一章，我们会继续深入，看看音视频流的具体传输机制。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录