【逆向分析】CMCC“和助手”APP(2.9)HTTP加密方式分析
1. 直接抓包会发现“和助手”的请求和应答数据都是加密的。如附图1所示。
下面来分析下加解密算法，最终目的是实现直接和服务端进行HTTP交互。

2.APP运行后会释放gatewayClient-2-9目录，里面是HTML和JS文件。通过JS里的关键词得知，“和助手”采用的WADE-MOBILE框架。奇怪的是关于WADE-MOBILE网上的介绍很少，只找到这篇有用的介绍http://www.docin.com/p-2187443660.html，大体了解到这个框架使得安卓APP能够使用HTML+JS实现前端展示，通过JS代码调用安卓API实现业务功能（比如与服务端交互）。

3. 从common.js中的callSvc()，追踪到mobile-client.js中的Mobile.dataRequest()，继续追踪到wade-mobile.js中的WadeMobile.dataRequest()，继续追踪到 androidExecute()，最后追踪到mobile-core.js中的PluginManager.exec()。JS里通过PluginManager.exec()来实现调用安卓Java代码里的功能。如附图2所示。

4. 通过PluginManager.exec()调用的函数名，在Java代码中可以寻找到具体的实现。例如"dataRequest"，应该是实现后台交互的。在Java代码中找到dataRequest()的实现如附图3所示。

通过进一步跟踪，在transPostData()中可以看到HTTP参数的封装过程，如附图4所示。
这里的key是DES的秘钥，发给服务端用于解密客户端数据。data是要发送的数据部分，也被使用MobileSecurity.requestEncrypt()加密了。

需要注意的是这个key本身也是经过加密的，查看MobileSecurity.getDesKey()代码如附图5所示，这里key的值是经过RSA加密的（公钥位于res\raw\public_key）。另外，这里的key并不是固定的，是在每次MobileSecurity类初始化的时候随机生成的，如附图6所示。
另外，DESKeySpec(k)时，如果k的长度如果超过8字节，将只取前8字节。

应答数据的解密是通过MobileSecurity.responseDecrypt()实现的，附图7和8所示。

梳理一下“和助手”的加解密流程：
（1）APP每次会生成一个随机的key用于DES加解密。
（2）HTTP请求时会把key作为一个参数（使用RSA加密后）传递给服务端，同时将其它数据通过DES加密后放到data参数中。
（3）服务端接收到数据后，先用RSA私钥解密出key的明文，然后根据key再DES解密出data明文。
（4）服务端将HTTP应答数据也使用该key进行DES加密后回送。
（5）客户端收到HTTP应答数据后使用该key进行DES解密。

如附图9所示，是我们对服务端应答数据解密后的一个示例（中文部分显示为乱码）。

• 
• 
• 
• 
• 
• 
• 
• 
• 

去微博查看或评论