受人之託，想從某網站上“弄到”其上的直播視頻流，並加以利用，雖然最終失敗了，但其中的破解經過還是值得和大家分享，希望對你有啓發。 視頻直播流無外乎採用RTMP協議封裝的Flv或者mp4，或者HLS，當然還有本人獨門技術（websocket傳輸裸數據，通過js解碼播放）。不過本次遇到的技術非常棘手，最終以失敗告終。 chrome打開網站的直播畫面，話不多說，F12調出控制檯，定位到直播畫面的Dom元素，一看是一個Flash元素，關鍵參數通過Flashvars傳遞給flash，這些參數都是明文傳遞，其中主要是userId，videoId。貌似十分順利。 如果是Flash播放器，那麼下面的路數就是進行反編譯。拿出10年窖藏的工具發現已經落後了，網上一搜一大把，找了一個免費的功能強大的工具，打開swf文件，沒有混淆，代碼一覽無餘。貌似十分順利。 代碼不多，經過仔細分析，發現使用的是RTMPE協議進行播放的。雖然本人專業從事過Flash以及視頻直播方面的工作，可真就沒研究RTMPE協議，這是一個RTMP協議的變種，在RMTP協議基礎上進行了加密。這一加密不要緊，還做了另一個驗證工作，足足困擾了我一整天時間。 在視頻播放前，播放器還做了一件事來防盜鏈。下面我詳細說明一下。
- 在RTMPE連接服務器成功後——NetConnection.Connect.Success
- 通過RPC調用了一個方法GetLive，該方法返回了一個ByteArray對象————可以理解爲二進制流
- 將該二進制對象load到Loader中並允許其訪問父SWF的代碼權限 這裏稍微說明一下，這個操作是Flash裏面加載另一個Flash的過程，Loader對象可以直接加載一個swf的URL，或者就是上述的直接從內存裏面加載一個二進制對象，這種通過RTMPE協議的RPC方式傳輸一個SWF的二進制格式相當隱蔽，又由於RTMPE協議的加密性，所以通過抓包你是無法知道這一個操作過程的。 我通過模擬這一個過程，在連接斷開之前，通過fileReference對象將這個ByteArray對象存儲到了硬盤上。再通過反編譯工具打開，看到了這個SWF文件的源碼。在這個源碼裏面它做了這樣一個操作
- 這個加載進來的SWF裏面攜帶了一個字符串，並以這個字符串作爲RPC的方法名再次發起請求，並從服務器得到視頻流的實際名稱。
- 主SWF通過這個視頻流的名稱進行播放視頻
上面的流程算是全部弄清了，下面就是破解過程。首先通過反編譯工具對SWF進行局部修改，意圖去掉其中的一些視覺元素（也是通過RPC返回的ByteArray加載到屏幕上的），結果只要我修改過SWF，連接就會很快斷開。於是我乾脆自己重新寫一個Flash播放器，但也是一樣的命運。 上baidu搜RTMPE、bing搜、翻牆Google搜，都沒有多少資料。 第二天，繼續研究，據我推測，服務器肯定對SWF文件本身進行了驗證，如果兩個文件有所不同即使一個字節不同，那麼文件的Hash肯定不同。這是許多下載工具進行校驗的原理。後來我打開Adobe官方文章查看了RTMPE協議的說明，恍然大悟：FMS服務器中可以用RTMPE協議對swf文件進行驗證，如果不是指定的swf客戶端文件就會拒絕連接。
那麼是否可以僞造一個客戶端，發送驗證信息呢？理論上可以的，但需要了解FlashPlayer的加密流程和驗證信息的生成原理。即便如此，還需要解決動態載入SWF的問題，那就需要實現FlashPlayer的主要功能，這樣的工作量幾乎不現實。所以該網站通過這些方法有效的抵擋了像我這樣想爬取其資源的人。本人甘拜下風。