AI 摘要（由 ChatGPT 总结生成）：
本文介绍了利用Clash进行透明代理的新方法，以解决一个授权APP的渗透问题。作者通过在手机上安装Clash Meta内核，并配置规则文件，实现了透明代理，避免了APP检测HTTP Proxy的问题。文章详细讲解了文件准备、食用步骤，并使用BurpSuite演示了成功抓包的过程。作者指出Clash的TUN模式支持自动设置全局路由，无需额外设置iptables规则。最后，文章提到了对该方法的一些玩法，如借助FRP实现远程抓包等。

前言

这个文章的起因是对一个十分“不友好”的授权 APP 做渗透，因个人手机上的测试工具比模拟器里的还全和强大（bushi），故该 APP 也将直接在本人物理设备上安装并做渗透。

手机在 WiFi 处设置 HTTP 代理后，将相应 APP 打开，直接来了个弹窗，说“设备环境异常，即将退出应用！”。对此早已见怪不怪，遂使用一些手段对该 APP 隐藏 Root 及相关环境特征。再打开 APP ，发现还是这个弹窗，结合过往对 APP 渗透的经验，猜测是将 HTTP Proxy 作为了检测的一环，便去 WiFi 处将 HTTP Proxy 取消，打开应用正常进入了。

由于在 WiFi 处直接设置 HTTP Proxy 会被应用检测并退出，接下来就是想到使用透明代理方式解决，本来考虑使用 DroidProxy 或命令编辑 iptables 规则去试一下，但突然间灵光一闪，本机我可以使用 Clash 的相关 Magisk 模块日常无感上网，且目前还没遇到过 APP 提示网络异常或不可用的问题，那岂不是也可以使用 Clash 做透明代理的解决方案的一种？于是，便有了这篇小记。

注：此处使用的是 Clash Core 版本！

文件准备

由于使用到 Clash Core，为了更多的可玩性以及支持 redir-host 代理方式，此处我选择的是 Clash Meta 内核，下载链接如下：

以及可能用到的 IP 地址规则库文件：

配置 Clash 的规则文件，文件命名成 config.yaml ，文件内容如下（使用 TUN 模式，注意更换规则文件中 IP 与端口）：

注：微信公众号中因复制替换原因，需将公众号中所给配置文件的小写 direct 手动改为大写的 DIRECT 。
#tproxy-port: 7890
bind-address: '*'
mixed-port: 7892
redir-port: 7893
allow-lan: true
mode: Global
log-level: silent
ipv6: false
external-controller: 0.0.0.0:9090

profile:
  store-selected: true
  store-fake-ip: false

tun:
  enable: true
  device: Meta
  stack: system #or gvisor
  dns-hijack:
    - 'any:53'
  auto-route: true #加上
  auto-detect-interface: true #加上

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: redir-host
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

proxies:
  - name: Proxy_HTTP
    # server 处修改为你的抓包软件设备的 IP
    server: 192.168.x.xxx
    # 抓包软件的端口
    port: 8080
    # 抓包软件的代理类型
    type: http

  - name: Proxy_Socks5
    server: 192.168.x.xxx
    port: 8080
    type: socks5
 
proxy-groups:

rules:
 - DOMAIN-SUFFIX,ip6-localhost,DIRECT
 - DOMAIN-SUFFIX,ip6-loopback,DIRECT
 - DOMAIN-SUFFIX,lan,DIRECT
 - DOMAIN-SUFFIX,localhost,DIRECT
 - IP-CIDR,0.0.0.0/8,DIRECT,no-resolve
 - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
 - IP-CIDR,100.64.0.0/10,DIRECT,no-resolve
 - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
 - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
 - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
 - IP-CIDR,198.18.0.0/16,DIRECT,no-resolve
 - IP-CIDR,224.0.0.0/4,DIRECT,no-resolve
 - IP-CIDR6,::1/128,DIRECT,no-resolve
 - IP-CIDR6,fc00::/7,DIRECT,no-resolve
 - IP-CIDR6,fe80::/10,DIRECT,no-resolve
 - IP-CIDR6,fd00::/8,DIRECT,no-resolve
 - MATCH,Proxy_HTTP

将上述文件使用 ADB 推送保存到 Android 设备的 /data/local/tmp 目录下：

adb push [FILE] /data/local/tmp/

如图：

image-20231017135504425

下面开始食用教程。

食用步骤

下述操作皆在 adb shell 命令下操作，需将 adb shell 授予 ROOT 权限。本文使用 BurpSuite 抓包工具演示，需前往 BurpSuite 将监听地址修改为所有接口，并将相关设备连接到统一局域网下。

1、前往 /data/local/tmp 目录下，运行 Clash-Meta ，命令如下：

# 授予 clash-meta 可执行权限
alioth@root:/data/local/tmp # chmod +x /data/local/tmp/clash-meta

# 运行clash-meta
alioth@root:/data/local/tmp # /data/local/tmp/clash-meta -d /data/local/tmp

如图所示即运行成功：

image-20231017140213514

​模块成功运行后，可通过控制面板控制代理选择，访问地址如下：https://yacd.metacubex.one

2、接下来就可以对目标应用抓包测试了， BurpSuite 拦截的数据包如图，以微信小程序为例，成功抓包：

image-20231017201558185

注意的是，此处成功抓包并解密其中内容，是因为本人已经将 BurpSuite 、Fiddler 等服务证书放置在了 Android 设备的根证书目录中，Clash 不会无视客户端的证书校验，所以，对于一些具有 SSL Pinning 的 HTTPS 软件程序，还是需要一些其它方式去解决证书校验问题，例如借助 Frida 、Xposed 框架的 TrustMeAlready 模块等。

此处之所以选择该 Clash 的 TUN 模式而非 Tproxy 模式，是因为该 Clash 的 TUN 模式支持自动设置全局路由，可以自动将全局流量路由到 TUN 网卡，可无需再次设置 iptables 的相关流量转发规则。

新版 Clash Meta 项目已变成 mihomo ，但使用原理不变。

更多的 TUN 模式的参数设置可借鉴参考如下教程文档：https://wiki.metacubex.one/config/inbound/tun/

小结

这也是个人近期“头脑风暴”想的一个抓包新姿势并实现，可能已经有大佬写过相关的教程文章了。但基于该方式的其它玩法也多多，例如借助 FRP 将电脑上的 BurpSuite 默认监听的 8080 端口临时映射至公网，然后在配置文件 config.yaml 中将相关规则的 IP 与端口替换成所映射至公网上的 IP 与端口，这样可以做到无需同一局域网条件下也可实现“抓包”。若你的配置文件中还有其它的规则，可以进行规则的合并与自定义，实现随用随切或只抓特定域名的包等等。瑞思拜~

End

本文标题：利用Clash进行透明代理的抓包新姿势

本文链接：https://www.isisy.com/1530.html

除非另有说明，本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议。

声明：转载请注明文章来源。

© 允许规范转载
如果觉得我的文章对你有用，请随意赞赏