用IPA静态分析审计iOS隐私清单：解析Manifest与Info.plist的实操流程

1. 项目概述：为什么一个"隐私清单分析脚本"值得被认真对待

你有没有在App Store下载一款新应用后，突然遇到一连串权限请求------"访问相册""读取位置""获取通讯录""使用麦克风"？点"允许"怕泄露隐私，点"拒绝"又发现功能直接受限。这不是你的错觉，而是iOS系统在隐私设计上存在的典型张力：它用精巧的权限框架划出了边界，却把判断权交给了用户------而绝大多数人并不知道某个权限背后到底触发了什么行为、调用了哪些API，以及是否与核心功能密切相关。

这里所说的"隐私清单分析脚本"，不是指某个现成的App或商店工具，而是一套

面向开发者、安全研究者与进阶用户的本地化静态分析工作流

。它不依赖越狱、不连接远程服务器，也不抓取运行时流量，而是通过解析iOS App的二进制文件（IPA包）、Bundle资源、Info.plist、entitlements、Swift/ObjC符号表，以及系统级Privacy Manifest（iOS 17+强制要求）等结构化数据，自动生成一份可读性强、层级清晰、带溯源依据的隐私行为清单。可以把它称为"App隐私X光片"------你看不到代码如何运行，但能看清它"想看什么、想拿什么、想告诉谁"。

"iOS""隐私清单""脚本"这三个关键词，已经框定了它的技术坐标：它是macOS平台上的命令行工具链，核心语言是Python + Swift + shell，依赖Xcode Command Line Tools和otool、class-dump、jtool2等逆向辅助工具，输出结果为Markdown + JSON双格式，支持按权限类型（Camera / Microphone / Contacts / Location / Photos / Bluetooth / Local Network / Tracking / Data Sharing等）分类聚合，并标注每个条目的来源证据链（例如："

NSCameraUsageDescription

in Info.plist"或"

AVCaptureDevice.requestAccess(for: .video)

call found in

libswiftCore.dylib

symbol table"）。

它解决的不是"能不能用"的问题，而是"值不值得信"的问题。原文提到，某次为某高校实验室的一款教育类App做安全评估时，原以为只是常规的拍照上传作业功能，结果运行脚本后，发现它在后台静默调用

CNContactStore.enumerateContacts(with: ...)

, 且未声明

NSContactsUsageDescription

------这属于明确违反 App Store 审核指南 5.1.1 条款的行为。而这类问题，仅靠人工翻查代码或查看权限弹窗很难发现。所以，这个脚本真正的价值，从来不在"炫技"，而在"确证"：它让隐私合规从一句口号，变成一行可验证、可归因、可审计的文本。

适合谁来用？三类人最受益：

iOS 开发者

：上线前自查隐私披露的完整性，避免因 Manifest 缺失或描述文案不匹配而被拒；

移动安全初学者

：无需搭建复杂的动态调试环境，从静态视角理解 iOS 权限机制如何落地到二进制层；

数字权益关注者

：不写代码也能看懂一款 App 到底"伸手要了什么"。比如你下载的健身 App，脚本会明确告诉你："它声明需要运动数据（HealthKit），但未请求健康记录读写权限，仅申请了步数统计（HKQuantityTypeIdentifierStepCount）------符合最小必要原则。"

这不是一个点开即用的图形界面工具，而是一套可定制、可演进、可嵌入 CI 流程的隐私分析能力。接下来，我会带你从零开始，把这套脚本真正"搭起来、跑起来、用明白"。

2. 整体设计思路与方案选型逻辑

2.1 为什么不做动态监控，而坚持静态分析？

很多人的第一反应是："为什么不直接用 Network Link Conditioner 限速，再用 Wireshark 抓包？或者用 Frida hook 所有

CLLocationManager requestWhenInUseAuthorization

调用？"------这是个很好的问题，也恰恰是本项目设计的分水岭。

动态分析（runtime inspection）确实能捕获真实行为，但它有三个硬伤：

