在短视频源码开发中，移动端音视频加密、防盗播实现方案

最新推荐文章于 2024-04-07 04:42:43 发布

云豹科技程序猿

最新推荐文章于 2024-04-07 04:42:43 发布

阅读量1k

点赞数

分类专栏：短视频系统源码

原文链接：https://segmentfault.com/a/1190000021126567

版权

短视频系统源码专栏收录该内容

59 篇文章 4 订阅

订阅专栏

为了增加平台及用户的盈利方式，有些短视频源码在开发设置了短视频查看的付费功能，要想保证该功能的正常使用，就需要对移动端的音视频进行加密、防盗播处理，今天我们就一起来看看在短视频开发中，移动端音视频加密、防盗播实现方案吧。

注意：保证用户体验是前提。否则再好短视频源码，用户体验垃圾，也无法发展。

如今市面上，移动端加密、防盗播的方式很多。这里只是讨论一种：我认为的用户体验较好，技术实现成熟，又有效防盗播的方式。

注意：防止盗播，并不能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 加上短视频源码加固，在实现上应该是比较安全了

以上就是“在短视频源码开发中，移动端音视频加密、防盗播实现方案"的全部内容，希望对大家在短视频开发时能有帮助。

云豹科技程序猿

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
在短视频源码开发中，移动端音视频加密、防盗播实现方案

为了增加平台及用户的盈利方式，有些短视频源码在开发设置了短视频查看的付费功能，要想保证该功能的正常使用，就需要对移动端的音视频进行加密、防盗播处理，今天我们就一起来看看在短视频开发中，移动端音视频加密、防盗播实现方案吧。注意：保证用户体验是前提。否则再好短视频源码，用户体验垃圾，也无法发展。如今市面上，移动端加密、防盗播的方式很多。这里只是讨论一种：我认为的用户体验较好，技术实现成熟，又有效防盗播的方式。注意：防止盗播，并不能100%杜绝盗播。只能不断增加短视频源码的破解成本，完全无法破解的短视频源码
复制链接

扫一扫

专栏目录