0x00 背景介绍
在工作后的休闲时间我比较喜欢打开网络电台听一些有声书,大牛实事点评;不知道从什么时候开始网络上突然流行起了付费音频,很多付费音频都是由名家亲自参与制作,质量非常高 很受大众的喜欢;其中以某电台的付费内容最受欢迎,我也购买了好些套音频来跟着名家的脚步学习;名家制作的付费音频在选择的时候不容二说,直接购买就是;但是也不乏其中有很多的标题党 哗众取宠,能不能在不付费的情况下先进行一次试听呢
0x01 分析
为了方便分析,我特意选择了直接在浏览器中打开电台wap版;随便选择一个付费才能收听的音频,使用Chrome浏览器,调试模式,手机模式如下所示
音频播放URL:http://m.xxx.com/69149360/sound/32173409
其中直接访问 http://m.xxx.com/69149360 可以显示当前主播的所有音频,也就是说 69149360 为主播ID, 而后面的 32173409 应该为当前的音频ID。
点击播放按钮通过chrome 调试 Network功能标签中,可以看到客户端会向服务端请求音频的真实地址用来播放; 通过分析发现以下两个请求比较关键。
第一个关键请求:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
|
第二个关键请求:
1 |
|
第二个请求直接就是m4a 音频地址了,其中服务器地址是 audio.pay.xx.com ,可以轻易的看出应该是从第一条GET中返回的json中获取的;那 这一串参数是怎么得来的呢?
1 |
|
0x02 调试
作为一个优秀且长相帅气的看雪潜水多年的网友,遇到问题想到的第一解决方案就是 调(tiao)试(xi); 对付这种web型的协议密钥就不用祭出倚天剑(OD)和屠龙刀(IDA)了,直接利用chrome自带的调试功能以及Fiddler进行劫持就够了。过程如下:
从以上两条请求可以分析得出,音频的最终请求参数不是由服务器返回,而是由本地计算得到的;通常在web开发中js往往就承担了计算以及动态控制责任。由于本人对js不是很熟悉,无法快速定位于是使用了一个本办法:删除触发播放按钮的事件来定位,删除一个点击下播放,查看是否能播放,然后再删除一个再点击播放 如此循环;
在不断删除点击下,最终定位到请求w4a的处理时间在all.js中。打开all.js 发现所有js源码都在同一行,这完全无法分析,而且影响下js断点调试;于是我将js 格式化保存到本地,利用Fiddler 的AutoResponder功能劫持到本地来设置。由于站点使用https 来传输js,Fiddler无法劫持https内容,我们索性将整个请求页面一并劫持并修改源码all.js 去请求非https;Fiddler设置如下
all.js格式化之后变得特别清晰,于是乎我们先稍微看一遍all.js 看看哪里可能是解密的关键地方。干逆向这么久,觉得逆向的过程就是一个猜想和推到猜想的过程;以我C语言功力来理解js 在有可以的地方下断点(关于Chrome JS 调试请看这里: http://www.jb51.net/article/58570.htm)
点击播放,最终发现在 success: function(t) { 这个地方停下来
F11一步步分析得出结论如下
解密播放绝对路径:
KEY通过字典o(s, r) 运算由 dg3utf1k6yxdwi09得到 xkt3a41psizxrh9l
1 |
|
再将KEY和第一条GET得到的json内容中的ep一起传入 i(p, e(t.ep)) 中,经过取字典位移等运算得出密文,
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 |
|
使用json返回的_randomSeed通过算法得到字符串A "oRIBQLWKzamwPSuh\C3:1cdMDTYvJVeH_q97fjX58p4nFsgxyr20t.NObi6-GEAlUk/Z"
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
再使用json中返回的fileId 字段重新排列字符串A 得到最终结果 preview/1702877/group1/M01/04/6E/wKgJMljAJmaxaBjBAVPzE83Jfuo884.m4a
1 2 3 4 5 6 7 |
|
有了m4a的绝对路径结果已经很清晰了; 播放地址拼凑方式为:domain+"download"+apiVersion+解密后的绝对路径+?+sign+buy_key+timestamp+token+duration
OK截至到这里,我们已经将收费音频中的试听音频的逻辑分析清楚了,下面我们看看必须购买才能听的音频是如何使用上诉逻辑获取真实地址的;
由于上面的分析使用的一条收费且可以试听的音频,下面我们看看如何获取其他收费的音频
复习一下:获取收费音频的播放列表的URL是 http://m.xxxx.com/zhubo/主播ID ,我们去主页随便选个收费且不能试听的主播ID试试吧 如下:
于是我们可以直接拿这个ID 来直接拼凑成我们分析的第一条GET语句(返回播放json) :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
|
看到如此熟悉的结果相信大家知道应该怎么做了吧?懂js的同学可以直接还原 all.js的算法,我这里就偷个懒用了浏览器来直接替换json值来计算结果
直接在解密函数头,双击t.ep中的值进行修改;关键值为:ep, fileId,seed, fileId,duration;由函数直接计算的结果为:
1 |
|
0x03 总结
本篇文章得以完成,完全需要感谢此app在架构过程中产生的逻辑漏洞;(服务器太过于信任客户端和未对收费音频进行认证(音频用户关联性认证)); 对此我要对此app表示感谢!
好了我们的本次分析某电台收费app之旅就结束了,懂js或者会调用js的同学,相信你们直接写个脚本遍历下载本app的所有付费音频应该不是什么难事吧; :) ,此篇文章我也会一并发送到app官方技术邮箱中,如果相信看到本文的朋友动手实战时会发现文中所诉根本不成立。
由于本人技术有限,文中所写如有错误地方还请大家指正海涵。如果有没看明白的同学可以在帖子中留言或者直接站内信联系我(请不要问我其他高深的问题,因为我连js都不会。。。)
0x04 感谢
在 VPP Security Lab 小组中论漏洞挖掘能力我不及@ggggwwww,论漏洞分析能力又不及@少仲。如此菜的人在VPP中得以生存下来是源于两位的无私分享,谢谢你们!
感谢看雪平台上所有无私奉献的大牛,没有你们的文章,估计我的技术应该还处于村口放牛的水平!谢谢!