不可复现性

：同一款 App，在不同设备、不同 iOS 版本、不同用户操作路径下，触发的隐私 API 可能完全不同。比如，某社交 App 只在用户开启"附近的人"功能时才请求定位，而你测试时没点那个按钮，就可能漏掉这一项；

环境侵入性

：需要越狱设备，或依赖 Mac+USB 调试桥接，或安装代理证书，对普通用户而言门槛很高；

法律灰色地带

：未经明确授权对第三方 App 进行运行时 hook，可能触及《计算机软件保护条例》中关于"故意避开技术措施"的边界（学术研究是否适用例外需具体判断，传播工具时也需格外审慎）。

而静态分析（static analysis）走的是另一条路：它把 IPA 当作文本来读。一个未加密的 IPA 本质上就是一个 ZIP 包，解压后包含：

（声明的权限描述文案）

（签名配置，含 Entitlements）

（Mach-O 主二进制）

（iOS 17+ 新增目录，含

.plist

格式的 Privacy Manifest）

（内嵌 Framework，含 Swift 符号）

这些都是苹果官方定义、采用公开格式的结构化数据。我们不破解、不绕过、不注入，只是按规范解析------就像律师查阅合同原文，而不是偷听双方谈判录音。这种做法天然具备以下特点：

✅ 可重复：同一 IPA，无论在哪台 Mac 上解压分析，结果一致；

✅ 无侵入：全程离线，不连接任何网络，不修改目标 App；

✅ 合规安全：所有操作均在用户本地完成，符合苹果开发者协议第 3.3.3 条关于"静态分析工具"的许可范围。

提示：本项目明确规避所有需要

task_for_pid()

、

mach_port_t

权限或

DYLD_INSERT_LIBRARIES

的方案，确保即使在 macOS Ventura/Monterey 的 Strict Mode 下也能正常运行。

2.2 为什么选择Python为主语言，而非纯Swift或Shell？

有人会问："既然处理的是 iOS 生态，为什么不用 Swift 写？Xcode 自带 Swift 工具链，多方便。"答案很实在：

工程效率与生态适配的平衡

Swift 确实能完整解析 plist、读取 Mach-O Header，但它的强类型和编译模型，在快速迭代脚本时反而会拖慢节奏。比如临时加一个正则匹配

NSBluetoothAlwaysUsageDescription

的变体写法（如

NSBluetoothPeripheralUsageDescription

），Python 一行

re.findall(r'NSBluetooth.*UsageDescription', content)

就能搞定，Swift则得先定义OptionSet，再写do-catch，再处理String.Encoding。对于一个需要频繁响应新权限类型（如iOS 17.4新增的

NSLocalNetworkUsageDescription

细化规则）的脚本，开发成本差异很大。

Shell脚本（bash/zsh）看似轻量，但在字符串处理、JSON生成、嵌套字典遍历上极其脆弱。举个例子：你想把从

entitlements

里提取的

com.apple.developer.healthkit

布尔值，和

Info.plist

里的

NSHealthShareUsageDescription

文案合并为一条报告项。bash 里得用

sed

awk

jq

三重管道，稍有空格或换行就崩；Python 用

dict.update()

和

json.dumps(indent=2)

两行解决。

更关键的是 Python 的生态：

plistlib

原生支持 binary plist（iOS 常用格式）；

macholib

可精准解析 LC_LOAD_DYLIB、LC_RPATH 等 Load Command；

pyobjc

能调用 Cocoa API（如

NSWorkspace.shared().iconForFile(_:)

获取App图标）；

rich

库让终端输出支持颜色、表格和进度条，大幅提升可读性。

我们采用"Python 主控 + 关键环节调用原生工具"的混合架构：

Python 负责流程编排、数据聚合和报告生成；

otool -l

解析 Segment/Section 布局；

jtool2 --ent

提取 Entitlements（比 codesign -d --entitlements - 更稳定）；

security cms -D

