本文乃Siliphen原创，转载请注明出处：http://blog.csdn.NET/stevenkylelee
本文针对的是cocos2d-x 3.4 版本进行研究。
首先，加密解密应该是一个单独的话题，一般不会涉及具体使用的引擎、框架和技术。
加密算法有Base64，DES等。
Base64的原理类似于凯撒密码，啥是凯撒密码呢，就是一个字符用另一个字符来代替。
比如：a用i代替，b用k代替，以此类推。加密和解密的过程就是一个互相映射的过程。
DES是一种使用密钥的加密算法。
DES和Base64这种无密钥的算法在使用上的区别是：
DES算法本身是可以不保密的，只要保密密钥即可，密钥才是解密的关键。
Base64如果用于加密的话，算法本身就是密钥。要保密算法。
MD5，SHA等是摘要算法。
Base64，DES都可以把密文还原出明文。
而MD5，SHA则不能对算法作用后的输出还原出原始数据。
摘要算法一般做身份验证。
我们做资源加密是要选择能把密文还原出明文的算法。
这属于密码学的内容了，可深可浅。
可以借鉴凯撒密码的原理自己对每个字节的内容进行映射来加密。
也可以对1字节，2字节，4字节的数据，用某个数进行异或运算来加密。
异或的特性是，用数A对内容B进行异或得到内容C，再用数A对内容C异或可以得到内容B。
这个特性可以被用来加密。同时，数A的作用就是密钥了。
设计的加密算法不同，加密算法的使用的接口也不同。
如果是用上面的2种思路做加密算法的话，加密算法的实现可以“in place”操作，
就是可以直接在密文所在的内存进行解密，不单独分配内存来保存解密后的数据。
如果加密算法很复杂，无法“就地还原”，就需要新申请内存来保存解密数据。
当然，执行速度一般是”就地还原“快。
我觉得，如果可以的话，最好是自己设计加密算法。
使用现成的DES之类的算法，密钥是关键。
如果是自己设计一个用密钥加密的算法，密钥和算法本身都是不公开的。
破解者要获取资源明文要经过如下步骤：
1.在程序中找到密钥的常量。
2.看懂反出来的汇编还原出算法，或者想办法利用加密算法的汇编代码。
其中步骤2会加大解密者解密的难度，这是自己设计加密算法比用现成的DES之类著名算法的好处。
我见过有一些人加密是对字段内容进行加密。
比如，他用xml保存数据，他只对保存的值进行加密。
内容类似这样 <Entity Hp = "密文" AttackValue = "密文" >
这并不是一种好的运用加密的方式，因为这种方式会：
1.透露程序的配置文件结构。XML、json等。
2.透露了程序可能使用的数据结构。看以上内容可猜想Entity实体类有2个字段，Hp（血量），AttackValue（攻击力）
更彻底的加密方式是，对整个xml、json等文件进行加密。
这样别人就不会知道关于你的数据的一丁点信息。
这种做法不是直接用数据解析库封装的类似LoadFile的函数直接读取文件。
而是，先把加密文件用文件读取方法读入内存，在内存解密后，再把解密数据传给解析库的解析函数。
这种做法要求解析库有对内存进行解析的接口。
比如，若用XML解析库，就会弃用LoadFile，要求有Parse方法。
有一种情况可能无法对整个数据文件进行加密。
就是使用sqlite等数据库的时候，这时候只能对字段进行加密了。
有些人设计加密机制会要求配置程序本身。
比如：程序需要一个配置（一个开关变量或者条件编译）来决定是否对资源进行解密。
发布时，把资源都加密好，开启程序对资源的解密。
开发时，资源不必加密，屏蔽程序对资源的解密。
这种做法需要来回设置解密开关，比较繁琐。
有一种实现思路更有扩展性、更灵活、使用更方便。
那就是自己设计文件头。
熟悉Win32编程的人可能会知道PE文件格式。
Windows运行一个exe之前，会检查PE文件头，
取得EXE文件的数据常量、代码区块等信息后，系统才能正确执行一个EXE。
我们可以设计一个加密文件头，加密文件头有一个字段标识该文件是否是被加密过的。
解密算法可以通过判断加密头的标识符来决定是否进行解密、采用哪种解密算法等。
这是一种数据驱动式的解密机制，解密信息都保存在加密数据本身中。
对于没有被加密过的数据，程序判断没有文件加密头标识，就不执行解密。
这样，程序可以同时读取未加密的数据和已经加密的数据，而不需要对程序进行任何修改。
注意：加密头的标识符应该足够特殊，保证和未加密的数据不会产生冲突。
若未加密的数据刚好出现了加密头的内容，那么程序就会对未加密的数据进行解密。
我的项目配置是用CSV文件。解析器，用的是我自己写的CSV解析器：
《CSV文件格式解析器的实现：从字符串Split到FSM》
在游戏中这部分的解密，比较容易实现，就是对整个文件加密，
游戏启动时把加密文件读入内存进行解密，然后把解密数据传到解析器进行解析。
一些由游戏产生的需要保存的数据，我用XML进行保存。加解密思路也如上。
但是，对于图片、动画，粒子、cocostudio1.6导出的UI 等数据，加密就不那么简单了。
因为，像 Sprite::create 这样的接口，并没有提供一个从内存获取纹理数据来初始化精灵的方式，
而是直接从磁盘文件中读。用户在外部是无法干预文件数据的读取载入的。
游戏资源的加密要怎么做？——只有修改引擎了。- -！
我觉得，修改引擎并不是一个好的做法。
引擎应该由引擎提供商来维护，而不是靠用户自己来动手。
用户自己动手会造成项目维护升级困难。
自己把引擎改得乱七八糟，想升级引擎到新的版本会变成很麻烦。
就算是修改了一点，升级引擎版本一次，就要做一次修改，这样也很麻烦。
要修改引擎，首先要跟踪调试，
以cocos2d-x 3.4 作为试验版本，从Sprite::create入口，一步步跟下去，
看看引擎是在哪里载入文件数据的。
经过调试跟踪，Sprite::create的调用堆栈如下：
getData
FileUtilsWin32::getDataFromFile
Image::initWithImageFile
TextureCache::addImage
Sprite::initWithFile
Sprite::create
在windows上，精灵载入图片，是调用到了
CCFileUtils-win32.cpp 这个文件中的
static Data getData(const std::string& filename, bool forString) 函数。
这个函数是一个非类成员静态函数。
再调试下其他的数据载入，cocostudio1.6做的动画的调用堆栈是：
cocos2d::FileUtilsWin32::getFileData cocostudio::DataReaderHelper::addDataFromFile cocostudio::ArmatureDataManager::addArmatureFileInfo
经过了多种文件类型载入的跟踪调试后，总结，
基本上文件的载入函数有2个，都在CCFileUtils-win32.cpp文件中，
1.FileUtilsWin32::getFileData
2.getData
要做解密的话，就是修改这2个函数了。
值得注意的一点是：getData函数的签名是：
static Data getData(const std::string& filename, bool forString)
forString这个参数，用于标识读入的文件是不是一个文本文件。
如果forString为真的话，buffer就要多分配一个字节，用来放置C语言的字符串结束符 \0
截图一下引擎的代码：
要做解密，我们的解密数据内存也要用forString来判断是否多分配一个字节的内存。
FileUtils单件类，很多函数是虚函数。FileUtils::getInstance，
在Windows平台上，返回的是 FileUtilsWin32子类对象。
在Android平台上，返回FileUtilsAndroid子类对象。
Cocos2d-x 3.4 实现在Windows和Android平台上的解密需要修改2个文件：
Windows 平台的：cocos\platform\win32\CCFileUtils-win32.cpp
Android 平台的：cocos\platform\android\CCFileUtils-android.cpp
这2个文件里面都有 getData 和 getFileData 函数，都需要修改之。
文件数据的读取在不同平台上有不同的实现，
如果要在目标平台上做资源加密，就需要修改目标平台上的读取实现。
FileUtils是一个文件读取基类，提供有默认的实现，一些平台会提供特定的实现。
通过多态，FileUtils让我们的游戏客户端代码不需要对特定平台做特定处理，
也不需要关心FileUtils子类的类型。
比较遗憾的是，由于时间关系，目前我没有找到对音频文件解密的方法。
调试跟踪发现，Cocos2d-x 在Windows上播放音频是直接调用了Win32 API，这些接口API是输入一个文件路径来播放音频的。
之前有提到，做加密解密需要应用数据的接口从内存中获取数据。
接口直接读磁盘文件，就没有办法干预文件的载入进行数据解密了。
我觉得引擎的设计者，可以提供一个接口，利用观察者模式，
让引擎用户可以在不修改引擎本身的情况下，干预数据的读取进行数据变换来实现解密。
毕竟自己改引擎不是一个好的做法。
一般要做资源数据加密，大体会做2件事：
1.写一个工具，能对磁盘文件进行加密。这个工具，可能需要遍历文件夹、可批量选择文件等功能。
2.在软件程序中加入解密功能，对工具加密后的数据进行解密。
工具能方便操作、提高生产力，很重要。
这里，我自己做了2个工具。
1.对cocos2d-x引擎进行修改和恢复的工具，使其具备解密功能。如下：
2.对磁盘文件进行加密解密的工具，方便打包时的批量筛选操作。如下：
这个工具能识别出文件是否已经被加密，原理是用了之前说的”加密文件头“设计。
这样可以防止对已被加密后的文件再次执行加密，防止对未被加密的文件执行解密。
降低误操作的可能性同时，也直观地显示文件的加密状态。
如果没有”加密文件头“，工具程序就无法识别一个文件到底是否被加密过。
做了资源加密会降低程序的性能，原因很简单，需要对文件数据进行额外的处理。
稍微复杂一点的加密算法，可能要申请内存空间来保存解密数据。delete , new 都是耗时操作。
资源的加密也可能会使得apk包体体积增大。这是为什么呢？
原因是，用Cocos2d-x 开发，资源会有很多*.plist *.ExportJson *.tmx 等文件。
plist 可能是配置，也可能是粒子。
*.ExportJson 等文件是 Cocostudio1.6 做出的动画、UI 导出文件。
*.tmx 是Tilemap输出的地图格式。
以上说的这些文件，都是用文本存储数据的，可以用Windows记事本打开查看内容。
apk包实际上是一个压缩包，压缩算法对于有大量冗余数据的文件压缩率是很高的。
我之前写过一篇关于压缩算法的文章《文件压缩与解压：哈夫曼编码》有兴趣的同学可以看看。
我做过一个试验，600多KB的 UI *.plist *.ExportJson 文件，打成apk包后，实际上只占60多KB。
这是因为压缩算法能对这些配置的文本文件有很高的压缩率。
如果我们的加密算法会降低冗余数据。
比如：一个文件的内容是“111111...."，10万个1。
我们的加密算法为了增加安全性，会把这些内容加密成为："sfsadfsa...."。
解密者很难从无规律的不重复的数据推出原先的”111111....“的内容，
但同时对这样的数据，压缩率也会很低。
我之前设计了一个使用密钥加密的算法，会消除冗余数据，
对于都是同样的一个字符的内容，可以加密成一个看似无规律的乱七八糟的内容，
其实还是有规律可言，只是无规律循环节很大而已。
然后，这些加密后的数据，几乎就不能压缩了。
加密资源之后输出的apk包相比没加密资源的包，体积增加不少。
对于这种情况，可以仅对图片等关键资源加密，而不对非关键性的文本文件加密。
或者降低算法的加密强度，保留数据冗余性。
