Rve∎

前言

本文主要是对网络协议进行分析，即分析网络数据包的字段，以及每一字段的生成方式。分析应用是格瓦拉v8.1.1版本，主要分析了数据包中签名sign值的生成过程及方式，sign是把数据包中的所有数据用”&”连接后，再进行md5得到的，服务器会通过这个值对数据包完整性进行校验。

分析过程

网络数据包如下：

这个应用已经把signmethod都告诉了我们是md5，可以看到数据包中的字段还是非常多的，他使用这么多的东西最大的目的也是为了最后进行md5的hash，用来防止其他人对数据包进行篡改，但是他的加密方式过于简单，甚至连md5都没有经过任何变换，下面我们通过源码分析来找到进行md5的值。

源码分析如下：

针对登陆时数据包的logintoken，全局搜索logintoken，找到sign值的入口

可以非常确定此处就是登陆时计算sign值的地方，我们重点关注hashmap v6的调用，找到了计算sign值的入口awb函数

仍然是关注哪里调用了之前生成的hashmap，发现awi.a函数会计算sign值

看到这里已经很明显的看到v0_3为我们要的sign值，那么找到之前对他进行处理的azl.a函数，这个函数的两个参数为hashmap，和azs.a函数的返回结果，跟进这个函数

可以看到这个函数先判断androiddramainmove和appkey的值是否相等，并把是否相等的bool型变量传入函数azs.a中去，如果为false则返回prikey-android，否则返回一串hash值，由于这里appkey为android2009，所以我们判断直接返回prikey-android。

继续分析函数azl.a

这里就很明显了，函数先是将hashmap中的数值使用“key=value”的形式通过”&“进行拼接，通过bax.a去掉最末尾的&后，再与prikey-android进行拼接，对最后的结果进行md5返回并且存入sign中。找到这段代码我们可以直接动态调试断在计算md5之前，得到这个sign值，然后修改其中的某一字段重新计算md5，就可以绕过服务器对数据包的校验。我们断下来的数据进行md5也验证了我们的推论:

获取验证码时生成的sign值的原始数据

1
2
3
4
5

appSource=AS01&appVersion=8.1.1&appkey=android2009&apptype=cinema&citycode=110000&deviceId=020000000000&format=xml&imei=354360070244405
&method=com.gewara.mobile.login.getMobileCodeByFindpass&mnet=WIFI&mobile=18310455273&mobileType=Nexus5X&mprovider=&osType=ANDROID
&osVersion=7.0&pageName=com.gewara.activity.usercenter.fragment.UserForgetFragment&pointx=116.365237&pointy=39.969854×tamp=2017-03-1615:42:41&v=1.0&version=1.0prikey-android

总结

之前都是对一些ctf题目进行分析，后边会更多地注重实战，注重对实际应用的分析和破解。实战分析主要的难点在于代码的定位，以及java或者android编程中的机制，程序执行。所以对开发能力也有比较高的要求。