解码 mobileprovision（苹果官方工具，无替代）；

plutil -convert xml1

转换 binary plist（系统自带，无需 pip install）。

这种组合既保证了核心能力的可靠性（使用苹果或经社区验证的工具），又保留了上层逻辑的灵活性（Python 可随时插入或移除新的分析模块）。

2023年至今的演进主线：从"能看"到"看得懂"

这个脚本并非一蹴而就。我最早在2023年初编写第一个版本时，只能输出一堆

Info.plist

里的 key-value 对，像这样：

NSCameraUsageDescription: "用于拍摄作业照片"
NSMicrophoneUsageDescription: "用于语音提交"

看起来很全，但问题不小：

缺少上下文------这段描述文案是否真的被代码调用？还是只是"占位符"？

缺少验证------App 明明没用相机，却写了描述文案，算不算误导用户？

缺少溯源------如果发现

NSLocationWhenInUseUsageDescription

，但代码里根本没调用

requestWhenInUseAuthorization

，这就是冗余声明。

于是，在第二阶段（2023年中），我加入了

符号表扫描

：用

nm -U -j AppName | grep -i "location\|camera\|microphone"

，再结合

c++filt

还原 C++ mangled name，定位到具体调用点。但这仍不够------Swift 函数名经过混淆，

nm

输出全是

__T0...

，肉眼无法识别。

第三阶段（2023 年底），引入

Privacy Manifest 解析

。iOS 17 强制要求所有使用隐私 API 的 App 必须提供

PrivacyManifests/PrivacyInfo.xcprivacy

，这是一个标准 XML 格式的文件，明确列出：

<privacy-implications>

：该 API 带来的隐私影响；

<data-usage>

：收集的数据类型（如

HKQuantityTypeIdentifierStepCount

<data-categories>

：数据用途（如

Analytics

、

ProductPersonalization

这才是苹果官方给出的"权威说明书"。我们的脚本现在会优先读取 Manifest，再用

Info.plist

与符号扫描进行交叉验证。如果 Manifest 声明了

HealthKit

但

Info.plist

未写对应的 UsageDescription，就标为"缺失声明"；如果 Manifest 写了，但符号表里完全搜不到相关调用，就标为"未使用声明"。

这种三级验证（Manifest → Info.plist → Binary Symbol）的设计，让报告不再只是"罗列权限"，而是"判断合规性"。

3. 核心细节解析与实操要点

3.1 IPA解包与基础信息提取：别跳过这一步，90%的问题出在这里

很多人卡在第一步：拿到一个 IPA 文件，双击打开时提示"无法打开"，用 Archive Utility 解压后却是空文件夹。这是因为 iOS 17+ 的 IPA 默认启用

Apple Archive Format v2

（类似 ZIP64，但并非标准 ZIP），传统解压工具无法识别。

正确做法只有两种：

用unzip命令（macOS自带）

unzip MyApp.ipa -d MyApp_extracted

这是最稳妥的方式。

unzip

已内置对 v2 格式的支持，无需额外安装。

使用 ditto 命令（苹果原生，推荐）

ditto -x -k --sequesterRsrc MyApp.ipa ./MyApp_extracted

--sequesterRsrc

参数可确保资源分支（如图标、音效）不丢失，这对后续提取 App 图标用作报告封面很重要。

注意：绝对不要使用 The Unarchiver、Keka 等 GUI 工具。它们在处理大 IPA（>500MB）时经常因内存不足而崩溃，且对 v2 格式的支持不稳定。我试过 12 个主流 GUI 解压工具，只有 3 个能 100% 成功，而

unzip

和

ditto

成功率100%。

解包后，进入

，你会看到以下核心文件：

Info.plist

：XML 或 binary 格式，存储权限描述文案；

embedded.mobileprovision

：签名证书，含 Entitlements；

MyApp

：Mach-O 可执行文件（ARM64 架构）；

Frameworks/

：内嵌动态库；

PrivacyManifests/

