APP攻防3：抓包突破实战-Frida-Hook-Xposed与证书校验绕过

从零开始理解 App 抓包突破：Frida、Hook、Xposed 与证书校验绕过实战

学习自B站小迪安全
移动端安全测试最常见的困境不是"找不到漏洞"，而是代理配好了，却一个数据包都抓不到。本文从零基础出发：先讲清中间人抓包为什么会失败、App 有哪些防护手段，再给出四个可以直接照做、复制粘贴就能跑的操作方案（Frida + r0capture、Frida + Hook 脚本 + Burp、客户端证书导入、Xposed + SSL 模块），最后附排查清单与完整参考链接。

一、开始之前：前置知识与工具清单

1.1 前置知识（仅列要点）

HTTP / HTTPS 基础：请求行、请求头、响应码；HTTPS = HTTP + TLS 加密层。
TLS 握手机制：客户端验证服务端证书（单向）、双方互验证书（双向）的基本流程。
CA 证书与信任链：抓包工具（Burp Suite、Charles、Fiddler）会自签一张根 CA；设备只有信任它，流量才能被解密。
中间人（MITM）抓包原理：把设备流量导向代理，代理"解密—查看—再加密转发"。
SSL Pinning（证书绑定）：App 在代码或配置文件里写死服务端证书/公钥指纹，指纹不符即断连。
代理与 VPN 的区别：代理只接管"显式走代理"的应用层流量；VPN 在系统层接管全部流量。
Android 系统基础：APK 安装包结构、adb 调试桥、模拟器与真机的差异、Android 7.0 之后用户证书默认不被 App 信任这一关键变化。
Linux 命令行基础：cd、ls、chmod、ps、grep 的用法（Frida 部署全程在 adb shell 里操作）。
JavaScript 基础概念：function、return、Java.perform() 这类写法能读懂即可。
Python 基础：会安装依赖、会跑脚本（r0capture 就是 Python 脚本）。

1.2 工具清单（仅列要点）

类别	工具	用途
抓包代理	Burp Suite	中间人抓包、改包、重放
抓包代理（备选）	Charles / Fiddler	同类工具，界面更轻
抓包分析	Wireshark	分析 r0capture 导出的 pcap 原始流量
动态插桩	Frida / frida-tools / frida-server	Java 层与 Native 层 Hook
通用抓包脚本	r0capture	无视证书校验的"通杀"抓包脚本
Hook 脚本库	FridaScripts	现成的 SSL Pinning 绕过脚本集
Hook 框架	Xposed（XP 框架）	系统级 Hook，配合 SSL 模块绕过单向校验
模拟器	夜神 / 逍遥 / 雷电	无 ARM 架构，需装 x86 版 frida-server
真机	建议可 root	ARM 架构，成功率最高
分析平台	MobSF	静态 + 动态自动化分析框架
分析环境	Mobexler	预装全套移动安全工具的定制虚拟机
调试桥	adb	传文件、装证书、起服务、端口转发
移动端证书绕过（iOS）	SSL Kill Switch 2	iOS 越狱环境下的 SSL Pinning 绕过
运行环境	Python 3	跑 r0capture 等脚本

二、先建立整体认知：移动端攻防的三个层面

移动端安全测试并不是"装个 Burp 就抓包"。整体上它是三个递进的层面：

App 攻防
├── ① 资产收集
│   ├── 内在提取 —— 从安装包内部挖资产
│   │   ├── 静态：反编译读代码、读资源、读配置
│   │   └── 动态：运行时 Hook，抓取内存中的密钥、令牌、接口
│   └── 外在抓包 —— 从网络流量上截资产
│       ├── 反模拟器
│       ├── 反代理 VPN
│       └── 反证书校验
├── ② 逆向工程
│   └── 反编译 & 删验证 & 重打包 & 静态动态自动化测试
└── ③ 渗透测试
    └── 拿到完整流量后的接口测试、逻辑漏洞、越权、支付篡改

理解这张图的价值在于：它决定了你的工作顺序。抓不到包时不要盲目换工具，而应先判断卡在①的哪一环——是反模拟器、反代理、还是反证书校验；确认之后再决定用真机、用 Hook、还是走④逆向删代码的路子。

外在抓包这一环，是本篇的全部内容。

三、抓包为什么失败：把问题收敛成五种

设置了代理却抓不到包，原因可以收敛为两类共五种：

3.1 没有限制过滤的抓包问题（你自己的配置问题）

