線上影片常見加密方式及安全性透析

資訊化時代，多媒體的應用日漸成為人們生活中不可或缺的部分，無論是獲取最新資訊還是教育學習，影片都是直觀高效的媒介之一。

　　基於網際網路的快速傳播，眾多培訓機構也逐漸將線下原創版權課程遷移到線上平臺中，一方面可以更快的打響知名度，同時往往能帶來比較樂觀的收益。這也滋生了黑產，盜版隨之出現。如何防範原創影片被輕易盜版呢?針對該問題，筆者對市面上的影片防盜方案做了一定調研，如有任何不當之處，請指正。

　　本文將根據面向人群分類闡述。一種是防小白使用者，一種是防IT技術人員。

　　防小白使用者

　　什麼是小白使用者?小白使用者是指對計算機的瞭解，僅停留在會使用階段的人群。

　　怎麼防小白使用者下載影片呢?一般採用的方式，包括但不僅限於播放地址隱藏、動態url校驗、協議防範等方式進行影片保護。

　 　播放地址隱藏

　　我們要知道，網站是基於HTTP協議的，如網站的圖片、css、js都是透過該協議進行傳輸，影片也不例外。由於http協議的開放性，很多瀏覽器或外掛都開發了對應的嗅探下載功能。如遨遊瀏覽器、360瀏覽器等。

　　***.com/space.php?do=playvideo&op=play_demo&iframe=0&aid=null&lid=22880&ltype=31&width=640&height=400 比如該網站的課程，採用了某度雲的平臺，就是對播放地址進行了簡單的隱藏的方式。相關影片使用某些瀏覽器就可以下載。

　　動態url校驗

　　第一種地址隱藏的方式，地址是固定的，所以很容易被下載。為了解決這個問題，很多網站或平臺，選擇在原始基礎上，加入了自定義的sign計算，進行播放地址校驗。

　　一般來說動態url具有時效性，可以有效地防下載和盜鏈。如某網校採用的樂視雲平臺。

　　**o.cn/player/Index.aspx?Id=3d009f67-259f-4aff-a710-25926a59278d

　　經過分析此時的下載地址如下：　　****29/play.videocache.lecloud.com/256/19/103/bcloud/121442/ver_00_22-1101707449-avc-800000-aac-61969-1*****0fdb2b1705aa116313dfd2-1495075183392.mp4?crypt=72aa7f2e948&b=879&nlh=4096&nlt=60&bf=86&p2p=1&video_type=mp4&termid=2&tss=no&platid=2*****=1519887000&nkey=22ab7366672c34cf45ff3abca0c1a564&nkey2=12672f233895fe89b49d0328161fadec&auth_key=1519887000-1-0-2-209-c08a24f6e01c7227fc9be939f3a4385d&geo***sid=235117191&tm=1519868986&key=4e34e1d64057a46346c4b42795e1c173&payff=0&cu***8&dur=1210&p1=3&p2=31&p3=310&cf=h5-android&p=101&playid=0&tag=mobile&sign=bcloud_121442&pay=0

　　通常情況下，該類下載地址存在一定的引數校驗，包括了時間戳 sign 等。但sign計算規則一般都比較簡單，容易被識破偽造。

　　這種方式同樣也可以透過瀏覽器或外掛下載。不過需要自行判斷，哪個地址才是真實的檔案地址。

　　協議防範

　　鑑於http協議的開放性，那麼影片如何避免被瀏覽器或外掛嗅探呢?一些網站選擇從協議入手，採用非http的協議進行影片播放，如rtmp協議。

　　rtmp協議由來已久，是adobe公司推出的影片播放協議，穩定性和安全性較http更好，應用廣泛。rtmp協議，需要專用的伺服器，如FMS，開源的有red5，技術成本比較高。

　　至於安全性方面，針對rtmp協議，目前已經有較多的嗅探下載工具出現。如某抓、rtmpdumper等。

