游戏加密技术
① 手机游戏一般用什么加密的
手游加密属于手游安全的重要步骤之一，可以使用一些第三方APP安全保护平台工具爱加密来实现，通过本地数据文件保护，页面防钓鱼保护，键盘监听保护，截屏保护，协议加密和源码安全保护。源码安全包括：DEX加花加壳保护，动态指令加载，资源文件保护，SO文件保护和内存防mp保护等等。单一的加密方式可能比较简单，比较容易被破解，但是组合起来效果就会很好。希望可以帮到你。
② 游戏封包加密方式
常见的加密算法可以分成三类，对称加密算法，非对称加密算法和Hash算法。对称加密指加密和解密使用相同密钥的加密算法。对称加密算法的优点在于加解密的高速度和使用长密钥时的难破解性。假设两个用户需要使用对称加密方法加密然后交换数据，则用户最少需要2个密钥并交换使用，如果企业内用户有n个，则整个企业共需要n×(n-1) 个密钥，密钥的生成和分发将成为企业信息部门的恶梦。对称加密算法的安全性取决于加密密钥的保存情况，但要求企业中每一个持有密钥的人都保守秘密是不可能的，他们通常会有意无意的把密钥泄漏出去——如果一个用户使用的密钥被入侵者所获得，入侵者便可以读取该用户密钥加密的所有文档，如果整个企业共用一个加密密钥，那整个企业文档的保密性便无从谈起。常见的对称加密算法有DES、3DES、Blowfish、IDEA、RC4、RC5、RC6和AES非对称加密指加密和解密使用不同密钥的加密算法，也称为公私钥加密。假设两个用户要加密交换数据，双方交换公钥，使用时一方用对方的公钥加密，另一方即可用自己的私钥解密。如果企业中有n个用户，企业需要生成n对密钥，并分发n个公钥。由于公钥是可以公开的，用户只要保管好自己的私钥即可，因此加密密钥的分发将变得十分简单。同时，由于每个用户的私钥是唯一的，其他用户除了可以可以通过信息发送者的公钥来验证信息的来源是否真实，还可以确保发送者无法否认曾发送过该信息。非对称加密的缺点是加解密速度要远远慢于对称加密，在某些极端情况下，甚至能比对称加密慢上1000倍。常见的非对称加密算法有：RSA、ECC（移动设备用）、Diffie-Hellman、El Gamal、DSA（数字签名用）Hash算法Hash算法特别的地方在于它是一种单向算法，用户可以通过Hash算法对目标信息生成一段特定长度的唯一的Hash值，却不能通过这个Hash值重新获得目标信息。因此Hash算法常用在不可还原的密码存储、信息完整性校验等。常见的Hash算法有MD2、MD4、MD5、HAVAL、SHA加密算法的效能通常可以按照算法本身的复杂程度、密钥长度（密钥越长越安全）、加解密速度等来衡量。上述的算法中，除了DES密钥长度不够、MD2速度较慢已逐渐被淘汰外，其他算法仍在目前的加密系统产品中使用。
③ 如何加密RPGXP游戏数据
方案一：使用自己的加密算法
第一种加密方案是修改RGSS102J.dll中的解密算法，然后自己把素材打包成RGSSAD格式。
此方案要求使用者对程序设计以及二进制文件的修改有一定的基础。
由于我现在还没有试过外挂dll这种技术，所以这里介绍一个相对简单的方法——修改MagicKey的初始值。RMXP是使用0xDEADCAFE作为MagicKey的初始值，那么我们把RGSS102J.dll中的DEADCAFE修改掉，然后自己打包就可以防范那些一般的解包工具。
当然，如果你觉得有必要的话，还可以给这个修改过的dll文件加一个强壳，然后随游戏发布。
虽然安全系数不高，但足以应对全自动的提取工具。我写了一个程序来自动修改MagicKey，并打包资源文件，我给它起名叫"纸老虎"。下载网页 http://www.uushare.com/user/lingchen/file/1333250。
难度指数：★★
安全指数：★☆
·方案二：混淆文件名
第二种加密思路是混淆文件名。在Windows操作系统下，有 \/:*?"<>| 这9个字符是不能用作文件名的。除去\/表示文件目录，我们还有7个特殊字符可用。如果在原有文件名中加入这几个本来不能用的字符，那么解包程序就会因为不能正常创建文件而提取失败。
注：此方法需要自己打包资源文件，以及修改rxdata文件，工作量比较大。
混淆不能绝对保证自己的游戏不被盗用，它的主要目的是打击盗用者的信心，让他在还没有导出全部素材的时候就已经垂头丧气，精疲力尽了。
难度指数：★★★★
安全指数：★★☆
·方案三 将整个游戏打包成一个可执行程序
这个方法很多人都在用，而且可用的工具比较多，与MoleBox类似的工具都可以做到。
难度指数：★★
安全指数：★★★
·方案四 给游戏加一个特殊的"壳"
此方法与方案三类似，并且与传统概念上给程序加壳有所不同。这里所说的"壳"更类似用一个定做的程序给游戏当作中介，它通过HookApi或者别的什么方法接管游戏读写文件的操作。因为是完全接管，所以资源使用什么格式完全是由使用者决定的。此方法需要比较深的编程功底。
难度指数：★★★★
安全指数：★★★☆
·方案五 自制RGSS解释器
这是所有方案中最有效的方案，但是如果真的要自制一个RGSS解释器有两个主要的障碍，
1、RMXP使用的文件格式
2、编写RGSS脚本的解释器
很显然，障碍一要比障碍二简单的多，但同样是一个庞大的工程。（如果有RMXP的源代码的话另当别论）
难度指数：★★★★★
安全指数：★★★★★
对于游戏而言，无论什么样的加密方案都只是增加破解者的工作强度，而不能真正保护自己的素材不被提取，因为素材终归是要在游戏中使用的。