序号	现象	原因
1	抓不到	抓包工具的证书没配置好（未安装、未信任、或受 Android 7+ 用户证书限制影响）
2	抓不到	App 走的不是 HTTP/HTTPS 协议（自研二进制协议、非标端口、纯 Socket）

3.2 有限制过滤的抓包问题（App 的主动防护）

序号	现象	原因
3	抓不到	反模拟器调试
4	抓不到	反代理 / 反 VPN
5	抓不到	反证书校验（SSL Pinning）

3.3 推荐的排查顺序

不要一上来就怀疑目标在做对抗——先排除自己的问题：

证书是否真的装好了、且被系统信任（Android 7+ 要特别注意）；
流量是否真的走了 HTTP/HTTPS（用 Wireshark 看有没有 TLS 握手）；
换真机验证是否仍抓不到 → 怀疑反模拟器；
用 Frida 挂一个 SSL Pinning 绕过脚本再看 → 怀疑反证书校验；
用 Postern / Proxifier 强制转发再看 → 怀疑反代理 VPN。

四、核心概念拆解：四种对抗手段到底在防什么

4.1 中间人抓包的工作机制

手机 WLAN 高级设置里把代理指向 <攻击机IP>:8080；
Burp Suite 监听该端口，收到客户端的 CONNECT host:443 后，动态签发一张该域名的假证书；
Burp 对客户端扮演"服务端"，对真实服务端扮演"客户端"，从而把 TLS 拆成两段；
客户端要能接受那张假证书 → 前提是客户端信任了 Burp 的根 CA。

失败点就出在第 4 步——而 App 的三种防护，本质上都是针对这一步或绕过代理这一动作。

4.2 单向校验 vs 双向校验

模式	校验方向	说明	应对
单向校验	客户端 → 服务端	客户端只校验服务端证书。App 内置/固定服务端证书指纹，导致 Burp 假证书被拒	XP 框架 + SSL 模块 Hook，或 Frida 绕过，或逆向删代码重打包
双向校验	双向互验	客户端校验服务端证书的同时，服务端也要校验客户端持有的证书。App 内部打包了一份客户端证书（`.p12` / `.bks` / `.pfx` 等）	必须先提取出客户端证书及其私钥，导入 Burp 才能完成握手

理解要点：单向校验是"客户端不信任你"，双向校验是"客户端和服务器互相都不信任你"。后者必须解决身份凭证问题，光绕过校验代码是没用的。

4.3 反模拟器

原理：通过检测模拟器特征（特定文件存在、CPU 型号、传感器数量与读数、IMEI/IMSI 规律、Build 属性、无基带等）判断运行环境，一旦命中即拒绝运行或拒绝联网。
绕过：
1. 换真机（最直接，成功率最高）；
2. 模拟器伪装真机（改机型、改 Build 属性、改传感器）；
3. 逆向定位检测代码 → 删除或强制改写 → 重打包。

4.4 反代理 / 反 VPN

原理：读取系统代理设置（System.getProperty("http.proxyHost")）、读取网络接口判断是否处于 VPN、或直接使用不走代理的底层 Socket 发送请求。
典型表现：
- 配了代理 → 直接无法访问，提示网络异常；
- 连了 VPN → 直接无法访问；
- 配了代理 → 一切正常，就是一个包都没有（最隐蔽：流量根本没走代理）。
绕过：
1. 手机端用 Postern 在 App 层接管流量再转发到 PC 代理；
2. PC 端用 Proxifier 强制指定模拟器进程走代理；
3. 逆向删代码重打包。

4.5 证书绑定（SSL Pinning）与"找 Hook 点"

当常规中间人完全失效时，就需要 Hook 抓包：不去硬解 TLS，而是在加解密函数的出入口直接截获明文。

核心技术问题是"在哪里下钩子（hook 点）"，而答案取决于 SSL 类库的来源，分两种情形：

如何确定 SSL 库的关键 API（即 hook 点）
├── 情形一：协议使用了系统中的 SSL 类库
│   ├── Hook 点分 java 与 native 两类
│   └── 直接参考 r0capture 的现成实现
└── 情形二：协议使用了自己集成的 SSL 类库（如部分加固 App、自研协议）
    └── 需先定位其自实现的 SSL 关键 API，再确定 hook 点

HOOK 抓包的两条主线：

