一开始直接用了burpsuit抓包，但是什么东西都没抓到，于是用netstat看了一下，再结合资料，发现用的是私有协议mtproto，所以burp抓不到东西。

直接用frida开始hook，虽然不太清楚具体的结构，但是可以先hook一些比较底层的函数，然后分析数据再把hook点一步步的网上移，最后挂到反序列化、解密操作之后的地方。

用脚本先Hook native里的以下函数:

这一步可以拿到fd, peer, ip:port, 收发方向, 包大小。

然后分析包的前十几个bytes，发现了疑似mtproto transport的类型。

例如:

这里看到的只是原始数据，是看不到明文的。

可以hook

在这里直接遍历

然后打印第一参数，也就是tl的请求对象:

在日志里就能够看到:

真正获取到明文消息的内容的位置是在

在这里只选择第一参数是:

的overload。
可以做个简单的逻辑判断：

然后调用

这里已经是 Telegram 客户端处理服务端更新的业务层了。也就是说：

在这里抓到的就不是密文了，而是java对象。

接下来需要做的是对updates.updates里的东西进行筛选:

如果发现有message字段，就进一步去尝试获取:

找到的最贴近聊天窗口的地方是在:

hook一下MessageObject的构造函数：

这个MessageObject是一个用的很多的消息包装对象，文本、图片、媒体状态都会被包成这个对象然后交给ui。

logMessageObject()主要功能是：

其中：
messageOwner 是原始 TLRPC$Message
messageText 是 UI 层处理后的文本
summarizeMessage(owner) 会继续解析消息、发送方、会话、媒体

所以这一步拿到的其实就是已经解密、反序列化之后的马上要给ui去用的明文消息。

大概的格式是这样的：

这里的ttl_seconds应该是这张图片过期的时间，2147483647是最大的int值。在app里处理的时候也有判断ttl_seconds == Interger.Max的，如果是那就说明这是一张view once图片；如果ttl_seconds > 0说明不是一张普通的图片；如果0 < ttl_seconds < Interger.Max那就计算其过期时间，时间到了就调用相应的销毁逻辑。

在找到以上信息之后，为了找到对应的图片处理逻辑，直接尝试hook了getPathToAttach这个函数。

每当从对话列表点到对话框里的时候，就会调用这个函数去加载照片。

对于普通的图片和阅后即焚的图片保存路径是不一样的，阅后即焚的照片保存路径在

并且不是以明文的形式保存的。通过对这个目录下的一些文件进行分析，发现文件名有点意思，可以看看：

除了开头的那个-之外，60709917428586295这一段相同，后面的结尾有点不同。

所以有理由相信，这些就是同一组照片在cache中的不同的派生文件，简单来说就是这是一起的。

所以接下来需要找的就是谁加载了这些文件，然后加载之后去了哪里，在哪里解密的？

为了找到是谁打开了这个.enc，在native层我hook了：

在java层hook了：

中的

还有

中的

最终确定了调用链:

[培训]《冰与火的战歌：Windows内核攻防实战》！从零到实战，融合AI与Windows内核攻防全技术栈，打造具备自动化能力的内核开发高手。