一次失败的破解经历

受人之托，想从某网站上“弄到”其上的直播视频流，并加以利用，虽然最终失败了，但其中的破解经过还是值得和大家分享，希望对你有启发。

视频直播流无外乎采用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的主要功能，这样的工作量几乎不现实。所以该网站通过这些方法有效的抵挡了像我这样想爬取其资源的人。本人甘拜下风。