问题描述
您遇到了一个问题：使用 Fiddler 或 Charles Proxy 截获 Android 应用的 HTTPS 请求（例如登录 API）失败。这在没有root设备的情况下更为困难，因为在 Android 7 及以上版本中，未经修改的应用通过这些代理工具拦截 HTTPS 流量变得非常困难。
解决方案
方案1 – 使用已经 root 的设备
步骤1: 安装 Fiddler/Charles Root CA证书
由于您的设备已经被 root，可以手动安装 Fiddler 或 Charles 服务器的根CA证书以进行 SSL 日志捕获。请参考以下链接详细操作：
– 在 Android 中配置 Fiddler
– 特别注意第二部分内容，此部分解释了如何为 Android 设备安装Fiddler的证书。
– 确保安装Fiddler时启用了 “CertMaker for iOS and Android” 扩展程序。
步骤2: 验证工具配置
使用上述方法成功捕获 HTTPS 请求后，即可验证 Fiddler 是否正确配置。您应该能够访问诸如 https://valid-isrgrootx1.letsencrypt.org/ 这样的网站而未遇到错误。
方案2 – 证书绕过
如果步骤1不起作用或您需要进一步的确认，请尝试如下方法：
步骤3: 检查应用使用是否包含证书pinning
一些应用会通过证书 pinning 技术防范类似情况。这意味着它会验证服务器发出请求时使用的证书与预定义值严格匹配。
步骤4: 使用 Frida+Objection 或 (ed)Xposed+TrustMeAlready 插件尝试绕过证书检查
如果上述验证显示应用确实使用了标准的 SSL/TLS pinning 机制，您可以考虑使用上述插件进行绕过。这通常涉及复杂的步骤和高级技术知识。
方案3 – 检查应用内部实现
鉴于您在问题描述中提到应用使用了原生库（native lib），可能是其部分功能并未通过标准 Android 流程进行网络请求调用，而是直接使用了底层接口或自定义 HTTPS 客户端。这种情况下，需要更深入的逆向工程来找到实际发送请求的部分代码，并可能还需要采用其他高级反调试和反汇编技术。
步骤5: 使用第三方工具分析应用
使用 ARM 逆向工程工具集（如 IDA Pro、Apktool），进行静态或动态分析以了解应用如何处理网络通信，尤其是在涉及加密通信部分。虽然这些工具并不常用且操作相对复杂，但在某些情况下它们能够帮助您找到真正的请求源。
结论
上述方案虽能提供一定解决路径，但针对具体问题可能需要结合实际应用的具体状况灵活选择方法，并做好充分准备和相应的技术研究工作。希望以上建议对您有所帮助！如遇困难可参考相关论坛和技术社区获取更多指导和支持。