企业官网建设流程全解析

• 文档
• 教程
• 网络安全

本篇技术指南讲解如何在 iOS 上监控应用接收系统 Share Sheet、AirDrop 与 Mail 投递文件时的完整处理链路，并基于 OWASP MASTG 仓库中的 MASTG-TECH-0168 技术条目，结合源码级 hook 输出、Info.plist 静态分析与无源码逆向思路，让读者掌握从"识别可接收文件类型"到"追踪文件落地与再移动"的端到端测试能力。读完本文，你将能够独立完成对 iOS 应用 UIActivity 接收流程的动态观测、入口方法定位与模糊测试。

背景：iOS 应用如何"接收"文件

自 iOS 6 起，系统提供了全局分享机制（Share Sheet），应用既可以通过UIActivityViewController知识条目。

接收侧的关键声明全部位于应用的Info.plist中：

• CFBundleDocumentTypes：声明应用可以打开的文档类型，每条包含名称与一个或多个 UTI（如public.png）。iOS 依据它判断应用是否有资格打开某个文档——仅通过UTExportedTypeDeclarations/UTImportedTypeDeclarations声明 UTI 是不够的。
• UTExportedTypeDeclarations/UTImportedTypeDeclarations：声明应用导出或导入的自定义 Uniform Type Identifiers (UTIs)。

当系统或其他应用把文件交给应用时，iOS 通过以下入口投递：

• application(_:open:options:)：传统 app-delegate 生命周期下的入口；
• scene(_:openURLContexts:)：使用 UIScene 生命周期（scene-based）的应用入口。

应用有责任校验收到的 URL 与文件，并在处理完毕后删除落在自身Documents/Inbox/目录中的文件。

前置准备：先读 Info.plist，确定输入与目标方法

在执行动态监控前，需要先弄清楚"应用声明能打开什么类型"以及"应该 hook 哪些方法"。步骤如下：

1. 获取目标应用的 IPA 包（相关获取流程可参考 MASTG-TECH-0058）。
2. 解压并打开.app包内的Info.plist（它可能是 XML 或二进制 bplist 格式）。
3. 在 macOS 上可用原生plutil转换格式：

plutil -convert xml1 Info.plist

在 Linux 上则使用libplist-utils：

apt install libplist-utils plistutil -i Info.plist -o Info_xml.plist

4. 重点检索以下关键字：

• CFBundleDocumentTypes——应用可打开的文档类型，决定测试时应该投递哪种文件；
• UTExportedTypeDeclarations/UTImportedTypeDeclarations——自定义 UTI；
• CFBundleURLTypes——自定义 URL scheme，对应接收侧的另一类入口。

这些关键字对应Info.plist中的哪些用途，以及grep -i <keyword> Info.plist的检索技巧，在 MASTG-TECH-0058 中有完整说明。这一步直接决定了后续测试的输入文件类型（例如声明了public.pdf就用 PDF）以及预期会出现哪些 open-URL 处理方法。

核心步骤：触发接收并 hook 入口

掌握接收机制后，按以下步骤进行动态观测：

1. 触发接收：从另一个应用向目标应用Share一个文件，或通过 AirDrop、电子邮件发送。要选择能够触发 "Open with..." 对话框的文件类型——即系统没有默认处理程序、必须让用户选择打开应用的类型（例如 PDF）。
2. Hook 入口方法：Hook open-URL 处理入口application:openURL:options:（传统生命周期）与scene:openURLContexts:（scene 生命周期），以及第一步从Info.plist静态分析中识别出的其他相关方法。
3. 观察应用行为：记录 hook 输出的参数、options 字典、返回值与调用堆栈。
4. 进阶测试：额外投递特意构造的畸形文件，或应用模糊测试（fuzzing）技术。

hook 工具推荐使用 Frida——它是本仓库在 iOS 动态分析上的主力工具（见 MASTG-TOOL-0039），可通过fridaCLI、frida-trace与 ObjC API 完成方法观测、参数打印与实现替换。

实战案例：File Manager 应用接收 AirDrop PDF

下面以一款真实世界中的文件管理器（File Manager）应用为例，完整走一遍上述流程：

1. 从另一台 Apple 设备（例如 MacBook）通过 AirDrop 发送一个 PDF 文件。
2. 等待AirDrop弹窗出现，点击Accept。
3. 由于系统对该文件没有默认应用，iOS 会切换到Open with...弹窗。下图展示了该弹窗（应用显示名已使用 MASTG-TOOL-0039 提到的方法修改，以隐藏真实名称）：

4. 选择SomeFileManager后，hook 输出如下：

(0x1c4077000) -[AppDelegate application:openURL:options:] application: <UIApplication: 0x101c00950> openURL: file:///var/mobile/Library/Application%20Support /Containers/com.some.filemanager/Documents/Inbox/OWASP_MASVS.pdf options: { UIApplicationOpenURLOptionsAnnotationKey = { LSMoveDocumentOnOpen = 1; }; UIApplicationOpenURLOptionsOpenInPlaceKey = 0; UIApplicationOpenURLOptionsSourceApplicationKey = "com.apple.sharingd"; "_UIApplicationOpenURLOptionsSourceProcessHandleKey" = "<FBSProcessHandle: 0x1c3a63140; sharingd:605; valid: YES>"; } 0x18c7930d8 UIKit!__58-[UIApplication _applicationOpenURLAction:payload:origin:]_block_invoke ... 0x1857cdc34 FrontBoardServices!-[FBSSerialQueue _performNextFromRunLoopSource] RET: 0x1

这段输出包含丰富的证据：

• 发送方身份：UIApplicationOpenURLOptionsSourceApplicationKey为com.apple.sharingd，即 AirDrop 系统守护进程；
• URL scheme：file://，指向应用沙盒内的Documents/Inbox/路径——当用户选定打开应用后，系统已经把文件移动到了该应用的 Inbox 目录；
• options 细节：LSMoveDocumentOnOpen = 1说明文件是被移动到应用沙盒而非原地打开，OpenInPlaceKey = 0进一步印证；SourceProcessHandleKey携带发送进程句柄（sharingd:605）；
• 返回：RET: 0x1表示application:openURL:options:成功处理了请求。

追踪文件去向：从 Inbox 到 Documents

紧接着，应用会把自己的处理逻辑跑起来。继续 hook 可观察到：

(0x1c002c760) -[XXFileManager moveItemAtPath:toPath:error:] moveItemAtPath: /var/mobile/Library/Application Support/Containers /com.some.filemanager/Documents/Inbox/OWASP_MASVS.pdf toPath: /var/mobile/Documents/OWASP_MASVS (1).pdf error: 0x16f095bf8 0x100f24e90 SomeFileManager!-[AppDelegate __handleOpenURL:] 0x100f25198 SomeFileManager!-[AppDelegate application:openURL:options:] 0x18c7930d8 UIKit!__58-[UIApplication _applicationOpenURLAction:payload:origin:]_block_invoke ... 0x1857cd9f4 FrontBoardServices!__FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ RET: 0x1

堆栈清晰揭示了调用链：application:openURL:options:→__handleOpenURL:→moveItemAtPath:toPath:error:，文件从 Inbox 被移动到/var/mobile/Documents/，随后从 Inbox 移除（符合 MASTG-KNOW-0081 描述的应用责任：处理完 Inbox 中的文件后应将其删除）。

无源码场景：如何定位真正被调用的方法

值得强调的是，以上结论完全不需要源码：

• 第一个 hook（application:openURL:options:）是显而易见的系统回调入口；
• 之后的方法则需要追踪候选方法来确定——例如在 Frida 中观察名字包含copy、move、remove的方法，逐一排查哪个是实际被调用的那个。

这正是动态分析的核心技巧：先 hook 已知入口，再顺着调用链上可能的方法名模式缩小范围，直到锁定真实处理函数。

延伸：自定义 URL scheme 的同类处理方式

UIActivity 接收文件与自定义 URL scheme 的处理方式完全一致——应用同样通过application:openURL:options:等入口接收参数。区别在于前者 URL scheme 为file://、数据是文件本体，后者则是形如igoat://?contactNumber=...的带参 URL。

对自定义 URL scheme 的完整测试方法论——包括静态分析注册信息（CFBundleURLTypes）、动态触发（Safari 地址栏、Notes 应用长按、FridaopenURL）、源应用校验测试、以及 URL scheme 模糊测试——请参考 MASTG-TEST-0075 测试条目。其中介绍的思路可以直接迁移到 UIActivity 接收场景：

• 用 Frida 的 ObjC 方法观察脚本（如observeSomething("*[* *openURL*]")）批量列出所有相关方法；
• 对收到的 URL 做输入模糊测试，并在/private/var/mobile/Library/Logs/CrashReporter检查.ips崩溃报告；
• 注意检查应用是否仍在使用application:handleOpenURL:等已废弃方法。

测试要点与安全提醒

• 校验输入来源：关注UIApplicationOpenURLOptionsSourceApplicationKey，确认应用是否校验了投递方（例如上述案例中的com.apple.sharingd），若任意来源均可投递，则需评估恶意文件风险。
• 关注文件生命周期：确认应用是否及时清理Documents/Inbox/中的文件；残留文件可能构成数据存储层面的问题。
• 畸形输入与模糊测试：除了正常文件，应使用畸形文件与 fuzz 载荷触发处理逻辑，观察是否崩溃或产生异常行为。
• 无源码时保持系统方法：先 hook 明确入口，再按方法名模式（move/copy/remove等）逐步追踪，即可在不接触源码的情况下还原处理链路。

延伸阅读

• MASTG-KNOW-0081：UIActivity Sharing 接收侧完整机制
• MASTG-TECH-0058：应用包与 Info.plist 静态分析
• MASTG-TEST-0075：自定义 URL scheme 测试（含模糊测试）
• MASTG-TOOL-0039：Frida 在 iOS 上的安装与使用

• 文档
• 教程
• 网络安全