V2EX › thisismr2 的所有回复 › 第 14 页 / 共 18 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 6 7 8 9 10 11 12 13 14 15 ... 18

❮

❯

2020 年 11 月 17 日

回复了 thisismr2 创建的主题 › 分享创造 › 使用 Wireshark 分析 iOS 和 Android 的所有 TCP&UDP 协议(和 TLS 解密)

@3dwelcome 如果是 android 可以用 xposed 钩子, 基本能达到修改 TLS 相关代码的效果

2020 年 11 月 17 日

回复了 thisismr2 创建的主题 › 分享创造 › 使用 Wireshark 分析 iOS 和 Android 的所有 TCP&UDP 协议(和 TLS 解密)

1-10 楼. 随机得出 2
https://i.imgur.com/z3ofQj7.png
https://i.loli.net/2020/11/17/xZ4Ibhfe8rSkVNG.png

@daohannce 请在这里 base64 一下你的邮箱, 然后告知需要 ios 还是 android 端的兑换码. Thank you.

2020 年 11 月 17 日

回复了 thisismr2 创建的主题 › 分享创造 › 使用 Wireshark 分析 iOS 和 Android 的所有 TCP&UDP 协议(和 TLS 解密)

根据 TLS 的原理, TLS 解密的难度可以分为很多种: 1 可以; 2 可以但很复杂; 3 可以但非常复杂; 4 不可以(除非能破解源码)
写这个的时候, 我曾试图解决更多, 但发现要想解决更多, 基本上都需要到 hack 操作系统机制的地步了, 当然大部分情况都是 1 的情况. 所以有 2,3 特殊情况时, 可以搭配 xposed 的模块已经算成熟了

2020 年 11 月 17 日

回复了 thisismr2 创建的主题 › 分享创造 › 使用 Wireshark 分析 iOS 和 Android 的所有 TCP&UDP 协议(和 TLS 解密)

原理是中间人攻击. 对于证书固定的可以搭配 xposed

2020 年 11 月 17 日

回复了 thisismr2 创建的主题 › 分享发现 › 用桌面 Wireshark 分析 iOS 和 Android 的所有 TCP&UDP 协议(和 TLS 解密)

发错位置了大家看这个 https://v2ex.com/t/726090

2020 年 11 月 17 日

回复了 thisismr2 创建的主题 › 分享发现 › 用桌面 Wireshark 分析 iOS 和 Android 的所有 TCP&UDP 协议(和 TLS 解密)

兑换码发放:
每 10 楼, 按 1-10 的随机数抽一次奖, 比如 1-10 楼抽一次, 11-20 抽一次, 21-30 抽一次...
抽的结果会在帖子内截图. 用 google 随机数生成器抽.
被抽到的可以选择需要 iOS 或 Android 端其中的一个兑换码

google 随机数生成器长这个样子