　　***exi.com/DigitalLibrary/Course.aspx?Id=52811。這個網站就是採用了rtmp協議，並且限制10分鐘試看時間。可以使用專業工具的嗅探功能，就可以得到rtmp地址直接觀看或下載完整影片，從而實現跳過購買流程，安全性可見一般。

　　綜上所述，對於小白使用者的防範，多半是在url上做文章，並沒有實質性的資料加密，難度都很低。從安全性的角度考慮，各大網站或平臺應當及時摒棄以上加密方式。

　　防IT技術人員

　　IT技術人員，是指具有一定的計算機基礎，會利用現成工具乃至在程式方面，有深入研究的人群。如網站管理員，程式設計師等。

　　針對該部分人群，目前業界普遍採用的防範方式，包括但不僅限於播放器校驗，url編碼加密、影片加密等。

　　 播放器校驗

　　區別於一般的校驗url地址，播放器校驗是指播放地址，只能透過特定播放器，進行域名白名單校驗才可以播放。作用主要在於防盜鏈和下載，一般直接訪問下載地址會403。

　　這種加密方式，一般可以透過對header偽造，新增referer等方式，實現403跳過校驗，實現影片下載，意義不大。

　　Url編碼加密

　　簡單來說，url編碼加密就是將播放地址自定義演算法編碼，建立私有協議的播放地址。播放需要專用的播放器進行地址解碼。

　　如某圖公考採用的某家雲平臺，就是採用這種方式。

　　**.com/cla/class_detail_62286.htm 經過除錯分析，並不能直接得到播放地址，但是可得到編碼加密的某家雲私有url。

　　bjcloudvod://Uml4e3c8NDRsZG8zf2pobHYwZ2ZxbWxngnZyNWpxcjRraTo5bzQ0PTcza2ZAZTNnajU4bGgyZz1rZ2dpb2c8bDY3Zj5BNDw5bTA0NzR6Mnp4b3JnbTB6cGtndDQ5Mzc5QDI5OmY1a2g6aGk7PWM2aUA3OTVrOzY5PWc1a2g5aWhBNGk_amBobXhbbU5dN2JzeTUzODc2ODw5ODZlPGdnOWxoOjlqNWU_PjU0aj81ODluNGdnQGVnQDhoPmZnZ2l3YmlNXDswans5

　　透過對播放器和js的分析，實現對加密的url解密，得到真實的播放地址。

　　(專用格式)

　　一般情況下，普通平臺的只要解析到真實地址就可以實現播放下載了。

　　某家雲在此基礎上，同時也對影片做了初步加密，這點做得還是不錯的。但是加密演算法過於簡單，透過解密，即可實現本地觀看。

　　3、影片加密

　　區別於對url進行處理，影片加密是對資料加密，達到即便被下載也無法播放的目的。目前比較知名的影片雲平臺，幾乎均有對影片進行加密處理。

　　Flash端多是自定義演算法，Html5大多基於HLS 協議使用或開發。

　　(一)Flash-FLV影片加密方案

　　方案一、flv部分資料加密，採用DES、AES128或其它演算法。

　　比如某網校採用的某C影片雲平臺，就是對flv的頭部資料進行加密，影片為pcf 格式。

　　**9.com/course.php?act=details&id=1317 獲取的下載地址

　　

　　由於加密的資料較少，且演算法比較單一，所以存在被解密的風險。

　　網路上已經出現了相關的解密工具。目前採用此類方案的廠商，包含但不僅限於 某C影片、某家雲等。

　　(2)flv切片加密處理，一般也是採用DES、AES128、XOR或其它演算法。

　　針對第一種flv加密方式存在的問題，如演算法單一、影片過大。更多有實力的廠商，在此基礎上最佳化、衍生出更加優秀的解決方案。

　　採用切片方式的優點較多，如載入更快速、播放更流暢、每一個資料片段都採用了加密，解密難度更高。

　　1、比如某網校採用的某雲影片雲平臺，演示地址

　　**63.com/front/homepage!showSellWayInfo.action?queryAssessCondition.currentPage=1&querySellWayCondition.sellId=40

