逆向工程破解 Pokémon GO Plus 的 OTA 签名验证机制

逆向工程 Pokémon GO Plus 第二部分：OTA 签名绕过

距离我发布Pokemon Go Plus研究发现已近6个月，至今无人公开其Pokemon Go Plus密钥。其中一个原因是从OTP（一次性可编程）存储器提取密钥需要精密焊接技术。在我发表文章几周后，我在/r/pokemongodev提出了通过空中下载（OTA）更新提取Pokemon Go Plus密钥的设想。

该设想基于两个事实：

1. 我们可以使用SPI编程器刷入任意镜像，且不存在签名验证，只需正确校验和
2. SPI闪存包含两份相同固件副本（存在2个固件库），这对OTA至关重要：若固件传输失败，引导程序（位于OTP中）将启动另一份有效固件

计划方案如下：

1. 创建自定义固件
2. 通过OTA将新固件刷入Bank 1。此时设备将存在两个固件：我们的固件和官方固件
3. 通过新固件的BLE（低功耗蓝牙）功能提取密钥
4. 向新固件发送特殊请求恢复原始固件（通过读取Bank 2的原始固件覆盖Bank 1的固件）

实施挑战

两个月前，Reddit用户jesus-bamford联系我并表示将实施该方案。进展看似顺利：

• 他能创建从OTP提取密钥的固件
• 能使用SPI编程器写入固件
• 能通过OTA发送固件（使用Dialog Semiconductor提供的Android应用）

但好消息至此为止：通过OTA写入的固件无法启动。引导程序认为固件无效，会启动Pokemon Go Plus的原始固件。他发现软件更新过程中存在SDK源码未提及的额外验证机制，但无法确定具体验证方式或绕过方法。

深度逆向分析

在泰国泼水节假期期间，我通过逆向工程引导程序确认了额外验证机制的存在：

1. 更新启动时设置标志位表明固件镜像尚未生效（确保更新失败时能启动其他有效固件）
2. 初始化SHA256哈希值
3. 每个写入SPI闪存的数据块都会更新哈希值
4. 更新结束时基于SHA256和OTP数据进行签名验证，验证通过后设置镜像有效标志

关键发现：

• 通过SPI编程器修改固件时，有效标志位会保留
• 通过OTA修改固件时，需要在更新结束时通过验证才能设置有效标志
• 更新过程需要OTP区域的特定密钥（意味着Niantic的官方更新需要服务器连接获取特殊密钥）

突破性漏洞发现

通过分析DA14580 SDK中的app_spotar_img_hdlr.c源码，发现关键函数：

ret = spi_flash_write_data(spota_all_pd, 
                          (spota_state.mem_base_add + spota_state.suota_img_idx), 
                          spota_state.suota_block_idx);

其中spota_all_pd包含来自更新应用的数据，第二个参数指定SPI闪存写入地址，第三个参数为数据大小。

更重要的是发现app_spotar_read_mem函数存在设计缺陷：该函数使用spota_state.mem_base_add存储临时值而非使用临时变量。当spota_state.mem_base_add大于2时函数会失败。

漏洞利用方案

利用流程：

1. 正常通过OTA发送数据（数据将按预期写入SPI闪存）
2. 在发送最后数据块前，触发app_spotar_read_mem调用，将mem_base_add修改指向固件头部的有效标志位地址
3. 发送最终数据块覆盖固件头部（包含我们设计的有效头部数据）

成功实践

Jesus-bamford出色地实现了该方案并取得成功。相关固件已在GitHub开源：

https://github.com/Jesus805/PGP_Suota

目前Android版更新工具尚未发布（正在基于SDK代码重写）。完成后用户将无需拆机即可提取Pokemon Go Plus密钥。

虽然本应等待其工作完成再发布本文，但我希望更多人能参与开发：包括iOS版本实现、其他设备的Pokemon Go Plus适配，甚至通过EdXposed（兼容Pokemon Go的XPosed分支）或iOS BLE API拦截库实现相同功能。