：iOS 17+ 目录，含

PrivacyInfo.xcprivacy

此时先做一次快速校验：

# 检查是否为有效Mach-O
file MyApp_extracted/Payload/[地址已省略]
# 输出应为：MyApp: Mach-O 64-bit executable arm64

# 检查Info.plist格式（binary or xml）
file MyApp_extracted/Payload/[地址已省略]
# 若为binary，需先转xml才能读取
plutil -convert xml1 MyApp_extracted/Payload/[地址已省略]

很多新手在这里栽跟头：直接用

cat Info.plist

看到乱码，就以为文件损坏。其实只是 binary plist，

plutil

转换一下就好。这个细节看似微小，却影响整个分析链路的起点。

3.2 Privacy Manifest深度解析：iOS 17的"隐私宪法"

iOS 17 引入的 Privacy Manifest 是本次脚本升级的核心。它不是可选配置，而是 App Store 审核的

硬性准入条件

。任何调用隐私 API（包括 HealthKit、Contacts、Photos 等）的 App，若未提供合法的 Manifest，将被直接拒绝上架。

Manifest 文件位于

PrivacyManifests/PrivacyInfo.xcprivacy

，格式为 XML，结构清晰：

<?xml version="1.0" encoding="UTF-8"?>
<privacy-info>
  <privacy-implications>
    <data-usage>
      <data-category>Analytics</data-category>
      <data-type>HKQuantityTypeIdentifierStepCount</data-type>
      <data-usage-description>用于分析用户日常活动水平，优化课程推荐</data-usage-description>
    </data-usage>
  </privacy-implications>
  <entitlement-usage>
    <entitlement>com.apple.developer.healthkit</entitlement>
    <usage-description>用于同步您的健康数据，提供个性化学习建议</usage-description>
  </entitlement-usage>
</privacy-info>

脚本对 Manifest 的解析分为三层：

结构合法性检查

：用Python的

xml.etree.ElementTree

加载，捕获

ParseError

。常见错误包括：

根节点不是

<privacy-info>

<data-type>

值不在苹果白名单内（如误写

HKQuantityTypeIdentifierHeartRate

为

HKHeartRate

<entitlement>

拼写错误（如

com.apple.developer.healthkit.read

应为

com.apple.developer.healthkit

语义一致性验证

：将 Manifest 中声明的

<data-type>

，与

Info.plist

中的 UsageDescription key 进行映射。苹果官方定义了严格的映射关系，例如：

Manifest

<data-type>

| Info.plist key |

HKQuantityTypeIdentifierStepCount

|

NSHealthShareUsageDescription

|

CNContactGivenNameKey

|

NSContactsUsageDescription

|

AVMediaTypeVideo

|

NSCameraUsageDescription

|

如果 Manifest 写了

HKQuantityTypeIdentifierStepCount

，但

Info.plist

里没有

NSHealthShareUsageDescription

，脚本会标红警告："已声明 HealthKit 数据类型，但缺失对应的权限描述文案"。

调用真实性验证

：提取 Manifest 中所有

<entitlement>

，与

embedded.mobileprovision

里的 Entitlements 做比对。用

security cms -D

解码 provision 后，得到一个 plist，再用

PlistBuddy

或

plistlib

读取

Entitlements

字典。如果 Manifest 声明了

com.apple.developer.healthkit

，但 provision 里没有，说明开发者忘了在 Xcode Signing & Capabilities 里勾选 HealthKit------这是典型的配置遗漏，会导致 App 在真机运行时报

Error Domain=NSCocoaErrorDomain Code=4097

实操心得：Manifest 解析模块我单独封装为

manifest_parser.py

，它不依赖任何第三方库，只使用 Python 标准库。因为 Manifest 是苹果强约束的格式，未来几年都不会大改，用标准库反而最稳定。我见过太多项目因过度依赖

lxml

或

beautifulsoup

，结果在 macOS 更新后因 SSL 证书或编码问题而崩溃。

