为了增加平台及用户的盈利方式,有些短视频源码在开发设置了短视频查看的付费功能,要想保证该功能的正常使用,就需要对移动端的音视频进行加密、防盗播处理,今天我们就一起来看看在短视频开发中,移动端音视频加密、防盗播实现方案吧。
注意:保证用户体验是前提。否则再好短视频源码,用户体验垃圾,也无法发展。
如今市面上,移动端加密、防盗播的方式很多。这里只是讨论一种:我认为的用户体验较好,技术实现成熟,又有效防盗播的方式。
注意:防止盗播,并不能100%杜绝盗播。只能不断增加短视频源码的破解成本,完全无法破解的短视频源码是不存在的。所以,想100%防止盗播也是不可能实现的。
一、实现方案
这里采用的方案是:客户端播放AES-128加密的m3u8媒体资源
为什么是m3u8 ?
- m3u8采用AES-128对称加密算法加密,技术成熟稳定
- 前边说了,保证短视频源码用户体验为前提
短视频源码音视频播放过程中,用户进入播放页后,音视频的秒开率(1秒内成功加载的播放数/播放总数)是影响用户体验的重要指标;m3u8媒体资源是一个文本文件,其由一个个ts视频片段的播放地址构成,选择合适的ts切片大小,能有效提高音视频的秒开率,保证用户的观看体验。
用户体验的大前提满足了,那如何实现呢?
- 客户端播放的视频源为 AES-128对称加密的 m3u8 媒体资源;
播放地址最终组织形式如下:
https://domain/course101.m3u8?playKey=i_am_decrypting_key101
- 播放地址 https://domain/course101.m3u8 与playKey 需从服务端获取;
加密m3u8的解密关键就在于playKey,因此,防止playKey被破解是防盗播的一个关键点 - 将最终播放地址交于播放器播放
二、实现举例
对于m3u8媒体资源,无论是 视频切片加密、ts视频片段解密播放 在技术实现上已经非常成熟,不存在技术壁垒,实现已经不是问题。
那么摆在移动端最主要的问题就是:防止短视频源码媒体资源被盗播,维护内容生产者的利益
注:虽然技术实现已经不是问题,但这里还是会把 移动端技术实现的细节和 防破解(防盗播)的实现细节进行呈现。
技术实现上,大概分为以下几个步骤:
- 获取短视频源码媒体资源播放地址
- 获取媒体资源的解密token (playKey)
- 拼接最终播放地址,播放m3u8媒体资源
下面我们从短视频源码移动端请求音视频内容列表,到成功播放的全过程来举一个例子:
1、获取ID为101的音视频内容列表
首先通过音视频ID 101向服务端发起请求,获取该音视频的内容列表。请求方式和返回结果如下:
a、发起请求:
https://domain/xxx/getCourseList.do?courseId=101
为了简单易懂,这里简单模拟一个get请求:
- 请求参数 courseId 为 101;
- 请求地址为 https://domain/xxx/getCourseList.do;
- 获取id为101的音视频,其对应的内容列表。
b、返回结果:
音视频101的音视频内容列表如下:
[
{ "mediaId": "101", //媒体资源id
"mediaUrl": "n3GuNo5Rc44anmLGrRU8Rne/JU9cHzc1vXZWiYEwcD0=", // 媒体资源的m3u8播放地址
"encryptId": "LLVahEH+HjZEOJk6RfJtww==" // 获取媒体资源playKey的encryptId
},
{ "mediaId": "102", "mediaUrl": "n3GuNo5Rc44anmLGrRU8RlKQGcM3X5R3oVqpuCrTpDk=", "encryptId": "Ez3wHHWx5ddq+D2miV2dFg=="
},
{ "mediaId": "103", "mediaUrl": "n3GuNo5Rc44anmLGrRU8RqLaIqPDWyZQ5VotuUSyNI8=", "encryptId": "R5a31ZJIy9Z5+tNPplxHLQ=="
}
]
正如注释中写的:
- mediaId 是媒体资源id ;
- mediaUrl是媒体资源的m3u8播放地址;
可能会疑问: n3GuNo5Rc44anmLGrRU8Rne/JU9cHzc1vXZWiYEwcD0= 是什么鬼,为什么不像播放地址?
这里正是防止媒体资源被盗播,维护内容生产者的利益的 第二步
这里将资源地址https://domain/course101.m3u8进行了一个简单的AES加密
对于其资源地址的加解密,会在下文进行详细说明。
- encryptId 则是 用于获取媒体资源的解密playKey。
encryptId的具体作用,会在下文中详细说明
注:这里服务器要做一个用户权限的校验:未购买用户不返回其 mediaUrl 和 encryptId
c、未购买用户的返回结果:
未购买用户不返回其 mediaUrl 和 encryptId
正是预防短视频源码移动端被不良用心的人员,恶意采用Http抓包进行破解。是防止媒体资源被盗播,维护内容生产者的利益的 第一步,也是很重要的一步。 因为:
- 短视频源码移动端无论如何防破解,总不能100%保证无法破解;
- 想要获取播放地址,必须购买音视频内容,对于用心不了的人员,增加了其破解成本;
未购买用户,通过音视频ID 101向服务端发起请求,返回数据如下:
[
{ "mediaId": "101", "mediaUrl": "", "encryptId": ""
},
{ "mediaId": "102", "mediaUrl": "", "encryptId": ""
},
{ "mediaId": "103", "mediaUrl": "", "encryptId": ""
}
]
注:未购买用户,请求某音视频列表接口时,不要返回 媒体资源的m3u8播放地址 和 获取媒体资源playKey的encryptId。这很重要
d、mediaUrl与encryptId解密:
为防止移动端短视频源码被Http抓包,mediaUrl 与 encryptId 都不是明文传输的。因此移动端拿到课程的内容列表后,首先需要对mediaUrl 与 encryptId进行解密。
关于解密:
- 对称加密算法,大家可以根据实际需求,自行进行选择;
- 解密相关代码,建议由C语言实现,打成SO添加到移动客户端中;
原因是增加短视频源码移动端破解难道,提高破解成本。
这里只是采用了简单的AES对称加密:
在这里插入图片描述
完成解密后的数据格式如下:
[
{ "mediaId": "101", //媒体资源id
"mediaUrl": "https://domain/course101.m3u8", // 媒体资源的m3u8播放地址
"encryptId": "qazwsx101" // 获取媒体资源playKey的encryptId
},
{ "mediaId": "102", "mediaUrl": "https://domain/course102.m3u8", "encryptId": "qazwsx102"
},
{ "mediaId": "103", "mediaUrl": "https://domain/course103.m3u8", "encryptId": "qazwsx103"
}
]
2、获取 playKey
在第1步中,已成功获取到媒体资源的播放地址 https://domain/course101.m3u8与encryptId。为了播放短视频源码媒体资源,下面来获取到加密m3u8视频的解密playKey
这里 playKey 仍然需要从服务端进行获取,获取方式如下:
模拟请求
发起请求:
https://domain/xxx/getMediaToken.do?encryptId=C0AFC0A81&mediaId=101
返回结果:
{ "playKey": "I_am_playkey_001"}
这里仍然模拟一个简单get请求:
- 请求参数 encryptId 为 qazwsx101;
- 请求参数 mediaId 为 101;
- 请求地址为 https://domain/xxx/getMediaToken.do;
注:playKey是加密m3u8解密的关键,是防止短视频源码媒体资源被破解的重中之重。
关于 playKey 加密
这里是防止媒体资源被盗播,维护内容生产者的利益的 第三步和第四步
1、playKey 服务端需加密传输;
2、请求getMediaToken.do接口时,短视频源码服务端需对该用户的购买状态进行验证,未购用户不返回其对应的playKey;
3、移动端获取到playKey后,在SO(C层代码达成的)中对playKey进行解密;
4、解密后的playKey存在一定的过期时间;或者使用次数限制(建议服务端限定只能使用一次)
加密算法要与mediaUrl 和encryptId 的解密算法区分开,增加破解成本
3、拼接播放地址
经过以上步骤,购买用户成功获取到 播放地址 https://domain/xxx/getMediaToken.do和解密key I_am_playkey_001。
将mediaUrl 与playKey 拼接起来,可以交给播放器播放了:
https://domain/course101.m3u8?playKey=i_am_decrypting_key101
到此,移动端的工作完成。
OK. 移动端完事大吉。
到这里短视频源码播放器与服务端的交互刚刚开始。
这里有必要先介绍一下,加密m3u8视频的文件格式:
加密m3u8视频的文件格式
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:19
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-KEY:METHOD=AES-128,URI="http://domain//hls.key"
#EXT-CUSTOM-YUNXIN:ntsversion=0,ntsprivatedata=d68edb4f4ee3c64233b1ece785758291727d053d
#EXTINF:11.960000,
http://domain/encrypt0.ts
#EXTINF:9.200000,
http://domain/encrypt1.ts
#EXTINF:10.000000,
http://domain/encrypt2.ts
#EXT-X-ENDLIST
以上为加密m3u8视频的文件格式:
- 短视频源码播放器在播放前,会用该地址 http://domain//hls.key向业务服务器发起请求,请求加密m3u8视频的解密秘钥;
解密秘钥如下图所示:
加密m3u8视频的解密秘钥并非playKey=i_am_decrypting_key101,而是一个16字节的文件。
m3u8的解密秘钥实际是一个16字节的文件。
这里肯定会有很多疑问,别着急,我们继续前边的话题播放器与服务端交互。
播放器 与 服务端 交互
- 当 播放器 向 服务端
发起https://domain/course101.m3u8?playKey=i_am_decrypting_key101 请求后; - 服务端 处理相对复杂
a、首先校验playKey=i_am_decrypting_key101是否有效;
b、若有效则将加密m3u8视频中的http://domain//hls.key更换为http://domain//hls.key?playKey=i_am_decrypting_key101;
c、下发m3u8文件给播放器;
- 播放器收到服务端下发的加密m3u8文件后:
a、播放器读取加密m3u8文件,获取解密秘钥的请求地址http://domain//hls.key?playKey=i_am_decrypting_key101;
b、播放器向服务端发起 http://domain//hls.key?playKey=i_am_decrypting_key101请求,请求解密秘钥;
- 服务端收到播放器的请求后,需对playKey=i_am_decrypting_key101进行校验,查看是否过期或者被使用过,若存在异常则不下发秘钥;若正常,则下发秘钥
- 播放器收到秘钥文件后,正常播放;
OK. 这次是真的 完事大吉。
4、移动端加固
如果仅仅做到上一步就结束了,短视频源码移动端被破解的概率还是很高。因为SO任然可以被反编译破解,而且SO的反编译技术也已经相当成熟。
所以,无论在SO中采用了怎样复杂的加密算法,SO被反编译后,还是有被破解的可能。
因此,以上步骤都完成后,我们仍然要对我们最终生成的短视频源码进行一次加密。Android端推荐采用短视频源码加固处理。
5、SO动态下发,定期更新加密算法
以上步骤都做完,如果短视频源码仍然被破解了。我们可以再加一层防破解处理:动态下发SO,定期更新加密算法。
这样就算线上短视频源码被破解了,也可以在不发版的情况下从容应对,更新一下加密算法就可以了。
三、总结一下
这里来简单总结一下,上边介绍的实现步骤 :
a、移动端拿 courseId 向服务端发起Http请求,获取课程的内容列表;
b、服务端对用户进行权限验证,未购买用户不返回其对应的播放地址;
c、移动端在SO层中对 mediaUrl与 encryptId 进行解密;
d、移动端 用解密后的encryptId,向服务端请求对应媒体资源的 playKey
e、服务端对用户进行权限验证,未购买用户不返回其对应的 playKey;
f、移动端 在SO层中对 playKey 进行解密;
注意,一定要与第三步的解密算法区分开
g、拼接mediaUrl 与 playKey ,交给短视频源码播放器播放;
到此,移动端工作完成。
h、播放器向服务端发起下发m3u8请求
i、服务端校验playKey;并动态替换m3u8中的URI字段
j、播放器从m3u8文件中取出URI字段后,向短视频源码服务端请求解密秘钥;
k、服务端校验playKey;并返回解密秘钥文件;
l、播放器播放
到此,加密m3u8 终于播放出来了。
m、移动端短视频源码加固处理;
n、为增强破解难度,这里解密SO可由动态下发,定期更新加密算法;
m、如果仍然担心短视频源码被破解,服务端下发的解密秘钥文件可以设置为非明文状态;客户端拿到解密秘钥后,以本地代理的方式设置给播放器进行播放。
注:这里有三个关键步骤:1、服务端对用户进行权限验证,未购买用户不返回其对应的播放地址;2、移动端 在SO层中对 playKey 进行解密;3、移动端App加固处理。
这三个关键步骤缺一不可,缺少任何一个移动端的破解难度和成本都将大大降低。
- 未购买用户不返回其对应的短视频源码播放地址
可以极大的降低付费音视频内容被大面积破解的情况出现。因为购买音视频内容亦需要成本。破解的音视频内容越多,那需要购买的音视频内容就越多,破解成本也就越高。
- 在SO层中对 playKey 进行解密
对于加密m3u8媒体资源,破解的关键就在于playKey,因此playKey的加密算法应足够的复杂
- 移动端短视频源码加固处理
移动端短视频源码加固,是移动端代码反编译非常重要的一环。如果没有这一环在SO层中对 playKey 进行解密的作用不是很大,因为无论SO中加密算法如何复杂,只要SO被翻遍后,再复杂的加密算法也没有意义了。
以上为全部处理流程
如果以上步骤都做了,付费音视频被盗播的可能性应该不大;但仍然存在Http抓包的可能性:
- http抓包时,会抓到https://domain/course101.m3u8?playKey=i_am_decrypting_key101请求
由于playKey只有一次使用有效,或者几个小时的超时时间。因此该内容无法被大规模传播;
- http抓包时,会抓到短视频源码播放器的秘钥下发请求
http://domain//hls.key?playKey=i_am_decrypting_key101;
由于服务端存在playKey有效性的校验,下次使用失效,因此也无法大规模传播;
如果对服务端明文秘钥文件下发存在疑虑,可以做以上流程图的“防盗播9”;
- 防盗播9 加上短视频源码加固,在实现上应该是比较安全了
以上就是“在短视频源码开发中,移动端音视频加密、防盗播实现方案"的全部内容,希望对大家在短视频开发时能有帮助。