最近有人给我展示了一款app，说抓不到它的请求，连上代理一看真的没有，所以本文结束。
一、初步试验
连上代理后，app并没有明显的提示与弹窗，并且还能够正常访问网络、获取数据，说明app本身设置了代理。
反编译一下，嗯？出错了。。。原来是加了新版的壳。
脱掉壳后，发现使用了OKHTTP的网络库。对于一些常用的网络库，其实提供了设置代理的接口，只需要将其设置成无代理的模式，它就不会应用系统默认的代理了。去代码里翻腾一下，看到很明的设置了Proxy.NO_PROXY。
这里可以去hook proxy方法，然后取消掉这个设置PROXY的过程，让方法直接返回。也可以绕过这个，通过VPN的方式，这里太懒了，直接采用第二种方法，省事不写代码。通过VPN转发到代理工具，已经能抓到包了，又快又省事。
二、测试分析
很明显的，一共有4处加密的地方，header中有3个参数xx-verify、xx-sid、xx-traceid，body中有一个参数client_secret。
通过观察发现，xx-verify是64位的，而xx-sid、xx-traceid和client_secret相类似，都是32位0-9a-f的形式，猜测是md5。
1、client_secret
先来看client_secret，是很经典的md5-salt。这里在map中插入一个private_key字段，然后排序拼接计算md5。
2、xx-sid、xx-traceid
这两个比较简单，uuid+时间戳。
3、xx-verify
xx-verify相对来说复杂一点，先通过URLDecoder加工一下，然后通过native的enMana方法来加密。根据URLDecoder，猜测可能跟请求的url有关。
enMana方法在libsservice.so文件中。
拖进IDA发现so没有任何加密措施，这极大的方便了静态分析。
找到ServerService_enMana导出函数，修改一下参数类型，简化一下视图后，可以非常明显的看到使用了hmac_sha256算法，并且还初始化了一个秘钥在getRMN函数中。
同样修改一下getRMN的参数类型，发现是去SharedPreferences中取了一个叫rmn的字段。所以回到java层，去看看rmn的赋值。跟踪下来知道这个值是从服务端获取的。
为了快速的验证，这里hook一下enMana函数的输入和输出。可以hook java层，也可以hook native层。因为enMana这个是导出函数，所以hook起来也很方便。例如使用frida，这个不是静态函数，所以我们只关心第三个参数即可：
通过hook得知加密的字符串就是URLDecode后的请求url，key是从SharedPreferences取，然后使用hmac_sha256加密。这里因为不是cm，所以魔改加密算法的可能性不大。
拖到一个在线的加密网站中验证一番，结果完全一样。
抓包结果：
加密结果：
至此就分析完了。
三、总结
1、分析过程中可以更灵活一些，边猜边验证。
2、要熟练掌握各种hook的操作，Java&&Native。
3、在看别人的代码时候，可以借鉴其中的保护思路，来提高自己app的安全性。
