在FLV文件结构一文中，我们已经了解了FLV文件的大致结构信息，同时在FLV文件校验一文中，我们可以完成对FLV文件的完整性进行校验。此文在这两篇文章的基础上尝试进行更深入一些的探讨——对FLV文件进行加密和解密操作。
在互联网时代，资源的分发已经变得非常容易，FLV也不例外，对于资源的版权方来说，分发难度的降低一方面降低了自身资源的传播成本，另一方面却由于没有良好的防止非法分发而带来对自身的利益侵害。稍稍驻步，我们就能看到已经有很多为保护版权而创造的各种方法，CSS。AACS，Key 2 Audio，Always-Online等等。本文作为保护FLV来说，也算是一种尝试，在实践中，灵活的使用也可一定程度保护资源的非法传播。下面让我们来简单聊聊：
Mitchell Chu 注：以下方法名称并非“官方”说法，而是自创，请注意！
第一式： 反位
反位的方法算是最基础的加密方式，原理就是将二进制中的比特位全部取反（注意：不是反码，是特定的异或操作）。代码如下：
byte GetReverse(byte b)
{
return (byte)(b ^ 0xFF);
}
byte Encrypt(byte data)
{
return GetReverse(data);
}
byte Decrypt(byte data)
{
return GetReverse(data);
}
加密：
对每个字节进行操作之后，我们就能得到一个被加密的新的FLV文件，此时，FLV文件的Header，Tag之类的已经全部被抹掉了，剩下的就是一堆数据而已。
解密：
解密此文件的方式非常简单，仅需要对FLV重新再来一遍异或操作即可得到原始文件。
优缺点：
这种加密解密方法的优点是，简单的没有负担，无需任何高达上的算法，不需要复杂的操作。但缺点是，只要有原始文件对比后，基本瞬间能了解加密算法，破解难度很低。
说明：
这种方法并非一无是处，相反，操作的恰当，还是有可为之处，比如，我们仅对某些敏感数据进行操作（哪些是敏感的？可以在FLV文件结构一文中找找：P），那么，在表面看起来这是一个完整（也可以是不完整）的FLV，但得到数据，没有得到具体算法的人拿到FLV也不再那么容易发现数据的加工之处。播放之时，却会因为数据的错误导致播放失败。
说到这里，看到网上曾经有了对FLV的加密方式是对每个字节进行-128，在此表示怀疑：此方法能否保证加密后的数据是真的能够被安全还原么？
第二式：对称加密
对称加密这个方法的原理是让合法用户在请求之后，系统同时发送解密密码，这样，用户在获得FLV资源的时候，同时拥有一个匹配的密码，这样，在播放之前，可以通过这个密码来得到正常的FLV源文件。
这个方法的实现种类很多，这里就不放出代码，只要是对称加密方式均可用在此处。
加密：
初始化密码，而后用对称加密算法+密码对FLV文件进行加密，得到加密后的FLV文件。
解密：
获得密码，而后用相匹配的对称加密算法+密码来完成对FLV的解密，得到正常的FLV文件。
优缺点：
如果不嫌事多，可以达到一人一码或者说一机一码（广告词啊，这是），但劣势也明显，一旦获得一次密码，也就丧失了对FLV的控制权，因为解密后，就是FLV原始文件嘛——所以，很多时候，要隐藏机密算法。
说明：
稍显复杂的一个算法，但在使用配套的客户端（Flash Player/PC 播放器等），还是能够比较好的完成对FLV的保护工作的，不同重点的防护是对自身加解密算法和FLV对应文件密码做保护，同时还得顾虑到解密的文件处理方式。
恩，本来还有第三式的，但还是到此为止吧，以免贻误众生。
使用上面的加密解密方法基本上已经能够完成对FLV的保护，当然，要保护FLV也不一定要使用加密方式，当年的Key 2 Audio不是通过创造多余的数据区来达到毁灭消费者的光驱么。
本人并不是积极的DRM（数字版权管理）拥护者，个人觉得适当保护对版权所有者，正版消费者有一定的益处，但过度的保护反而会让版权者迷失，而失去精进的动力，陷入过度的依赖DRM，反而可能会伤及正版消费者利益，比如：Online-Always的DRM，当年刺客信条的正版用户体验竟然不如盗版 。