Charles抓包鸿蒙系统显示unknown？

Question

在使用Charles对鸿蒙系统（HarmonyOS）应用进行抓包时，常出现HTTPS请求显示为“unknown”的问题。该现象多因HarmonyOS默认启用更强的SSL/TLS安全策略，导致Charles的SSL代理证书无法被应用信任。即使已安装Charles证书，部分系统或应用仍会通过证书固定（Certificate Pinning）或网络安全性配置限制中间人代理，从而拒绝解密流量。此外，鸿蒙对后台应用网络访问也有更严格的管控，可能影响代理正常工作。此问题直接影响接口调试与数据监听，是移动端抓包中的典型难题。

Answer 1

使用Charles对鸿蒙系统（HarmonyOS）应用进行HTTPS抓包的深度解析与解决方案

1. 问题背景与现象描述

在移动端接口调试过程中，开发者常使用Charles Proxy作为抓包工具，以监控HTTP/HTTPS请求。然而，在针对华为鸿蒙系统（HarmonyOS）设备上的应用进行抓包时，频繁出现HTTPS请求显示为“unknown”的现象。

该问题的核心表现为：尽管已正确配置代理、安装并信任Charles根证书，但部分HTTPS流量仍无法解密，仅显示为加密流或标记为“unknown”，导致无法查看明文请求与响应内容。

• 典型场景：App内API调用、WebView加载、后台服务通信等HTTPS请求均受影响。
• 影响范围：涉及自研App、第三方SDK、混合开发框架（如H5+原生）等多种技术栈。

2. 技术成因分析：从表层到深层

造成此问题的技术原因可划分为多个层级，逐步深入如下：

1. 系统级SSL/TLS策略强化：HarmonyOS基于微内核架构设计，增强了网络安全机制，默认启用更严格的TLS版本（如TLS 1.3）和加密套件限制，拒绝弱安全性连接。
2. 用户证书信任链隔离：即使用户手动安装了Charles的CA证书（.pem/.crt），系统可能未将其纳入应用运行时的信任锚点，尤其在高安全模式下。
3. 应用层证书固定（Certificate Pinning）：多数金融类、支付类或敏感数据交互App采用OkHttp、Retrofit等库实现SSL Pinning，直接绑定服务器公钥或证书指纹，绕过系统信任链验证。
4. 网络安全性配置（Network Security Config）：AndroidManifest.xml中定义的<network-security-config>被HarmonyOS继承并强化，明确禁止用户证书参与校验。
5. 后台任务网络访问管控：HarmonyOS对非前台应用实施网络限流、延迟或断连策略，可能导致代理会话中断，影响持续抓包。

3. 常见排查流程与诊断方法

为定位具体阻断环节，建议按以下流程执行：

步骤	操作内容	预期结果	异常处理方向
1	确认设备Wi-Fi代理指向Charles所在主机IP及端口（默认8888）	HTTP明文请求可见	检查防火墙、同一局域网连通性
2	通过浏览器访问chls.pro/ssl下载并安装证书	系统提示“已安装”且位于“受信任的凭据”中	尝试重启、清除证书缓存
3	测试访问通用HTTPS网站（如https://httpbin.org/get）	成功解密流量	说明系统级代理可行，问题出在特定App
4	启动目标App，观察是否出现“unknown”	若仅该App异常，则进入应用层分析	怀疑存在Pinning或自定义TrustManager

4. 解决方案矩阵：多维度突破限制

根据问题根源不同，需采取组合式应对策略：

# 示例：修改模拟器或已Root设备的系统证书存储（仅限测试环境）
# 将Charles证书转换为系统格式
openssl x509 -in charles-proxy-ssl-proxying-certificate.pem -inform PEM -outform DER -out charles.cer
adb push charles.cer /sdcard/
su
mv /sdcard/charles.cer /system/etc/security/cacerts/<HASH>.0
chmod 644 /system/etc/security/cacerts/<HASH>.0

• 动态Hook方案：利用Xposed框架或Frida注入，拦截OkHttpClient.Builder.certificatePinner()方法，禁用Pinning逻辑。
• 重打包APK/HAP：反编译HAP包，修改network_security_config.xml，添加<trust-anchors><certificates src="user"/></trust-anchors>允许用户证书。
• 使用支持HarmonyOS的专用代理工具：如PacketCapture（无需Root，自动处理证书）、Proxyman（配合虚拟机桥接）等替代方案。
• 开启开发者选项中的“强制使用代理”模式：部分鸿蒙版本提供调试开关，强制所有网络走指定代理。

5. 架构级思考：安全与调试的平衡之道

随着操作系统安全模型演进，传统中间人代理方式面临根本性挑战。鸿蒙系统的分布式安全架构强调端到端可信链，使得任何未经签名的中间节点难以介入通信过程。

graph TD A[客户端App] -->|原始HTTPS| B(目标Server) C[Charles Proxy] -->|MITM| A C -->|伪造证书| D[Charles CA证书] D -->|需被系统&App双重信任| E[HarmonyOS Trust Store] E -->|受限于Pinning/NscConfig| F[证书验证失败] G[解决方案] --> H[Frida Hook] G --> I[系统证书植入] G --> J[流量镜像至可控环境]

未来趋势表明，单纯依赖本地代理抓包的方式将逐渐被更高级的调试体系取代，例如：

• 集成日志上报通道，通过内部接口暴露关键请求信息；
• 构建Mock Server + API Gateway调试平台，脱离真实终端依赖；
• 利用HarmonyOS DevEco Studio内置的网络分析器进行可视化追踪。