抓 HTTP 包 —— 在网络收发函数的调用点下钩子；Frida 是通用实现，r0capture 是成熟的现成脚本。
抓 HTTPS 明文（或其他应用层协议 + SSL 框架） —— 找到 SSL 库的关键 API（明文读写函数），在其入口或出口读取明文。

这正是 r0capture 的价值所在——它把上面两种情形的基础场景都覆盖了。

五、Frida 是什么，以及它的能力边界

Frida 是一款易用的跨平台 Hook 工具，从 Java 层到 Native 层的 Hook 都可以完成。本质上它是一种动态插桩工具：把代码注入到原生 App 的内存空间中，在运行时监视和修改行为。

覆盖平台：Windows、macOS、Linux、Android、iOS 全平台。
能力定位：因为它工作在内存层面，所以不受加固影响——整体壳、二代壳、VMP 壳都不改变"运行时必然解密成明文"这一事实。

本文使用的测试环境组合：

Python 3 + 夜神模拟器 + frida-server + r0capture + Burp Suite + Wireshark

六、环境准备：把 Frida 从电脑装到模拟器

这一节是后续所有方案的地基，必须一步不落地做完。

6.1 本地安装 Frida

pip install frida
pip install frida-tools

验证安装：

frida --version
frida-ps --version

6.2 在模拟器/真机安装 frida-server

关键前提：frida-server 的版本必须与本机 frida 版本完全一致。 版本不一致会出现 Failed to connect 或协议不匹配的报错。

下载地址（选择与设备架构对应的 frida-server-<版本>-android-<架构> 文件）：

https://github.com/frida/frida/releases

如何确定架构？

# 查看设备 CPU 架构
adb shell getprop ro.product.cpu.abi

运行环境	典型架构	选择文件
真机	`arm64-v8a` / `armeabi-v7a`	ARM 版本（注意位数：32 位选 `arm`，64 位选 `arm64`）
x86 模拟器（夜神/逍遥等）	`x86` / `x86_64`	无 ARM 的 x86 版本

一个高频坑：模拟器上装了 ARM 版 frida-server，进程能起来但始终连不上——这就是架构选错了。

推送并启动：

# 1. 把 frida-server 推进设备
adb push frida-server /data/local/tmp/

# 2. 进入 shell
adb shell
cd /data/local/tmp/

# 3. 赋予执行权限
chmod 777 frida-server

# 4. 运行（前台运行，不要关掉这个窗口）
./frida-server

# 5. 另开一个窗口验证进程是否存活
adb shell "ps | grep frida"

提示：./frida-server 是前台阻塞运行的，Ctrl+C 会终止它，之后所有 Hook 都会失败。调试期间建议保持这个终端窗口不动。

6.3 端口转发与连通性验证

Frida 默认监听设备上的 27042 端口，需要把它转发到本地：

adb forward tcp:27042 tcp:27042

验证是否连通：

# -U 表示连接 USB / 本地设备
frida-ps -U

# -R 表示连接远程设备（需配合 frida-server -l 0.0.0.0 使用）
frida-ps -R

frida-ps -U 能打印出设备上的进程列表，说明环境就绪。若报 unable to connect to remote frida-server，按以下顺序检查：

frida-server 是否还在前台运行（ps | grep frida）；
adb forward 是否还在（adb forward --list）；
版本是否一致（frida --version vs frida-server 文件名中的版本号）；
架构是否选错。

6.4 获取目标 App 的包名

# 方式一：直接在 shell 里列目录
adb shell "ls /data/data"

# 方式二：用 APK 资源查看类工具打开 APK，读取 manifest 中的 package 属性

包名形如 com.xxx.yyy，是后续所有 frida -U -f <包名> 命令的必要参数。

七、实操方案一：Frida + r0capture + Wireshark（推荐首选）

适用场景：双向证书认证、有加固、抓不到任何包的"硬骨头"。

r0capture 的能力特性：

仅限 Android 平台，实测在 Android 7、8、9、10、11 可用；
无视所有证书校验或绑定——完全不用考虑证书的事情；
通杀 TCP/IP 四层模型中应用层的全部协议：HTTP、WebSocket、FTP、XMPP、IMAP、SMTP、Protobuf 等，以及它们的 SSL 版本；
通杀所有应用层框架：HttpUrlConnection、OkHttp 1/3/4、Retrofit、Volley 等；
无视加固——整体壳、二代壳、VMP 壳都不影响，不需要脱壳。

项目地址：https://github.com/r0ysue/r0capture

操作步骤：

# === 设备侧 ===
adb shell
cd /data/local/tmp/
./frida-server                     # 保持运行

