一款安卓加固app的协议分析 - ag官方网站

一款安卓加固app的协议分析

最近有人给我展示了一款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

先来看clientsecret,是很经典的md5-salt。这里在map中插入一个privatekey字段,然后排序拼接计算md5。

2、xx-sid、xx-traceid

这两个比较简单,uuid+时间戳。

3、xx-verify

xx-verify相对来说复杂一点,先通过URLDecoder加工一下,然后通过native的enMana方法来加密。根据URLDecoder,猜测可能跟请求的url有关。

enMana方法在libsservice.so文件中。

拖进IDA发现so没有任何加密措施,这极大的方便了静态分析。

找到ServerServiceenMana导出函数,修改一下参数类型,简化一下视图后,可以非常明显的看到使用了hmacsha256算法,并且还初始化了一个秘钥在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的安全性。

备注:文中图片有关敏感信息均已隐去

免责声明:本文仅代表文章作者的个人观点,与本站无关。其原创性、真实性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容文字的真实性、完整性和原创性本站不作任何保证或承诺,请读者仅作参考,并自行核实相关内容。

http://image99.pinlue.com/thumb/img_jpg/fU5lCR7fLSTypySBGb307ynzJEsA8BP4ZsNaek0uy9VxdzUzpRuT01z6a7j1oVZ6VmMQzUvjATYqakhyp96KaA/0.jpeg
我要收藏
赞一个
踩一下
分享到

分享
评论
首页