公司使用的是
xxapp打卡。要想自己打卡, 那么我抓包获取接口和参数,自己组装,自己访问接口即可。 说干就干,我开始在登录界面进行抓包:
从图上可以发现:
- 在请求的时候,
herades里面有一些参数,包括了custom-device-id,custom-version,custom-os,custom-company-id,x-json-web-token等,这些内容是自定义header加上去的,后期调用接口时可能会用到 - 采用了
https连接
既然XXX采用https方式,我们没有证书,就无法拦截获取信息,接口调用基本行不通了,那么我们采用AccessibilityService辅助功能的方式进行打卡如何呢?
思路是:将一台手机放到公司,连接网络,另一台手机远程
app是在运行的,然后通过AccessibilityService进行辅助点击从而进行打卡。或者直接设置定时器,时间到之后自动触发以上过程并打卡。但这种思路对进程保活有相当高的要求,不太好实现。
使用https之前的XXX,肯定是http,那么http接口今安在?
居然200,而且从返回的json来看,登录接口对于服务器的逻辑来说是没问题的,应该是在使用中,那么下一步我们只需要拿到入参就行。
下一步,反编译xxxx.apk,用到的工具是AndroidCrakTool:
这里要提一下,反编译后我们能拿到资源文件们,资源文件对于定位页面,控件,以及此控件接下来的逻辑是至关重要很有帮助的。
- 反编译后,将
AndroidManifest.xml和res文件夹留下,其他的删除即可,因为我们此次不对smali进行分析 - 另外,反编译后我们发现XXX并没有对代码进行加壳,只是单纯的混淆了。所以这就更加轻松简单
接下来,我们将XXX.apk后缀名改为zip,然后解压,得到如下内容:
可以看到,得到了两个dex文件,一个classes.dex和classes2.dex,这是因为他的方法数超过了65536,进行multidex的结果。现在我们使用AndroidCrakTool对这两个dex进行dex2jar,目的是将dex转成jar包,方便我们阅读源码。
得到jar包之后,我们用JD-GUI打开阅读,也可以使用AS或者IDEA进行源码阅读。这里采用JD-GUI。
打开这两个jar如下图:
现在来理一理思路,我们刚才测试的是登录接口,我们目的是打卡,那么我们就需要登录后,得到
token,然后带上token和一大堆参数进行打卡接口的访问,所以第一步,我们需要得到登录接口的参数。
我们通过使用TopActivity,在手机上找到登录界面的Activity名字。
从设备左上角可以知道这个界面的名字和包名,所以我们在JD-GUI中找到对应的包名进入寻找登录界面。由于我们有两个jar,所以就先挨个找吧。但从顺序来说,这个登录界面一般会在dex1中,当然这也是猜测,不过一般按照代码量和顺序来看的话是这样的。果不其然,如下图:
从界面上看,我们是点击了
button之后进行网络请求的,所以我们看成员变量,发现一个button,变量名i,然后紧接着下面有个b()方法,内部将i初始化了,findviewbyid()内部传入的正是这个button的id在R文件中的静态常量值。这里插一句,如果有需要对界面和id进行分析的话,就需要从这些dex中找到R文件,然后将这个id的数值拿去寻找匹配,就能在R文件中反向得到这个控件的id,然后将这个id拿到之前反编译后的res文件夹中搜索匹配,从而得到布局文件,控件id等。当然也能通过AS的DDMS进行布局分析,从而得到id,不过那个id是混淆后的,在jar中是无法找到的,因为jar中使用的id是int静态常量。
接下来我们将i变量的id值2131362755用来进行搜索,得到设置点击事件的地方。这里为何不直接用变量i呢?因为i是混淆后的,搜出来可能会有很多,不好排除。
从图上可以看到,我们找到了onClick()回调,并且找到了点击后的逻辑。图中有个方法,叫executeOnExecutor(),看起来像是AsyncTask的线程池执行方法,我们看看是不是,这时候点击前面new b(),看看这个b对象是啥,如下图:
可以看到果然是AsyncTask。那么结果就显而易见了,此次请求使用AsyncTask发起,所以我们在AsynctTask内部就能找到网络请求的相关内容了。先看第一个:
protected Void a(Void... paramVarArgs){
this.b = b.w(this.d, this.e);
return null;
}
此方法一看就知道,他是doInBackground方法混淆后的,因为他的返回值是Void而不是void。在这个AsyncTask实现的时候,泛型定义如下:
private class b extends AsyncTask<Void, Void, Void>{}
三个Void,所以可以断定第一个a()方法是doInBackground。那么网络请求就在这里面了。再来看第二个a()方法。
protected void a(Void paramVoid){}
从返回值和参数来看,可能是onCancelled()和onPoseExcute(),但是从整体代码和代码量来看,可以断定是onPoseExcute():
现在回过头来分析doInBackground()。
this.b = b.w(this.d, this.e);
我们点击w()进入看看:
可以看到,这个b对象的w()方法,就是组装登录接口所需参数的,登录接口需要2个参数,最下面那个是接口地址,红色部分是一串字符串。而通过大码部分的字符串,我们可以知道第二个参数是密码,那么后面跟一串字符串是什么呢?是不是加密?,我们点击e.a()中的a()方法去看看:
从图上可以看到a()方法接收一个参数,联系刚才组装数据的地方,可以知道,密码是由明文加后面红色部分字符串,再整体经过MD5加密之后的。至于为何知道是明文密码,我们返回到LoginActivity,在AsyncTask实例化的时候传入了两个参数,后者就是密码。这个密码字符串的获取方式是反推出来的,如下图:
所以,现在我们有了接口地址,参数,加密方式,我们试试看能否访问成功。
经过调试,登陆成功,server返回了一堆数据,其中包括了token,id等:
我们现在相当于完成了50%。
接下来的步骤要比之前简单太多了。通过抓包,获取到打卡接口的大概路径,然后在刚才组装登录接口参数的
b类中,查询匹配这个接口地址,于是得到了打卡的完整接口地址。并且得到了入参。剩下的就是慢慢组装数据了。我们需要打卡,那么就需要经纬度。通过反编译发现他是用的是高德地图,于是我们使用高德的地理位置反编码,将我们想打卡的位置的经纬度得到,然后传入参数体,从而实现登录并打卡。
其实整个过程走下来,最主要的几个点:
- 在替换成
https后,原http接口未关闭,可能是为了兼容老版本 apk未进行更深层的保护,仅仅只是混淆- 密码加密的关键信息未进行有效保护,直接暴露了出来
最后,这次尝试主要是利用了http接口未关闭的漏洞,其实说到底也就是一次抓包分析数据的过程。
- 以上敏感信息均做打码处理
app名字也替换成了XXX- 请勿用作商业用途和非法途径,仅供学习参考
- 如有侵权,联系我删除