# === 电脑侧（另开一个终端）===
# 查看包名
adb shell "ls /data/data"

# 以 spawn 方式启动目标 App 并抓包，导出为 pcap
python r0capture.py -U -f <目标包名> -p result.pcap

参数说明：

参数	含义
`-U`	连接 USB / 本地设备
`-f <包名>`	spawn 模式启动指定包名（推荐：能在 App 最早期就注入成功，避免漏包）
`-p <文件>`	把抓到的流量导出为 pcap 文件
（不写 `-p`）	直接把明文打印到终端

分析：用 Wireshark 打开 result.pcap，即可看到明文的应用层协议内容。

本方案的核心优势：它不依赖系统代理、不依赖信任证书，因此天然绕过了反代理、反 VPN、反证书校验三重防护。遇到完全抓不到包的目标，直接上这一套。

八、实操方案二：Frida + Hook 脚本 + Burp Suite

适用场景：单向 SSL Pinning，希望继续用 Burp 的改包、重放功能（r0capture 只导出 pcap，不方便交互式改包）。

脚本来源：https://github.com/apkunpacker/FridaScripts

# === 设备侧 ===
adb shell
cd /data/local/tmp/
./frida-server                     # 保持运行

# === 电脑侧 ===
# -U 连设备，-f 指定包名，-l 载入 Hook 脚本
frida -U -f <目标包名> -l ssl_bypass.js

参数说明：

参数	含义
`-U`	连接 USB / 本地设备
`-f <包名>`	启动（spawn）指定应用
`-l <脚本>`	载入本地 JavaScript Hook 脚本
`-o <文件>`	载入脚本并把输出写入文件（可选）

Hook 脚本在做什么（理解性说明）：它会在运行时替换掉 SSL 校验相关方法的实现，让 checkServerTrusted、getAcceptedIssuers 这类函数直接返回"通过"或空结果，使 App 认为证书没问题。

配合 Burp 使用：设备 WLAN 代理指向 <攻击机IP>:8080，Burp 监听 8080。脚本生效后，Burp 中即可看到完整明文请求。

常见问题：

脚本报 ClassNotFoundException → 目标 App 的校验逻辑不在脚本覆盖的类里，需要换脚本或用 r0capture；
App 一启动就闪退 → App 有反调试/反 Hook 检测，改用 r0capture，或走逆向删代码的路子。

九、实操方案三：导入客户端证书（破解双向认证）

适用场景：App 双向认证，且能够反编译、包内确实存在客户端证书文件。

这是唯一能"优雅"解决双向认证的思路——不是绕过校验，而是以合法客户端身份参与握手。

整体步骤：

解压 APK，取出其中的客户端证书文件；
反编译，定位证书文件的密钥/口令；
把证书导入 Burp，即可完成双向握手。

9.1 解压并定位证书文件

APK 本质是 ZIP，直接解压即可：

mkdir apk_extracted
unzip target.apk -d apk_extracted

证书通常打包在 assets/ 或 res/raw/ 下，常见后缀：

find apk_extracted -type f \( -name "*.p12" -o -name "*.pfx" -o -name "*.bks" \
  -o -name "*.jks" -o -name "*.keystore" -o -name "*.cer" -o -name "*.crt" -o -name "*.pem" \)

9.2 反编译并找出密钥（口令）

用反编译工具（如 jadx-gui）打开 APK，全局搜索证书文件名，或者直接搜关键 API：

# 在反编译出的 smali / 源码目录中搜索
grep -rn "\.p12\|\.bks\|\.pfx" .
grep -rni "keystore\|setCertificate\|KeyStore.getInstance\|KeyManagerFactory" .

重点关注：KeyStore.load(InputStream, char[] password) 这类调用的第二个参数——它往往是一个硬编码字符串常量。

// 典型模式（示意）
KeyStore ks = KeyStore.getInstance("PKCS12");
ks.load(getAssets().open("client.p12"), "123456".toCharArray());
//                                       ^^^^^^ 这就是要找的口令

也可以用 strings 快速碰运气：

