用一首歌曲來譜寫RTMP協議分析

新聞 08-23

為了讓我這篇技術稿更加有情趣，打算用一首歌曲的結構來命名我整篇文章的脈絡。

一、前序

最近在重溫由W.Richard Stevens 的傳世之作《TCP/IP詳解》，看到第12章TCP ，基於傳輸層有TCP 、 UDP 、 TLS 、DCCP 、SCTP 、RSVP 、PPTP等，那我好奇那基於TCP有哪些協議呢？在Google裡面查找了一下，有一個協議映入眼帘 RTMP ，RTMP(實時消息傳輸協議)是Adobe 公司開發的一個基於TCP的應用層協議，主要用來在Flash/AIR平台和支持RTMP協議的流媒體/交互伺服器之間進行音視頻和數據通信。RTMP協議沒聽過啊，一下子激起了我想要揭開它的面紗的衝動，大概研究了RTMP協議整整3天時間，試圖想要找出一些漏洞出來，幸運的是我找到了！很雞凍，下面就是我對此協議的分析。

二、RTMP協議分析

1) 播放一個RTMP協議的流媒體需要經過：

1>握手 2> 建立鏈接 3>建立流 4>播放 5>發送 ———————

1>握手(Handshark)

Handshake done Handshake done

Note：交互示意圖就不講解了,很簡單!為了讓本技術稿有很好的易讀性，我儘力注釋！

2>建立鏈接（ConnectResponse）

3>建立流

4>播放

←—-抓包播放的關鍵字元串「play」

5>發送（Send）——Metadata

2）用我的寶貝wireshark抓包來分析一下過程

1>抓包：

2>RTMP消息結構：

還是用XMind做個示意圖吧！

要想在相應的網路環境上傳輸就需要將消息拆分成較小的數據塊

3>消息塊的報文結構：

Note:時間戳:由於時間戳在電子取證中的重要作用及其法律地位，時間戳系統必須擁有極高的安全級別，安全保護應包括物理環境安全和軟體安全。

4>RTMP消息分塊

Message被分割為幾個消息塊的過程中， Message Body大小固定的消息塊(Chunk Size，默認128個位元組)並在其首部加上Chunk Header 就組成了相應的消息塊。

Eg:309位元組的消息塊進行分塊示意圖如下所示：

3) HnadsShark階段的源碼分析

三、滲透測試&<流行句D>

分析到RTMP居然是未加密協調，很開心！然後就查了一下此協議的都應用在哪些方面，結果是：流媒體/交互伺服器之間進行音視頻和數據通信，我第一就想到的應用場景是當今炙手可熱的直播平台，隨便百度了一下，點進去一個直播平台如下圖：

哇塞，可愛的妹子，心裡想再瞅瞅，不一會有有一個噁心的彈窗蹦出來，如下圖：

我毫不猶豫的關閉這個彈窗，心裡想：還敢不敢讓我安安靜靜的看這個直播，沒過30s又出現這個彈窗！我明白了這個直播平台想要

收集我的個人信息<不懷好意，大家都懂的！>

不認證不給看!心裡憋屈，想著能不能繞過註冊認證看直播呢？反正已經知道RTMP協議是未加密的，是明文傳輸的！先抓包看一下再說。

Note:1>想要抓到完整的三次握手包，必須是在免費觀看的那段時間進行抓包，彈窗後後抓的包是不完整的！

2>由於這種通信模式是最常見的C/S模式，突然讓我想到剛剛分享了Rtmp的消息結構，

Play/Pause

它是C/S交互的字元串標誌！

Note:ID(15-20)是負責發送AMF編碼的命令，負責User與Server之間的交互 eg：Play/Pause。

也就是Rtmp協議裡面肯定有」play」這個字元串！然後用wireshark的過濾器進行字元串關鍵字的查詢；由於是未加密的協議，只要我找到這個播放的URL地址，再找個可以播放這種流式協議的播放器不就大功告成了嗎？突然腦袋中靈光乍現，記得在2017-7-27的BUF早餐鋪<本人像追劇一樣，每次發布，必拜讀>就有報道一個內容是：關於因頻繁殺後台，VLC播放器將華為機型列入黑名單。