Cocos2d-x 资源加密解密实践总结
本文乃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保存数据,他只对保存的值进行加密。 内容类似这样 <EntityHp = "密文" 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解析器: 《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 CCFileUtils-win32.cpp 这个文件中的 static Data getData(const std::string& filename,bool forString) 函数。 这个函数是一个非类成员静态函数。
再调试下其他的数据载入,cocostudio1.6做的动画的调用堆栈是: cocos2d::FileUtilsWin32::getFileData 基本上文件的载入函数有2个,都在CCFileUtils-win32.cpp文件中, 1.FileUtilsWin32::getFileData 2.getData
要做解密的话,就是修改这2个函数了。 值得注意的一点是:getData函数的签名是: static Data getData(const std::string& filename,bool forString) forString这个参数,用于标识读入的文件是不是一个文本文件。
如果forString为真的话,buffer就要多分配一个字节,用来放置C语言的字符串结束符 截图一下引擎的代码:
要做解密,我们的解密数据内存也要用forString来判断是否多分配一个字节的内存。
FileUtils单件类,很多函数是虚函数。FileUtils::getInstance, 在Windows平台上,返回的是 FileUtilsWin32子类对象。 在Android平台上,返回FileUtilsAndroid子类对象。 Cocos2d-x 3.4 实现在Windows和Android平台上的解密需要修改2个文件: Windows 平台的:cocosplatformwin32CCFileUtils-win32.cpp Android 平台的:cocosplatformandroidCCFileUtils-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。 这是因为压缩算法能对这些配置的文本文件有很高的压缩率。 如果我们的加密算法会降低冗余数据。 比如:一个文件的内容是“222221....",10万个1。 我们的加密算法为了增加安全性,会把这些内容加密成为:"sfsadfsa...."。 解密者很难从无规律的不重复的数据推出原先的”222221....“的内容, 但同时对这样的数据,压缩率也会很低。 我之前设计了一个使用密钥加密的算法,会消除冗余数据, 对于都是同样的一个字符的内容,可以加密成一个看似无规律的乱七八糟的内容, 其实还是有规律可言,只是无规律循环节很大而已。 然后,这些加密后的数据,几乎就不能压缩了。 加密资源之后输出的apk包相比没加密资源的包,体积增加不少。 对于这种情况,可以仅对图片等关键资源加密,而不对非关键性的文本文件加密。 或者降低算法的加密强度,保留数据冗余性。 (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |