weeknessback-ben/ios-flutter-ssl-bypass

# iOS SSL bypass + Burp 重定向工具包 这是一个基于 Frida 的一体化工具，用于将越狱 iOS 应用的 HTTPS 流量引入到 Burp Suite 中，即使在以下情况： - 应用针对自身硬编码的锚点集进行了证书绑定（例如调用 `SecTrustSetAnchorCertificatesOnly`），因此仅在 iOS “设置”应用中信任 Burp 的 CA 是不够的，**和/或** - 应用的网络栈完全忽略了 iOS 系统的 HTTP/HTTPS 代理设置 （已确认 Flutter/Dart 的 `dart:io` 存在此问题 —— 基于 Safari/CFNetwork 的 流量能正常识别系统代理，而 Dart 自带的 `HttpClient` 则不行），因此任何 VPN / `pf` 重定向 / Wi-Fi 代理配置都无法捕获该应用的流量。 它在目标应用自身的进程中结合了两个 Frida hook： 1. **SecTrust bypass** —— hook `Security` 模块中的 `SecTrustEvaluateWithError`、 `SecTrustGetTrustResult` 以及旧版的 `SecTrustEvaluate`，并强制它们返回成功。 2. **Burp 重定向** —— hook `libsystem_kernel.dylib` 中的 `connect()`，并在应用 尝试连接配置端口（默认为 80/443）时，将目标 `sockaddr_in` 原地重写为 Burp 的 IP:port。 完整的架构说明（每个 hook 的存在原因、时序图、字节级的 sockaddr 结构、设计权衡）：**[`docs/ARCHITECTURE.md`](docs/ARCHITECTURE.md)**。 文件： - `ios_ssl_bypass_redirect.py` —— CLI 驱动程序（SSH 检查、frida-server 检查/启动、SSH 隧道、Frida 启动+hook）。 - `ios_ssl_bypass_redirect.js` —— Frida hook 脚本（基于模板，由 `.py` 驱动；也支持手动编辑并通过 `frida -l` 独立加载，只需 先自行替换 `__TOKEN__` 占位符即可）。 ## 前置条件 针对每台设备 / Burp 实例设置一次 —— 本工具不会自动化这些步骤： 1. **已在设备上安装并完全信任 Burp 的 CA 证书。** 在设备的 Wi-Fi 代理（或本工具，仅限重定向模式）已通过 Burp 路由的情况下，在设备上的 Safari 浏览器中访问 `http://burp/cert`，安装 配置文件，然后前往 **设置 → 通用 → 关于本机 → 证书信任 设置**，并为 PortSwigger CA 启用完全信任。 2. **Burp 监听器已启用“Support invisible proxying”** (Proxy → Proxy settings → 编辑监听器 → Request handling)。在此重定向设置中没有 `CONNECT` 方法 —— Burp 会根据 ClientHello 中的 TLS SNI 来确定真实的上游主机。 3. **笔记本电脑上已安装 `frida-tools`**，且版本与设备上已运行/可安装的 `frida-server` 版本匹配（或兼容）。 `frida --version` 显示的主版本号应与针对该设备运行 `frida-ps` 返回的主版本号一致。 4. **笔记本电脑上已安装 `sshpass`** (`apt install sshpass`)。 5. 设备与 Burp/笔记本电脑之间需要存在可路由的网络路径 （处于同一 Wi-Fi 子网最为简单）。需要设备的 SSH 访问权限 —— 越狱 默认用户为 `mobile`，密码为 `alpine`，除非已更改，否则 `sudo`/root 密码同样为 `alpine`。 ## 基本用法 ``` python3 ios_ssl_bypass_redirect.py \ --device-ip 192.168.1.100 \ --package com.example.targetapp \ --burp-ip 192.168.1.50 --burp-port 8080 ``` 此操作会通过 SSH 检查设备，确保 `frida-server` 正在运行（如果未运行，则以 root 身份启动），打开本地 SSH 隧道以连接 `frida-server`， 安装两个 hook 全新启动应用，并恢复其运行。在使用应用时保持其运行；按 Ctrl+C 停止（会干净地关闭 SSH 隧道）。 ## 使用场景 **默认 —— 在 80/443 上进行 bypass + 重定向（常见情况）：** ``` python3 ios_ssl_bypass_redirect.py --device-ip 192.168.1.100 \ --package com.example.targetapp --burp-ip 192.168.1.50 ``` **仅重定向，无 SecTrust bypass** —— 应用未进行证书绑定，或者您已激活 其他 bypass 机制，仅需将流量路由至 Burp： ``` python3 ios_ssl_bypass_redirect.py --device-ip 192.168.1.100 \ --package com.example.app --burp-ip 192.168.1.50 --no-bypass ``` **仅 SecTrust bypass，无重定向** —— 应用已遵循 iOS 系统 代理（基于 CFNetwork/URLSession 的网络），因此将普通的 Wi-Fi 代理配置 指向 Burp 即可捕获流量，您只需处理证书绑定 bypass： ``` python3 ios_ssl_bypass_redirect.py --device-ip 192.168.1.100 \ --package com.example.app --burp-ip 192.168.1.50 --no-redirect ``` **非默认端口**（应用同时通过 TLS 与自定义端口上的内部服务进行通信，例如 8443）： ``` python3 ios_ssl_bypass_redirect.py --device-ip 192.168.1.100 \ --package com.example.app --burp-ip 192.168.1.50 --redirect-ports 80,443,8443 ``` **自定义 SSH 凭据 / 已在非默认端口上运行的 frida-server：** ``` python3 ios_ssl_bypass_redirect.py --device-ip 192.168.1.100 \ --device-user mobile --device-password hunter2 --root-password hunter2 \ --frida-port 27043 --local-port 27043 \ --package com.example.app --burp-ip 192.168.1.50 ``` **诊断 / 详细模式** —— 打印应用发出的每一次 `connect()`（不仅限于 被重定向的连接），并记录每次 `SecTrustEvaluateWithError` 调用在被强制修改前的*原始*返回值。这在流量未显示在 Burp 中，且您需要判断 hook 是否针对相关连接触发时非常有用： ``` python3 ios_ssl_bypass_redirect.py --device-ip 192.168.1.100 \ --package com.example.app --burp-ip 192.168.1.50 --verbose ``` ## 参数参考 | 参数 | 默认值 | 用途 | |---|---|---| | `--device-ip` | *(必填)* | iPhone IP (Wi-Fi 或 USB 中继) | | `--device-user` | `mobile` | SSH 用户 | | `--device-password` | `alpine` | SSH 密码 | | `--root-password` | 同 `--device-password` | 如果需要（重新）启动 frida-server，用于 `sudo` | | `--ssh-port` | `22` | | | `--frida-port` | `27042` | 设备本地的 frida-server 监听端口 | | `--local-port` | 同 `--frida-port` | SSH 隧道的本地端口 | | `--frida-server-path` | 自动检测 | 设备上 frida-server 的路径 | | `--package` | *(必填)* | 要启动的 bundle ID，例如 `com.example.targetapp` | | `--burp-ip` | *(必填)* | Burp 监听器地址 | | `--burp-port` | `8080` | Burp 监听器端口 | | `--redirect-ports` | `80,443` | 要重定向的端口逗号列表 | | `--no-redirect` | 关闭 | 禁用 connect() 重定向 hook | | `--no-bypass` | 关闭 | 禁用 SecTrust bypass hook | | `-v, --verbose` | 关闭 | 记录透传连接 + 原始 SecTrust 返回值 | ## 故障排除 - **`SSH check failed`** —— 验证 `--device-ip`/凭据，并确保设备与 笔记本电脑能在 `--ssh-port` 上互通（处于同一 Wi-Fi 子网最为简单； 开启了客户端隔离的跨子网 Wi-Fi 或 VLAN 划分会无声地丢弃这些 连接）。 - **`frida-server binary not found on device`** —— 自行安装/复制 与您的 `frida-tools` 版本匹配的 `frida-server` 构建版本（在笔记本上 检查 `frida --version`），或指定 `--frida-server-path`。 - **Hook 已安装，但在 Burp 中毫无显示**，尽管笔记本上的 `ss -tn` 显示 设备到 `--burp-ip:--burp-port` 存在带有排队数据的 `ESTABLISHED` 连接： - 加上 `--verbose` 重新运行。如果看到 `[SecTrustEvaluateWithError] original=1`，说明应用已成功信任 Burp 的证书（CA 信任设置 正确）—— 此时缺少历史记录并不是绑定或 重定向问题。 - 检查 Burp 的 **Dashboard → Event log**（所有级别，包含 Debug）以查看 目标主机 —— `... is using HTTP/2` 的调试信息确认 Burp 已完成 TLS 握手并识别了协议，即使 HTTP 历史记录中的请求/响应 与您预期的不符。 ## 已知限制 - 仅限 IPv4 (`AF_INET` sockaddr 解析) —— 重定向 hook 不支持 IPv6。 - 每次运行都会全新启动应用（从不附加到已运行的 实例） —— 这是刻意为之，在测试中，附加到正在运行的进程 可靠性较低。 - 不会在设备上安装或信任 Burp 的 CA，也不会开启 Burp 的“Support invisible proxying”设置 —— 这两者都是一次性手动设置 步骤（见前置条件）。

标签：Docker支持, Frida, iOS安全, SSL Pinning绕过, 云资产清单, 内存分配, 数据可视化, 流量劫持, 逆向工具, 逆向工程