　　經過分析可以得到片段地址，每一段均是加密的smf檔案，地址存在規律性

　　

　　

　　

　　經過分析，其實每一段都是flv片段，進行了簡單的加密。由於分片演算法比較單一，存在不足，所以還是可能被解碼合併的。

　　2、某某威視也採用flv切片加密技術，其演算法更復雜，並會自動升級，目前市面上沒有對應的解密方案

　　目前採用此類flv最佳化方案的廠商，包括但不僅限於某量、某山(某雲)等。

　　(二)HTML5-HLS影片加密方案

　　鑑於flash跨平臺的相容性問題及漏洞，越來越多的廠商更加青睞在H5作影片加密方案，同時實現pc及移動端的影片保護。目前較為廣泛採用的是apple hls 協議。

　　HLS協議理論可以參考該類文章http://blog.csdn.net/jwzhangjie/article/details/974402

　　目前hls協議的使用，包含了原生協議和自定義最佳化兩種。

　　(1)原生hls協議

　　Hls協議天生的優勢，使得大部分廠商便可以直接採用，並未做任何處理。但由於協議的公開性，目前網路上已經有對應的解密方案，其中不乏傻瓜式工具類。如ffmpeg。

　　比如該網站採用的某訊雲平臺，**x.com/course/detail?goods_id=269

　　透過簡單除錯，得到對應的m3u8地址，再利用ffmpeg命令列便可實現下載。

　　251150518.vod2.myqcloud.com/4149f144vodtransgzp1251150518/c6fdf3479031868223044654629/KXN2BbJnqicA.f230.m3u8 命令列大致如下

      目前採用該協議的廠商，包括但不僅限於某訊雲、某c影片、某寶影片等。

　　(2)基於hls協議最佳化

　　針對hls協議的問題，部分對技術有追求的廠商，便推出了一些最佳化處理方案。當然hls影片的洩漏，主要還是金鑰的洩漏，所以最佳化均是圍繞AES128金鑰的保護入手做處理。

　　1、某某soho採用了金鑰混淆錯序的方式。將原本的16位元組金鑰處理為20位元組，透過播放器進行復位解碼。該演算法容易被猜測出混淆錯序規則，存在一定的風險。

　　以某某soho官網的課程為例***soho.com/open/course/2

　　經過除錯分析，可以得到對應的m3u8索引文字，採用了氣球雲端儲存，***soho.com/hls/3182/playlist/XZA3vMgVaxNQFagdbte5t8ORCfX0tC5e.m3u8

　　各個清晰度m3u8採用了編碼加密，有時效性，僅能訪問一次，防範做的還是不錯的。

　　可以看到影片採用了AES128的加密演算法。金鑰的地址，第一次訪問的時候，是20位元組，“f8864726x4r6f34w4r36”，其後每次訪問都是不同的16位元組。

　　其實真實的秘鑰，就藏在了第一次的20位元組裡面，之後的16位元組都是假的秘鑰。

　　我們需要從20位元組中找到真實秘鑰，從而實現解密。具體演算法不做闡述。

　　2、某某威視目前針對hls做了兩種最佳化方案，分別是web授權和app授權。

　　(1)Web授權

　　介紹：為了相容微信平臺和web頁面，採用了sign校驗，一次訪問即失效。有效防止盜鏈和下載。

　　該方式與某soho方案類似，透過對m3u8地址，進行sign計算校驗，並增加了時效性，不排除被猜測規則，偽造下載地址的可能性。

　　(2)App授權

　　介紹：採用伺服器校驗和傳輸金鑰，將原本的16位元組加密處理為32位元組，SDK授權解密進行解碼。

　　這種方式是對金鑰key資料本身進行加密處理。目前尚無解密方案出現，安全級別極高。當然隨著時間的遷移，不排除以後有對應的解密方案出爐。

　　目前基於hls協議進行最佳化處理的廠商，包括但不僅限於某某威視、某soho。

以上內容為筆者整理相關資料合成見解，部分資料參考第三方或官網文件。

連結：
來源：站長之家