以下爲幾種常用的視頻加密技術，我們這次的測試平臺採用的是第二種，第三種方式主要依靠專用播放器來解決數據交到客戶端的這一環的安全性，但是專用播放器帶來了使用不便的兼容問題。
1、防盜鏈技術：這種嚴格來說，不屬於視頻加密，只是想辦法防止視頻被下載，只允許在線播放。但這種基本上來說屬於防一般用戶，很容易被繞過去。因爲你只要讓瀏覽器可以播放，別人就可以僞裝自己是瀏覽器，拿到url，進行僞裝瀏覽器的各種referer等信息，欺騙過防盜鏈系統，下載到視頻。
2、HLS加密技術：也可以稱之爲m3u8切片加密，這種是目前H5時代廣泛使用的技術，該加密本身是很安全的，基於AES加密算法。但有個致命的問題：別人很容易拿到祕鑰進行解密。這種方式最大的優點是：幾乎主流瀏覽器都支持，包括微信、qq等，打開就能播放，兼容性很好。缺點也很明顯：
因爲算法是公開的，並且如果不保護好祕鑰文件，ffmpeg等命令行、很多工具軟件，均可拿到祕鑰對視頻基本還原，如果只是採用單純的HLS加密技術，可以說：極其不安全。幸好，近幾年國內很多廠商在標準HLS加密的基礎上，對m3u8文件中的祕鑰等做了防盜處理，這種二者結合，效果就好很多。
3、視頻文件內容採用私有算法真正逐幀加密：這種方式一般是基於不公開的算法，對視頻文件、直播流、m3u8中的ts數據等，均可實現實時逐幀加密。但加密後的視頻，需要專用特定播放器纔可以播放。由於採用私有算法，因此其他播放器無法進行播放，增強了安全性。但也帶來了一定不便利性，就是必須安裝專用軟件。不過這類技術就比較考驗加密實力了，目前很多加密軟件號稱加密，但某寶等平臺隨便一搜，也有很多破解。因爲，即使你用了專用播放器，但如果別人很容易逆向你的播放器，也就知道了加密算法，所以需要開發公司有多年深厚的研發實力纔可以放心。
https://www.zhihu.com/question/24561177/answer/1191234975
首先打開視頻平臺視頻連接，打開瀏覽器調試窗口查看視頻連接，可見是 EduSoho 氣球雲提供的播放方案，HLS 流媒體視頻格式，使用 VLC 打開視頻地址並不能直接播放，視頻地址內容是加密的。
進一步查看 m3u8 文件內容可以看到，視頻切片內容使用了 AES-128加密，解碼需要 iv (偏移量），key (祕鑰），m3u8 內 EXT-X-KEY,URL 記錄了祕鑰的獲取路徑，而打開此網址是需要 cookie 鑑定訪問者身份的，且可以在平臺後端控制用戶的祕鑰過期時間，到此爲止，仍然還是安全。
接下來，進行進一步的測試，對於普通 HLS 格式視頻，使用 ffmpeg 可以直接下載轉爲 mp4 格式，但是案例這種加密視頻是不可以的，需要對下載下來的視頻切片進行解碼。
ffmpeg -i https://embed-fastly.wistia.com/deliveries/bde18e17ca5ff78ec940fc82c76ed6194f4f7886.m3u8 wistia.mp4通過 m3u8 內獲取到的 iv , 和祕鑰嘗試解碼失敗，說明 iv , key 祕鑰保護變形過，並不能直接使用。
openssl aes-128-cbc -d -in fileSequence0.ts -out fileSequence0_decrypto.ts -nosalt -iv *** -K ***祕鑰已經下發給瀏覽器客戶端，那麼解密的工作一定是在瀏覽器內通過 Javascript 完成的，由於 Javascript 的透明性，這裏的加密算法並不安全。
打開調試查看調用的 js 文件，可以看到有 氣球雲（EduSoho) 的播放器 SDK。
打開 js文件查看，是經過 webpack 打包過的，原文件的路徑仍然可見，"/src/crypt/decrypter.js" 看起來就是解密算法所在。
定位到相關函數 ，可以看到是對祕鑰進行過一系列的操作換出來的，對視頻切片解碼後操作 Dom 把播放內容推給播放器。
由於打包加密過的 js 代碼，變量都被換過，調試起來非常困難，解讀跟蹤代碼來獲取解密算法的方式理論上可行，但是花費的時間很難預估，會讓很多人知難而退，前端對祕鑰的加密算法的目的基本也達到了。
繼續進行下一步之前，我們注意到 氣球雲的播放器 SDK 的 js 文件未採用 https 加密傳輸，那也就意味着可以被劫持後 插入調試代碼，破解將變得更加容易，如圖，我們通過反向代理+hosts 文件修改的方式將目標 js 文件劫持到本地文件，插入調試代碼。
現在最簡單方式是直接獲取解密後的切片內容，不理會解密過程。
從原代碼可以看到視頻內容的解密是在瀏覽器 ServiceWoker 內進行的， 這裏並不能操作 dom 還不能很方便的將解密內容取出來。
可以看到，解密後 ServiceWoker 通過 postMessage 發解密內容給主進程，我們接下來只有 添加監聽器截取對應時間和內容。
並將解密的內容放到全局變量內 window._files 。
-
t.onWorkerMessage = function(e) { -
-
if (e.data.event=="hlsFragParsingData" && e.data.data.type == "pureData" ) { -
var _files = window.files || {} -
_files[e.data.data.sn] = e.data.data.data; -
window.files = _files -
console.log('sn', e.data.data.sn,Object.keys(_files).length, Math.round(Object.keys(_files).length/6)+" mins"); -
window.sn = e.data.data.sn -
} -
... -
}
最後使用 window.saveAs('xx.ts') 下載合併後的視頻文件。
-
window.saveAs = (filename) => { -
var blob = Object.values(window._files) -
if (window.navigator.msSaveOrOpenBlob) { -
navigator.msSaveBlob(blob, filename) -
} else { -
const link = document.createElement('a') -
const body = document.querySelector('body') -
link.href = window.URL.createObjectURL(new Blob(blob, {type: "application/zip"}))\ -
link.download = filename -
-
link.style.display = 'none' -
body.appendChild(link) -
-
link.click() -
body.removeChild(link) -
window.webkitURL.revokeObjectURL(link.href) -
} -
}
可以看到，雖然視頻最終下載了，但是需要一點的前提條件 比如 http 不安全協議，逆向加密算法的時間成本等。
視頻保護問題的根本是總有那麼一個環節你要將視頻真實數據交給客戶端，這個環節是平臺控制的更多還是客戶自己控制的更多，決定了效果。 強如 DRM 數字版權保護的方案，設置了很多限制條件比如播放時必須在線、解碼是在專用硬件是解密的，但是數據總要給顯示器的，所以仍然存在 hdmi、wifi投屏 的盜錄方式。
安全是相對的， 目前能做的只能是增加破解者的成本。
改進前景：瀏覽器端加密 WEBASSEMBLY
WebAssembly（縮寫WASM）是一種安全，便攜，低級代碼設計用於高效執行和緊湊表示的格式。
它的主要目標是使Web上的高性能應用，不需要針對網絡的特定假設或提供特定的定製化的網絡功能，因此它可以在其他環境中直接使用，也就是良好的跨平臺特性。 WebAssembly是由W3C社區組開發的開放標準
WebAssembly在性能及加密場景的深度探索