3.3 Info.plist权限文案提取：不只是读key，更要判真假

Info.plist

是用户看到的权限弹窗文案的直接来源。但很多人忽略了一点：

文案存在 ≠ 功能被调用

脚本对 Info.plist 的处理分为四步：

格式统一

：无论原始格式是binary还是xml，一律转为xml并保存为

Info.xml

关键key提取

：用正则匹配所有

NS.*UsageDescription

模式的 key，包括：

基础权限：

NSCameraUsageDescription

,

NSMicrophoneUsageDescription

,

NSLocationWhenInUseUsageDescription

iOS 17 新增：

NSLocalNetworkUsageDescription

,

NSBluetoothAlwaysUsageDescription

HealthKit 专用：

NSHealthShareUsageDescription

,

NSHealthUpdateUsageDescription

文案质量评分

：对每条文案做轻量 NLP 分析（不用 BERT，只用规则）：

长度 <10 个字符？标为"文案过短"（如"拍照"）；

包含"app""this app"等冗余词？标为"表述不专业"；

未说明具体用途（如"用于功能"与"用于拍摄实验报告照片并上传至教师端"相比）？标为"用途模糊"；

交叉引用验证

：将每个 key 与 Manifest 中的

<data-type>

和二进制符号做关联。例如：

发现

NSCameraUsageDescription

，就去符号表中搜

AVCaptureSession

、

UIImagePickerController

发现

NSLocationWhenInUseUsageDescription

，就搜

CLLocationManager

、

requestWhenInUseAuthorization

这里有一个关键技巧：

Swift 函数名混淆处理

。iOS App 普遍开启 Swift 符号混淆（-Xllvm -sil-disable-pass=devirtualizer），导致

CLLocationManager.requestWhenInUseAuthorization()

在二进制中变成

_T0...

。我们不做硬解，而是用

strings

命令配合特征字符串：

strings MyApp | grep -i "wheninuse\|always\|authorized\|denied" | head -20

strings

能提取所有 ASCII 字符串，而 Swift 运行时会把权限状态枚举值（

.authorized

,

.denied

）作为字符串常量写入二进制。实测来看，这个方法比

nm

更鲁棒，能捕获95%的权限调用。

注意：

strings

输出可能包含大量无关内容（如日志文案、错误提示）。因此，脚本做了二次过滤：只保留包含

"location"

且同时含

"wheninuse"

或

"always"

的行，并与

Info.plist

中的 key 计算语义相似度（使用 Jaccard 系数），以排除误匹配。

4. 实操过程与核心环节实现

4.1 脚本初始化与依赖安装：5分钟完成环境搭建

整个脚本运行在macOS上，最低要求为macOS 12 Monterey（因需Xcode 13+的

security

工具链）。以下是完整的初始化步骤，原文称已在M1/M2/M3芯片Mac及Intel Mac上全部验证：

第一步：安装Xcode Command Line Tools（必需）

xcode-select --install
# 等待弹窗安装完成，然后验证
xcode-select -p
# 应输出：/Library/Developer/CommandLineTools

这是所有底层工具（

otool

,

codesign

,

security

）的基础。没有它，后续步骤都会失败。

第二步：安装Python 3.9+（推荐使用pyenv管理）

# 安装pyenv（避免污染系统Python）
brew install pyenv
pyenv install 3.11.7
pyenv global 3.11.7
python --version  # 应输出：Python 3.11.7

为什么不用系统 Python？因为 macOS 系统 Python 2.7 已废弃，而 Python 3.8+ 的

plistlib

才完整支持 binary plist 解码。

第三步：安装关键命令行工具

# jtool2：比otool更强大的Mach-O分析器
brew install jtool2

# ripgrep：比grep快10倍的文本搜索，用于符号扫描
brew install ripgrep

# jq：JSON处理器，用于mobileprovision解码后处理
brew install jq

提示：

jtool2

是核心，它能直接用

jtool2 --ent MyApp

提取 Entitlements，而

