wnagzihxa1n

wnagzihxa1n

iOS/Android Security

© 2021

大土豆安全笔记 2020.03.31

菜栏现在的粉丝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

IMAGE

痛定思痛,这是低级错误啊!

于是我赶紧复习看了一波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

IMAGE

崩溃的地方是memcpy(),由于我们目前还没有动态跑起来,中间的执行过程暂时不清楚,所以就不过多的去关注了,先把大概的流程梳理清楚

IMAGE

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()会对包做类型判断,再进行相应的分发操作

我们需要关注两个位置

IMAGE

第一个位置是函数UnpacketRTP(),它负责减去12字节

v7 = UnpacketRTP(
               &pCur,               // 指向包
               (signed int *)((char *)&nCodec + 3),
               udwTimeStamp,
               &udwTimeStamp[1],
               &redundantlen,
               &pDataLength);       // 对RTP包进行操作

传入的是指针变量,所以等于上层函数变量减去12

IMAGE

回到函数XVEChannel::RecvRtpPacketCng(),减完之后的变量为pDataLength,赋值给___len

___len直接传入函数CAudioJBM::InputAudioFrameToJBM()

IMAGE

后面的逻辑我们在一开始已经分析了,只判断了是否大于300

问题来了,这个变量pDataLength是什么呢?

根据大佬的报告描述,它是包的长度,我们继续往前回溯分析,发现pDataLength来自函数参数a3

我后面还分析了一部分,但是没有运行数据的情况下分析起来感觉没什么意义,就先不贴分析了

今天拿到了测试机,明天可以跑Frida来打印数据了,我目前遇到最大的问题就是不知道数据从哪里开始一层层组包,也不知道包从哪里开始一层层解包,有中间数据之后分析起来半猜半蒙就好很多了,强行假装自己还能再抢救一会儿

关于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

我今天想到一个很神奇的远程交互代码逻辑分析方式,不过需要先花时间写一个工具,一般情况下我都会把自己的思路无保留的在这里分享,但是这个思路我先藏着,扩展一下可以自动化Fuzz

一定有其它大佬已经实现了类似的工具了,但是开源的肯定没有