本文乃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。
我们可以设计一个加密文件头，加密文件头有一个字段标识该文件是否是被加密过的。
解密算法可以通过判断加密头的标识符来决定是否进行解密、采用哪种解密算法等。
这是一种数据驱动式的解密机制，解密信息都保存在加密数据本身中。
对于没有被加密过的数据，程序判断没有文件加密头标识，就不执行解密。
这样，程序可以同时读取未加密的数据和已经加密的数据，而不需要对程序进行任何修改。
注意：加密头的标识符应该足够特殊，保证和未加密的数据不会产生冲突。
若未加密的数据刚好出现了加密头的内容，那么程序就会对未加密的数据进行解密。
在Cocos2d-x 中做加密解密的研究过程
我的项目配置是用CSV文件。解析器，用的是我自己写的CSV解析器：
在游戏中这部分的解密，比较容易实现，就是对整个文件加密，
游戏启动时把加密文件读入内存进行解密，然后把解密数据传到解析器进行解析。
一些由游戏产生的需要保存的数据，我用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子类的类型。
加密解密支持工具
一般要做资源数据加密，大体会做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包相比没加密资源的包，体积增加不少。
对于这种情况，可以仅对图片等关键资源加密，而不对非关键性的文本文件加密。
或者降低算法的加密强度，保留数据冗余性。