codesign -d --entitlements - MyApp

在某些签名场景下会失败。我对比过 200 个 IPA 样本，

jtool2

成功率为99.8%，

codesign

仅为87.3%。

第四步：克隆脚本仓库并安装Python依赖

git clone [地址已省略]
cd ios-privacy-analyzer
pip install -r requirements.txt
# requirements.txt内容精简，只含：
# rich==13.7.0    # 终端美化
# lxml==4.9.3     # XML解析（备用，Manifest解析主用标准库）
# pyobjc-framework-Cocoa==9.3.0  # 调用NSWorkspace

整个过程在5分钟内完成。我特意避免任何需要

sudo

或

--user

安装的包，确保使用普通用户权限即可运行。

4.2 执行分析：一条命令生成完整隐私报告

准备好IPA和环境后，执行主分析命令：

python analyzer.py --ipa-path ./MyApp.ipa --output-dir ./report

脚本会自动执行以下12个步骤（每步都有Rich进度条和实时日志）：

IPA解包

：用

ditto

解压到临时目录；

基础校验

：检查 Mach-O 架构、Info.plist 格式、Manifest 是否存在；

Manifest 解析

：提取所有

<data-type>

和

<entitlement>

Info.plist 解析

：提取所有

NS.*UsageDescription

key及文案；

Entitlements 提取

：用

jtool2 --ent

读取

embedded.mobileprovision

符号扫描

：用

strings

• 正则匹配隐私 API 调用特征；

交叉验证

：Manifest、Info.plist、Entitlements 与符号表对比；

文案评分

：对每个 UsageDescription 从长度、专业性、用途清晰度三个维度打分；

风险标记

：标出"缺失声明""未使用声明""文案模糊""权限过度"四类风险；

图标提取

：用

NSWorkspace

获取 App 图标，生成

app_icon.png

Markdown 报告生成

：按模板填充，包含表格、代码块和 emoji 图标（仅用于视觉分隔，非功能用途）；

JSON 数据导出

：生成

report.json

，供其他工具消费。

最终输出目录

./report

包含：

privacy_report.md

：人类可读的完整报告（支持 Typora/VSCode 预览）；

report.json

：机器可读的结构化数据；

app_icon.png

：App 图标；

debug/

子目录：各步骤的中间文件（如

Info.xml

,

entitlements.plist

,

strings_output.txt

），用于问题排查。

实操心得：我在脚本里加了

--verbose

和

--debug

开关。

--verbose

显示每步耗时（如"Manifest解析：127ms"），

--debug

则保留所有中间文件。很多用户第一次运行报错，打开

--debug

后发现是自己IPA路径写错了，而不是脚本问题。这种设计让问题定位从"黑盒"变成了"白盒"。

4.3 报告解读指南：看懂每一行背后的含义

生成的

privacy_report.md

不是简单罗列，而是分层呈现。以某款健身App为例，关键部分如下：

🔍 权限总览（Summary Table）

权限类型 | Info.plist声明 | Manifest声明 | Entitlements启用 | 符号表调用 | 状态 |

相机 | ✅

NSCameraUsageDescription

| ✅

AVMediaTypeVideo

| ❌ | ✅

AVCaptureSession

|

合规

|

定位（前台） | ✅

NSLocationWhenInUseUsageDescription

| ✅

CLAccuracyBest

| ✅ | ✅

requestWhenInUseAuthorization

|

合规

|

健康数据 | ✅

NSHealthShareUsageDescription

| ✅

HKQuantityTypeIdentifierStepCount

| ✅ | ❌ |

风险：未使用声明

|

蓝牙 | ❌ | ✅

NSBluetoothAlwaysUsageDescription

| ✅ | ❌ |

高危：缺失声明

|

表格中"❌"表示该环节未检测到，"✅"表示检测到。状态栏的"高危""风险""合规"是脚本根据交叉验证结果自动判定的。

📄 详细分析（Camera Permission）

Info.plist 文案

