一次失败的破解经历

受人之托,想从某网站上“弄到”其上的直播视频流,并加以利用,虽然最终失败了,但其中的破解经过还是值得和大家分享,希望对你有启发。 视频直播流无外乎采用RTMP协议封装的Flv或者mp4,或者HLS,当然还有本人独门技术(websocket传输裸数据,通过js解码播放)。不过本次遇到的技术非常棘手,最终以失败告终。 chrome打开网站的直播画面,话不多说,F12调出控制台,定位到直播画面的Dom元素,一看是一个Flash元素,关键参数通过Flashvars传递给flash,这些参数都是明文传递,其中主要是userId,videoId。貌似十分顺利。 如果是Flash播放器,那么下面的路数就是进行反编译。拿出10年窖藏的工具发现已经落后了,网上一搜一大把,找了一个免费的功能强大的工具,打开swf文件,没有混淆,代码一览无余。貌似十分顺利。 代码不多,经过仔细分析,发现使用的是RTMPE协议进行播放的。虽然本人专业从事过Flash以及视频直播方面的工作,可真就没研究RTMPE协议,这是一个RTMP协议的变种,在RMTP协议基础上进行了加密。这一加密不要紧,还做了另一个验证工作,足足困扰了我一整天时间。 在视频播放前,播放器还做了一件事来防盗链。下面我详细说明一下。

  1. 在RTMPE连接服务器成功后——NetConnection.Connect.Success
  2. 通过RPC调用了一个方法GetLive,该方法返回了一个ByteArray对象————可以理解为二进制流
  3. 将该二进制对象load到Loader中并允许其访问父SWF的代码权限 这里稍微说明一下,这个操作是Flash里面加载另一个Flash的过程,Loader对象可以直接加载一个swf的URL,或者就是上述的直接从内存里面加载一个二进制对象,这种通过RTMPE协议的RPC方式传输一个SWF的二进制格式相当隐蔽,又由于RTMPE协议的加密性,所以通过抓包你是无法知道这一个操作过程的。 我通过模拟这一个过程,在连接断开之前,通过fileReference对象将这个ByteArray对象存储到了硬盘上。再通过反编译工具打开,看到了这个SWF文件的源码。在这个源码里面它做了这样一个操作
  4. 这个加载进来的SWF里面携带了一个字符串,并以这个字符串作为RPC的方法名再次发起请求,并从服务器得到视频流的实际名称。
  5. 主SWF通过这个视频流的名称进行播放视频

上面的流程算是全部弄清了,下面就是破解过程。首先通过反编译工具对SWF进行局部修改,意图去掉其中的一些视觉元素(也是通过RPC返回的ByteArray加载到屏幕上的),结果只要我修改过SWF,连接就会很快断开。于是我干脆自己重新写一个Flash播放器,但也是一样的命运。 上baidu搜RTMPE、bing搜、翻墙Google搜,都没有多少资料。 第二天,继续研究,据我推测,服务器肯定对SWF文件本身进行了验证,如果两个文件有所不同即使一个字节不同,那么文件的Hash肯定不同。这是许多下载工具进行校验的原理。后来我打开Adobe官方文章查看了RTMPE协议的说明,恍然大悟:FMS服务器中可以用RTMPE协议对swf文件进行验证,如果不是指定的swf客户端文件就会拒绝连接。

那么是否可以伪造一个客户端,发送验证信息呢?理论上可以的,但需要了解FlashPlayer的加密流程和验证信息的生成原理。即便如此,还需要解决动态载入SWF的问题,那就需要实现FlashPlayer的主要功能,这样的工作量几乎不现实。所以该网站通过这些方法有效的抵挡了像我这样想爬取其资源的人。本人甘拜下风。

转载于:https://my.oschina.net/langhuihui/blog/2877959

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值