菜栏现在的粉丝170位,拜托大家一件事,别点”好看”,是的,别点,这玩意对我有毒,我不想自己陷在多少个”好看”里面,也别去转发分享这个破菜栏的文章,说真的没啥好转发的,我又不靠这玩意赚钱,就是我日常学习瞎扯
主要是我很喜欢说话,可以一直讲不停的那种,但是日常搞审计又没人跟我说话,所以开了个菜栏哇啦哇啦,现在这种状态我感觉挺好:)
今天没做啥,继续分析微信那个内存破坏,菜啊,一个内存破坏分析了两天还没分析完
做了一件很蠢的事情,C++的类函数在编译后第一个参数会是this
,我一开始分析是this
对应R0
,但是分析一半脑子一抽,觉得this
不占用寄存器传参,又重新分析,后来发现一个short
类型变量对应成了指针,才发现不对
我举个例子,就是一个set/get
class DemoCPlus {
private:
int field;
public:
DemoCPlus();
int getField();
void setField(int field);
};
DemoCPlus demoCPlus;
demoCPlus.setField(10);
可以看到第一个参数是this
,占用R0
痛定思痛,这是低级错误啊!
于是我赶紧复习看了一波ARM逆向,RE4B真是本好书,当然我看的是中文版,毕业那年买的书
01 libvoipCodec - CAudioJBM::InputAudioFrameToJBM
#01 pc 0x1219ff /data/app/com.tencent.mm-TQNkaubz5b3G-b5myc_RkA==/lib/arm/libvoipCodec.so (CAudioJBM::InputAudioFrameToJBM(unsigned char*, int, unsigned int, unsigned short, int, int, int)+2298)
函数CAudioJBM::InputAudioFrameToJBM()
只对n
做了一个判断,n
来自a3
,也就是寄存器R1
崩溃的地方是memcpy()
,由于我们目前还没有动态跑起来,中间的执行过程暂时不清楚,所以就不过多的去关注了,先把大概的流程梳理清楚
02 libvoipCodec - XVEChannel::RecvRtpPacketCng
#02 pc 0x10648b /data/app/com.tencent.mm-TQNkaubz5b3G-b5myc_RkA==/lib/arm/libvoipCodec.so (XVEChannel::RecvRtpPacketCng(unsigned char*, short, int)+5690)
感谢盘古分享的文章,让我可以直接拿重命名后的变量来分析,太省事了
RecvRtpPacketCng(__int64 XVEChannel, unsigned int *pData, __int16 len, void *a4)
函数XVEChannel::RecvRtpPacketCng()
会对包做类型判断,再进行相应的分发操作
我们需要关注两个位置
第一个位置是函数UnpacketRTP()
,它负责减去12
字节
v7 = UnpacketRTP(
&pCur, // 指向包
(signed int *)((char *)&nCodec + 3),
udwTimeStamp,
&udwTimeStamp[1],
&redundantlen,
&pDataLength); // 对RTP包进行操作
传入的是指针变量,所以等于上层函数变量减去12
回到函数XVEChannel::RecvRtpPacketCng()
,减完之后的变量为pDataLength
,赋值给___len
___len
直接传入函数CAudioJBM::InputAudioFrameToJBM()
后面的逻辑我们在一开始已经分析了,只判断了是否大于300
问题来了,这个变量pDataLength
是什么呢?
根据大佬的报告描述,它是包的长度,我们继续往前回溯分析,发现pDataLength
来自函数参数a3
我后面还分析了一部分,但是没有运行数据的情况下分析起来感觉没什么意义,就先不贴分析了
关于qemu的漏洞利用文章《qemu-pwn cve-2019-6788堆溢出漏洞分析》,写的不错,扩展学习一波
- https://ray-cp.github.io/archivers/qemu-pwn-cve-2019-6788%E5%A0%86%E6%BA%A2%E5%87%BA%E6%BC%8F%E6%B4%9E%E5%88%86%E6%9E%90