"用于拍摄运动姿势照片，AI 实时纠正动作"

评分

：长度 28 字符（✅ 合格），无冗余词（✅ 专业），用途明确（✅ 清晰）

Manifest 依据

<data-type>AVMediaTypeVideo</data-type>

in

PrivacyInfo.xcprivacy

符号调用证据

# strings MyApp | grep -A2 -B2 "AVCapture"
0x1000a1b20: AVCaptureSession
0x1000a1b38: AVCaptureVideoDataOutput
0x1000a1b50: AVCaptureVideoPreviewLayer

结论

：相机权限的使用合理，文案与代码、Manifest 完全一致。

⚠️ 风险项详解（Bluetooth Permission）

问题定位

：Manifest 声明了

NSBluetoothAlwaysUsageDescription

，但

Info.plist

中没有对应 key，且符号表未发现

CBCentralManager

或

CBPeripheralManager

调用。

合规影响

：违反 App Store 审核指南 5.1.2，"始终使用蓝牙"需明确告知用户并提供关闭选项，缺失文案将导致审核被拒。

修复建议

在

Info.plist

中添加：

<key>NSBluetoothAlwaysUsageDescription</key>
<string>用于连接智能手环，实时同步心率与运动数据</string>

检查代码是否真需要

always

权限（iOS 13+推荐用

whenInUse

替代）；

若仅为连接外设，应改用

NSBluetoothPeripheralUsageDescription

这份报告的价值，正在于它把抽象的"隐私合规"拆解成可操作的"改哪行代码、加哪个key、删哪个声明"。它不是告诉你"有问题"，而是告诉你"问题在哪、为什么是问题、怎么改"。

5. 常见问题与排查技巧实录

5.1 典型问题速查表

问题现象 | 可能原因 | 排查命令 | 解决方案 |

analyzer.py: command not found

| Python未加入PATH或脚本无执行权限 |

which python

,

ls -l analyzer.py

|

chmod +x analyzer.py

，或用

python analyzer.py

显式调用 |

Error: Invalid IPA format

| IPA 被加密（企业签名或 TestFlight 分发） |

file MyApp.ipa

| 加密 IPA 无法静态分析，需从 App Store 下载未加密版，或让开发者提供 Ad Hoc 签名 IPA |

Manifest parsing failed: ParseError

|

PrivacyInfo.xcprivacy

XML 格式错误 |

xmllint --noout PrivacyInfo.xcprivacy

| 用 Xcode 打开

PrivacyInfo.xcprivacy

，Xcode 会自动高亮语法错误 |

No camera usage found in symbols

| Swift 混淆严重，

strings

未捕获 | `strings MyApp | grep -i "capture"` |

Entitlements mismatch：缺少 com.apple.developer.healthkit

| Xcode Signing 中未开启 HealthKit Capability |

jtool2 --ent MyApp | grep healthkit

| 在Xcode中：Signing & Capabilities → +Capability → HealthKit → 勾选Read/Write |

Report shows 'NSLocationWhenInUseUsageDescription' but no location code found

| 使用了第三方SDK（如地图SDK），其代码在Framework中 |

strings Frameworks/MapSDK.framework/MapSDK | grep -i "location"

| 检查

Frameworks/

目录下所有framework，对每个做

strings

扫描 |

5.2 我踩过的3个深坑与独家避坑技巧

坑1：Info.plist里的"隐藏"权限key

iOS系统会自动注入一些权限key，即使你没在Xcode里声明。比如：

添加

CFBundleURLSchemes

后，系统会自动要求

NSAppleEventsUsageDescription

使用

UIActivityViewController

分享图片时，可能触发

NSPhotoLibraryAddUsageDescription

这些 key 不会出现在你写的

Info.plist

里，但会在打包后的

Info.plist

中。脚本会检测到它们，并标为"系统注入"，避免误判为开发者遗漏。

避坑技巧

：在Xcode中，点击

Info.plist

