上文通过fiddler抓到了点赞的包,并通过对比不同包的差异确定了需要逆向4个关键字段的算法:X-Ladon、X-Gorgon、X-Tyhon、X-Argus; 本文尝试逆向分析这些字段的实现算法!
逆向都是从数据开始的!于是满怀期待把这4个字符串放到android killer(jdax-gui逆向这种上百兆app时,用全局搜索非常耗内存,我16G的内存都不够用),结果无一例外都找不到!这不是应征了中国人的那句古话:此地无银三百两么!既然这些字段直接搜不到,那么就有这么及种可能:
- 字段本身被分成了好些段,比如X-Ladon被分成了X- La don等段,用完整的字符串搜不到;
- 字段本身被加密了,使用的时候才动态解密,导致静态搜索查不到
- dex文件被加密或加壳导致静态搜索查不到
- X-Ladon是在so层生成的,所以java层静态找不到!在kali下用strings命令查找的结果不乐观,如下:啥都没有
换成X-试试:这次找到了一大堆,但是挨个人肉搜查后发现还是没有我们想要的这4个字段,那么只剩一种可能了:这4个字段都被加密了!
关键字段直接找不到,只能“围魏救赵”,从非关键字段入口;GET头有很多字段,GET的url里面不也有很多字段么?其实这些字段都是为了从客户端给服务端传递信息,没有本质区别的!头的字段不好找,就从url下手呗!用url的“/aweme/v1/commit/item/digg/”下手,终于找到了(而且还只有2处,非常利于查找):
smali代码看着不方便,这里继续换成jadx试试。代码如下:很明显用了retrofit框架!
从这里也看不出个啥!那就用obejction hook试试呗:结果没任何反应,说明根本没调用!
截至目前,静态分析能用的手段都用了,由于java层混淆地厉害,不太好分析这些类、方法和变量的功能;lib下面的so文件有113个,我也没时间精力挨个拖到IDA去分析,只剩一条路了:内存搜索和dump!
先用objection,查找某个字段,有结果:
用frida查看:意外发现了另一个关键的字符串;
在这个内存地址下断点,一旦有代码读写这个内存地址立即断下来,用来定位关键的代码;andrdoi端该怎么操作了?先试试GameGardiance!尝试后发现这里只能查找字符串地址,然后根据maps映射查看,发现这些地址都是通过malloc函数在栈上分配的,根本不再代码段(这又是一句正确的废话),无法定位到具体的so!
X-Ladon也是:都是通过malloc在栈上分配的地址,无法定位到so文件!
换成最熟悉的CE:X-Ladon关键字段存放的位置很多,但是值得关注的不超过5个,如下:
本以为胜利就在眼前,想直接通过“find out what access this address”定位到关键代码,结果直接报错!what the fxxk.............
刚开始不知道为啥,后来查了很多资料,发现是hw手机即使root后,默认也没开启硬件断点,所以用gdb调试也没法下硬件断点:
先根据ce的地址找X-Ladon字段,结果在这个字段的附近居然同时出现了其他3个字段,真是得来全不费功夫啊)!
耐心点:每个字段都下个读写断点:
有可能是这些通过malloc分配的地址只用1次(尝试过用pixel,毕竟是Google的亲儿子,root后默认是开启了硬件断点的。用CE的“find out what access this address”还是没断下来;不管我更换多少视频、点赞等操作,通过CE查看内存数据一直都没变,说明这块内存只被用了一次就没再用了; 后续从sub_6221c函数分析得知: 这3个字段每次生成前都用malloc分配内存,所以这些内存只用一次,用内存断点的方式自然是找不到读写的代码),用完就回收,所以导致断不下来!这种方式每次用的时候都要申请内存,效率较低,但也更加安全,可以有效防止内存断点的追踪!还有一种可能:这些加密字段是针对当时发送的数据做加密的,因为每次发送的数据包不同,所以每个数据包加密的密文只用1次,所以用这种方式是无效的!好吧,思路到这里又断了!
换个思路:从/proc/pid/maps这里看到,这些地址内存都是通过libc的malloc函数分配的内存,要是在这里下断点,然后在栈上回溯,是不是就能追踪到调用者了?
frida有个trace的功能(ida也有,但是调试时经常弹窗爆各种异常,需要手动选择和点击,trace的效率台低,已经放弃),首次运行命令后会生成一个js脚本,然后自己在js脚本添加需要打印的信息,我改后的js脚本如下:
这里打印调用堆栈;由于被调用很多次,我就不把所有的日子都贴出来了,这里选几个比较关键的:
从日志来看,调用libc.so文件中malloc函数的so文件不多,有libutils.so、libinput.so、libc++.so、libbinder.so、libstagefright.so、libui.so、libgui.so、libsqlite.so,这些so的数量和原始110多个so比,范围已经小了很多;并且也能定位到so的哪一行代码层层调用了malloc函数,后续先从内存dump这些so,从这里开始继续分析!
============================分割线==============================
个人猜测是给公司内部所有产品使用的通用代码);这些基础框架代码包含了retrofit代码,通过http、network等关键自研,hook了 “com.bytedance.frameworks.baselib.network.http.util.UrlUtils.encode” 这个函数;又根据调用栈找到了com.ss.android.ugc.aweme.bp.d$3$1.run,这个是栈底的函数了,说明就是从这里开始运行的;并且从命名看,这明显是x音的函数,所以需要重点跟踪!从java层的源码看,这个是Thread线程,当试图搜索这个函数的start方法时,但是根本找不到(如下):猜测start方法可能被加壳隐藏了,后续还要好好找找在哪藏着的!
以上就是本篇文章【python逆向抖音xb算法请求不到数据 抖音xlog算法逆向】的全部内容了,欢迎阅览 ! 文章地址:http://mdekt.bhha.com.cn/quote/168.html 行业 资讯 企业新闻 行情 企业黄页 同类资讯 网站地图 返回首页 康宝晨资讯移动站 http://weazh.bhha.com.cn/ , 查看更多