鲁达 移动App黑客渗透中常见的加密与解密
目前App数据传输过程中几种常见的加密方式，以及一些常规的解密手段，并不涵盖并应对所有情况，在实战过程中还须具体情况具体分析，随机应变；同时，也十分欢迎与希望各路大神提出宝贵建议和思路，一起学习和研究。（注：全文中所提到的App仅针对Android App）
随着App移动应用的广泛应用及移动开发技术的飞速发展，移动应用的安全也越来越被重视；在App服务端渗透中，我们在抓包时经常会发现App在数据传输过程中做了加密（如图1），以防止数据被查看或被篡改；而渗透过程中的很多时候我们都需要抓包修改，这就要求我们需要先对App数据包进行解密了。
1.png
一、一些常见的加密方式
对于App传输数据加密，一般会考虑三个方面
1） 可用性：客户端和服务端都可逆向破解
2） 较高的安全性：不容易被破解
3） 效率性：加密性能及资源占用方面不是很高
针对以上三个方面需求，目前用得最多有以下几种加密方式（当然，有时候会掺杂一些其他的小算法，具体情况自行识别和解码即可），其特点及优缺点分别阐述如下。
关于哈希算法，一串字符串哈希之后，我们会完全看不出原文的信息。这个性质很有用，但我们无法实现加密通讯，因为连加密通讯应该接受到信息的人，也看不懂。
比如我们要给一个人发送一段话“今晚还是小树林见”，我们sha256运算后是：2e2097b9caae882f32966a4d2469561fa70793e0cc3ba32a421a27fcd1bb3fa0
OK，消息被人截获了是不担心别人看懂，问题是接受消息的人也看不懂了。
这个时候我们可以用对称加密算法来实现加密通讯。原理很简单，假设我们要给你发送一个信息hello，然后我们约定所有的字母都往字母表后一位来表示。h的后面是i，e的后一位是f，l的后一位是m，o的后一位是p。那我想发送hello的时候，每个字母往后一位替代，得到并发送字符串ifmmp。
这个ifmmp不是一个有意义的单词，接受方因为知道我们的约定，把每个字母往前一位，就能还原出hello。我们把hello称为“明文”，往后一位的过程叫“加密”，往后挪一位，而不是三位或者五位，这个数量当做“密钥”，加密后的ifmmp叫“密文”，往前一位还原叫“解密”，解密完后又变成hello，也就是变回“明文”。
这个密钥就像一把钥匙，只知道往后挪是不够解密的，还需要知道往后挪几位。这个很重要，因为我们不可能为所有场景单独设计一套加密算法，算法的安全性恰恰建立在它是公开的，没有人能够攻破的基础上。加密的算法都是公开的，你要保证你的信息不被人窃取，能够保密的就是密钥。
1）对称性加密。如DES、AES、3DES等。这些加密方式的算法基本已公开，因此其特点为密钥/生成密钥的方法固定，因此这种加密方式的优点为性能效率较好，而且也较大的提升了解密的成本；但由于密钥固定，因此缺点也很明显了，则是在客户端和服务端上都能找到密钥或密钥的生成方法。因此其突破口为通过逆向客户端来寻找密钥。另外，这种加密方式可同时用于请求包和返回包。
2）非对称性加密。如RSA、Rabin等。这些加密方式的算法基本也已经公开，因此其特点为有一对公钥和私钥：客户端上保存公钥，用于加密；服务端上保存私钥，用于解密。因此这种加密方式的优点为安全性较高，客户端上只有用于加密的公钥，而没有用于解密的私钥；而弱点则为加解密效率不高，性能资源占用较大，所以目前很多App还是选用对称性加密。由于客户端上没有解密数据包的私钥，因此需要使用其他方法获取数据包明文才能进行数据包篡改。（获取方法后续详述）另外，由于只有一对公钥和私钥，所以这种加密方式一般只会出现在请求包，而返回包则一般为明文返回。
3）自定义算法加密。有少数App开发的技术人员还会使用自定义算法来对数据包进行加密，算法五花八门，大多为各种常见的编码（如Base64）和字节位移运算等混杂。这种加密方式的优点为效率较高，但缺点为算法硬编码在客户端中，只要通过逆向即可解密出来。
以上三种加密方式各有优缺点，对于第一和第三种，虽说可通过逆向App获取密钥/算法来进行解密，但是开发者往往会通过其他手段来增强安全性，如App加固或把密钥/算法硬编码在so文件中等；这样就更进一步地提高了逆向与解密的难度和成本了。