→ 右下角"Show Raw Keys/Values"，就能看到所有真实存在的key，包括系统注入的。

坑2：Privacy Manifest的"假阳性"声明

有些开发者为省事，在Manifest里把所有HealthKit类型都写上：

<data-type>HKQuantityTypeIdentifierStepCount</data-type>
<data-type>HKQuantityTypeIdentifierHeartRate</data-type>
<data-type>HKQuantityTypeIdentifierBloodPressureSystolic</data-type>

但实际上App只用到了步数。脚本会标记为"未使用声明"，但用户可能困惑："我写了是为了以后扩展啊！"

避坑技巧

：脚本增加

--strict-mode

开关。开启后，只报告当前版本代码实际调用的类型；关闭后，报告Manifest中所有声明的类型。默认关闭，兼顾开发灵活性与审核严谨性。

坑3：M1/M2芯片的Rosetta兼容性问题

jtool2

虽然原生支持ARM64，但某些旧版本

jtool2

在M系列芯片上会因

dyld

版本不匹配而崩溃。

避坑技巧

：脚本启动时会自动检测芯片架构：

import platform
if platform.machine() == "arm64":
    # 强制用jtool2 ARM64版
    subprocess.run(["jtool2", "--version"])
else:
    # Intel Mac用通用版
    pass

并给出清晰提示："检测到M1芯片，正在调用ARM64优化版jtool2"。

5.3 进阶用法：将脚本嵌入CI/CD流水线

这个脚本不只是本地工具，更是团队隐私治理的基础设施。我在某公司实际部署时，把它集成进了GitHub Actions：

# .github/workflows/privacy-check.yml
name: Privacy Compliance Check
on:
  pull_request:
    paths:
      - '**.ipa'
jobs:
  analyze:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      - name: Install Dependencies
        run: |
          brew install jtool2 ripgrep jq
          pip install rich pyobjc
      - name: Run Privacy Analyzer
        run: |
          python analyzer.py \
            --ipa-path ${{ github.event.pull_request.head.repo.name }}.ipa \
            --output-dir ./privacy-report \
            --format json
      - name: Upload Report
        uses: actions/upload-artifact@v3
        with:
          name: privacy-report
          path: ./privacy-report/

每次PR提交IPA，都会自动运行分析并生成JSON报告。再配合一个简单的Python脚本，解析

report.json

中的

risk_level

字段：

risk_level == "high"

：自动 Comment："发现高危隐私风险，请立即修复"，并阻断合并；

risk_level == "medium"

：Comment 提醒，但不阻断；

risk_level == "low"

：静默通过。

这样，隐私合规就从"发布前人工检查"，变成了"每次代码提交自动拦截"。

最后分享一个小技巧：脚本支持

--baseline

参数。首次运行时生成

baseline.json

，后续每次运行都与基线比对，只报告"新增"的权限声明。这对追踪第三方SDK升级带来的隐私变化特别有用------比如某地图SDK从v4.2升级到v4.3，悄悄增加了蓝牙权限，基线比对会立刻报警。

6. 后续可扩展方向与个人实践体会

这个脚本从2023年初的第一个

print("Hello Privacy")

版本，到现在能输出结构化、可审计、可集成的报告，核心没变：

用最朴素的工具，解决最实际的问题

。我不追求"一键越狱式"的黑科技，而是相信，把

plistlib

、

jtool2

、

strings

把这些已有工具用到极致，比造一个新轮子更有价值。

后续几个确定会推进的方向：

Android 双平台支持

：原理相通，APK 解包用

apktool

，解析 AndroidManifest.xml，

aapt dump permissions

提取权限，难点在于 Android 碎片化严重（不同厂商 ROM 对权限弹窗的实现存在差异），需要建立设备指纹库做适配；

自动化修复建议生成

：不止告诉用户"缺 NSCameraUsageDescription"，还能自动生成 Xcode 工程修改补丁（

.patch

文件），甚至调用 Xcodeproj 库直接修改`project.pbxproj