【逆向分析】CMCC“和助手”APP(2.9)HTTP加密方式分析

1. 直接抓包会发现“和助手”的请求和应答数据都是加密的如附图1所示。

下面来分析下加解密算法最终目的是实现直接和服务端進行HTTP交互。

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

通过进一步跟踪在transPostData()中可以看到HTTP参数的封装过程，如附图4所示

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

另外DESKeySpec(k)时，如果k的长度如果超过8字節将只取前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所示是我们对服务端应答数據解密后的一个示例（中文部分显示为乱码）。