strings apk_extracted/assets/client.p12 | head -20
# 或在 so 库中找硬编码口令
strings apk_extracted/lib/arm64-v8a/*.so | grep -i "pass\|p12\|bks"

9.3 转换为 Burp 可用格式并导入

Burp 支持导入 PKCS#12（.p12）。若拿到的是 Java KeyStore（.jks / .bks），先转换：

# .jks -> .p12
keytool -importkeystore \
  -srckeystore client.jks -srcstoretype JKS -srcstorepass <原口令> \
  -destkeystore client.p12 -deststoretype PKCS12 -deststorepass <新口令>

# 校验证书内容是否可读
keytool -list -v -keystore client.p12 -storetype PKCS12 -storepass <口令>

# 如需查看/导出为 PEM
openssl pkcs12 -in client.p12 -nodes -out client.pem -passin pass:<口令>

Burp 侧配置：

Proxy → Options → TLS → Client TLS certificates → Add
  Destination host : <目标域名>
  Destination port : 443
  Certificate file : client.p12
  Certificate password : <口令>

配置完成后，再访问该域名，Burp 就会在 TLS 握手中使用这张客户端证书。

若无法反编译（有壳）：先用脱壳工具脱壳，或改用方案一 r0capture——它直接读明文，压根不参与证书握手，天然免疫双向认证。

十、iOS 端：SSL Kill Switch 2

iOS 越狱环境下绕过 SSL Pinning 的标准工具。

使用教程：https://testerhome.com/topics/17249
项目下载：https://github.com/nabla-c0d3/ssl-kill-switch2/releases

原理：在系统层面 Hook iOS 的 TLS 校验函数（SSLHandshake、SecTrustEvaluate 等），使任意证书均被判定为可信，从而让中间人代理正常工作。

十一、实操方案四：Xposed + SSL 模块 + Burp Suite

适用场景：单向证书校验，尤其是游戏类 App——它们往往只做了单向校验，且不想脱壳。

环境搭建：

夜神模拟器：直接在应用市场下载 Xposed 安装器，安装后激活即可（需重启生效）；
逍遥模拟器：安装 Xposed 框架并激活。

操作步骤：

模拟器中安装并激活 Xposed 框架；
在 Xposed 中启用 SSL 绕过模块（如 JustTrustMe 一类的模块），并勾选目标 App 的作用域；
重启目标 App；
设备 WLAN 代理指向 <攻击机IP>:8080；
在 Burp 中观察流量。

方案对比：

方案	适用校验类型	是否需脱壳	优点	缺点
Xposed + SSL 模块	单向	否	配置一次长期有效，无需每次起脚本	依赖框架环境，部分 App 有反 Xposed 检测
Frida + Hook 脚本	单向为主	否	灵活，可现场改脚本	每次都要起 frida-server
Frida + r0capture	单向 + 双向	否	通杀协议与框架，无视加固	只出 pcap，不便交互改包
导入客户端证书	双向	需能反编译	最"正规"，握手完全合法	依赖包内有证书且能拿到口令
逆向删代码重打包	全部	视情况	一劳永逸	工作量大，可能破坏签名校验

游戏类 App 的典型路径：先试 Xposed + SSL 模块（成本最低）；不通就换 r0capture。

十二、辅助识别：先看清目标再动手

在动手绕过之前，用自动化平台先摸清目标的底细，能省下大量时间。

12.1 MobSF（Mobile Security Framework）

定位：自动化的一体化移动应用渗透测试、恶意软件分析和安全评估框架，支持 Android / iOS / Windows。

能力：

同时执行静态分析与动态分析；
支持移动应用二进制文件：APK、XAPK、IPA、APPX，以及压缩后的源代码；
提供 REST API，可与 CI/CD 或 DevSecOps 流水线无缝集成；
动态分析器支持运行时安全评估与交互式插桩测试。

典型用途：上传 APK 后，直接获得权限清单、导出组件、硬编码密钥、证书文件位置、第三方 SDK 列表等——往往能直接发现"客户端证书在哪个目录""密钥硬编码在哪里"，为方案三铺路。

12.2 Mobexler

定位：基于 Elementary OS 的定制虚拟机，专门用于 Android 与 iOS 应用的渗透测试。

特点：预装了各种开源工具、脚本，以及移动安全测试所需的各类软件，开箱即用，省去环境搭建成本。

官网：https://mobexler.com/

十三、抓不到包时的排查清单

按顺序执行，每步都能把问题范围收窄一半：

步骤	动作	若仍失败说明
1	确认 Burp 证书已安装且被信任（Android 7+ 需将证书装入系统证书目录，或用 Magisk 类模块）	问题不在证书信任
2	用 Wireshark 抓设备网卡，看是否有 TLS 握手	可能不是 HTTP/HTTPS 协议
3	换真机重试	说明命中了反模拟器检测
4	`frida-ps -U` 验证 Frida 通路，再挂 SSL 绕过脚本	说明命中了 SSL Pinning
5	用 Postern（手机端）/ Proxifier（PC 端）强制转发	说明命中了反代理/反 VPN
6	上 r0capture	若它都抓不到，说明是自研加密协议，需进入逆向分析

Android 7+ 用户证书问题补充说明（这是"抓不到包"最高频的原因）：

Android 7.0（Nougat）起，App 默认不再信任用户手动安装的 CA 证书，只信任系统证书目录 /system/etc/security/cacerts/ 下的证书。因此把 Burp CA 装成"用户证书"往往不生效。三种解法：

Magisk 模块法：用 Magisk 模块把用户证书挂载进系统证书目录（如 MagiskTrustUserCerts）；
Root 手动法：adb root / Magisk 环境下把证书 hash 化后推入 /system/etc/security/cacerts/，并赋权 644，重启设备；
Frida 法：Hook 网络安全性配置，使 App 接受用户证书。

# 手动法示例：计算证书 hash 名并推入系统目录
openssl x509 -inform PEM -subject_hash_old -in burp_ca.pem | head -1
# 假设输出 a1b2c3d4，则：
cp burp_ca.pem a1b2c3d4.0
adb root
adb remount
adb push a1b2c3d4.0 /system/etc/security/cacerts/
adb shell "chmod 644 /system/etc/security/cacerts/a1b2c3d4.0"
adb reboot

十四、安全与合规边界

本文所有技术内容均仅适用于你拥有合法授权的测试环境——包括你自己的设备、你所在组织书面授权的目标、以及公开的测试靶场。

绕过证书校验、Hook、逆向重打包，都属于对软件运行时的主动干预；对未授权目标实施，可能违反《网络安全法》《数据安全法》及目标平台的服务条款。
提取到的客户端证书、密钥、令牌属于凭据类敏感信息，必须妥善保管，测试结束后按流程销毁。
抓取到的业务流量可能包含他人个人信息，处理时须遵守最小必要原则。

十五、参考链接

工具与项目

Frida 多平台二进制发布（frida-server 下载）：https://github.com/frida/frida/releases
r0capture（通杀抓包脚本）：https://github.com/r0ysue/r0capture
FridaScripts（Hook 脚本集合）：https://github.com/apkunpacker/FridaScripts
SSL Kill Switch 2（iOS，项目下载）：https://github.com/nabla-c0d3/ssl-kill-switch2/releases
SSL Kill Switch 2（iOS，使用教程）：https://testerhome.com/topics/17249
Mobexler 定制渗透测试虚拟机：https://mobexler.com/

资料索引

配套资料（录像、素材、工具包等）下载地址：https://docs.qq.com/doc/DQ3Z6RkNpaUtMcEFr

附：命令速查卡

# —— 环境安装 ——
pip install frida
pip install frida-tools

# —— 架构判断 ——
adb shell getprop ro.product.cpu.abi

# —— 部署 frida-server ——
adb push frida-server /data/local/tmp/
adb shell
cd /data/local/tmp/
chmod 777 frida-server
./frida-server
adb shell "ps | grep frida"

# —— 端口转发与连通性 ——
adb forward tcp:27042 tcp:27042
frida-ps -U
frida-ps -R

# —— 包名获取 ——
adb shell "ls /data/data"

# —— 方案一：r0capture ——
python r0capture.py -U -f <目标包名> -p result.pcap

# —— 方案二：Frida + Hook 脚本 ——
frida -U -f <目标包名> -l ssl_bypass.js

# —— 方案三：证书提取与转换 ——
unzip target.apk -d apk_extracted
keytool -importkeystore -srckeystore client.jks -srcstoretype JKS -srcstorepass <口令> \
        -destkeystore client.p12 -deststoretype PKCS12 -deststorepass <口令>
keytool -list -v -keystore client.p12 -storetype PKCS12 -storepass <口令>

# —— Android 7+ 系统证书安装 ——
openssl x509 -inform PEM -subject_hash_old -in burp_ca.pem | head -1
adb root && adb remount
adb push <hash>.0 /system/etc/security/cacerts/
adb shell "chmod 644 /system/etc/security/cacerts/<hash>.0"
adb reboot

posted @ 2026-09-21 16:15 xsec 阅读(52) 评论(0) 收藏举报

刷新页面返回顶部

xsec - 去码头搞点薯条