https://imgur.com/WLrgWLr
https://i.imgur.com/WLrgWLr.png
https://i.loli.net/2020/11/17/OwyukCsVGrUx8Jq.png
![image.png]( https://i.loli.net/2020/11/17/OwyukCsVGrUx8Jq.png)

2020 年 10 月 19 日

回复了 thisismr2 创建的主题 › 推广 › 一个配合 mitmproxy 的 iOS 和 Android 端 HTTP&HTTPS 抓包 APP(非设置系统代理方式)

目前 rawtcp 参数是 experimental 性质的

2020 年 10 月 19 日

回复了 thisismr2 创建的主题 › 推广 › 一个配合 mitmproxy 的 iOS 和 Android 端 HTTP&HTTPS 抓包 APP(非设置系统代理方式)

更正 #23 内容:

错误:
“坏处是 mitmproxy 只能处理 http 和 https 流量, 所以如果某个 app 走的私有 TCP 协议, 那么这部分流量 mitmproxy 就无法处理了, 可能 app 就显示无法连接之类的. 当然介于当前讨论的主题也是 HTTP 和 HTTPS 抓包, 可以理解. (这种情况如果 mitmproxy 后期可以将非 HTTP(S)协议的代理请求也正常处理哪怕不分析包就更好了)”

正确:
mitmproxy 可以处理非 http 和 https 流量, 只需要加个 --rawtcp 即可
$ mitmproxy -m socks5 --rawtcp

2020 年 10 月 17 日

回复了 thisismr2 创建的主题 › 推广 › 一个配合 mitmproxy 的 iOS 和 Android 端 HTTP&HTTPS 抓包 APP(非设置系统代理方式)

@coolzilj 其实目的是一样的. 其实就是 transparent, linux 和 bsd 和 mac 依赖的各不相同, iptables, doas, pf. 使用体验上. 如果对这几个工具非常熟还可以. 另外应该如果是 windows 应该就走不通了好像

2020 年 10 月 17 日

回复了 thisismr2 创建的主题 › 推广 › 一个配合 mitmproxy 的 iOS 和 Android 端 HTTP&HTTPS 抓包 APP(非设置系统代理方式)

@fx0719 升下嘛, 反正早晚得升

2020 年 10 月 17 日

回复了 thisismr2 创建的主题 › 推广 › 一个配合 mitmproxy 的 iOS 和 Android 端 HTTP&HTTPS 抓包 APP(非设置系统代理方式)

@playniuniu 给你发了邮件

2020 年 10 月 17 日

回复了 thisismr2 创建的主题 › 推广 › 一个配合 mitmproxy 的 iOS 和 Android 端 HTTP&HTTPS 抓包 APP(非设置系统代理方式)

发现了我没开启这个选项.

已开启.

https://i.imgur.com/04yqKHy.png

已经 subscribe 的我再看看

2020 年 10 月 17 日

回复了 thisismr2 创建的主题 › 推广 › 一个配合 mitmproxy 的 iOS 和 Android 端 HTTP&HTTPS 抓包 APP(非设置系统代理方式)

@playniuniu 好像还真是. 和 paypal 的逻辑不一样. 我研究下

2020 年 10 月 17 日

回复了 thisismr2 创建的主题 › 推广 › 一个配合 mitmproxy 的 iOS 和 Android 端 HTTP&HTTPS 抓包 APP(非设置系统代理方式)

@playniuniu 好像在 stripe 发给你的邮件里?

2020 年 10 月 17 日

回复了 thisismr2 创建的主题 › 推广 › 一个配合 mitmproxy 的 iOS 和 Android 端 HTTP&HTTPS 抓包 APP(非设置系统代理方式)

@playniuniu 我也第一次用这个支付方式. 怎么取消我得去搜搜, 搜到再回答

2020 年 10 月 17 日

回复了 thisismr2 创建的主题 › 推广 › 一个配合 mitmproxy 的 iOS 和 Android 端 HTTP&HTTPS 抓包 APP(非设置系统代理方式)

@playniuniu 兑换码已发. (昨晚睡的早)

2020 年 10 月 16 日

回复了 thisismr2 创建的主题 › 推广 › 一个配合 mitmproxy 的 iOS 和 Android 端 HTTP&HTTPS 抓包 APP(非设置系统代理方式)

如果没 append 发放完毕, 就代表还没发放完毕. 如果遇到边界情况导致不够会重新生成新的发放. 周末愉快.

2020 年 10 月 16 日

回复了 thisismr2 创建的主题 › 推广 › 一个配合 mitmproxy 的 iOS 和 Android 端 HTTP&HTTPS 抓包 APP(非设置系统代理方式)

**还有 16 对**

2020 年 10 月 16 日

回复了 thisismr2 创建的主题 › 推广 › 一个配合 mitmproxy 的 iOS 和 Android 端 HTTP&HTTPS 抓包 APP(非设置系统代理方式)

l 开头的 outlook 邮箱. 兑换码已发送.

2020 年 10 月 16 日

回复了 thisismr2 创建的主题 › 推广 › 一个配合 mitmproxy 的 iOS 和 Android 端 HTTP&HTTPS 抓包 APP(非设置系统代理方式)

我尽量系统的解释下抓包的各种情况.

## 首先是拦截流量, 两种情况

* 第一种是配置系统代理

这种方式呢通常是创建一个 http proxy, 然后配置到系统代理上, 如果 app 选择走系统代理(大部分会走, 但是 app 不走系统代理也是开发人员一行代码的事). 所以这种方式有一定的局限性. 不走的就是直连了.

* 第二种是拦截所有 TCP 和 UDP 流量

这是 mitmproxy client 选择的方式, 这种方式的好处是所有流量都能够拦截, 开发人员无视系统代理也没用(因为不工作在系统代理那块).
这里拦截了所有的 TCP 和 UDP 流量(这里刻意排除了 DNS 流量)给 mitmproxy
坏处是 mitmproxy 只能处理 http 和 https 流量, 所以如果某个 app 走的私有 TCP 协议, 那么这部分流量 mitmproxy 就无法处理了, 可能 app 就显示无法连接之类的. 当然介于当前讨论的主题也是 HTTP 和 HTTPS 抓包, 可以理解. (这种情况如果 mitmproxy 后期可以将非 HTTP(S)协议的代理请求也正常处理哪怕不分析包就更好了)

## 关于(SSL)TLS 和单独对称加密的数据

解密 TLS 的原理就是中间人劫持, 所以需要那个根证书.

TLS 又分单向和双向认证

单向认证: 通常 https 的网站啊接口什么的都是单向认证, 所以可以我们用根证书辅助来拦截, 可以正常解包.

双向认证: 也就是服务端会验证客户端的证书, 所以这种是无法解密的(不好理解, 可以理解下面要描述的情况)

单独对称加密: 可以理解为服务端和客户端约定一个密钥, 客户端将密钥编译进代码里. 这种情况, 只有你知道编译进代码里的密钥你才能解密. 所以根证书也是无能为力的.

1 ... 6 7 8 9 10 11 12 13 14 15 ... 18

❮

❯