一、目标
最近也不让加班了,李老板每天早早的就回家,小视频也刷的没意思了。还是好好找个mm正经聊聊吧。
今天我们的目标是 某婚恋App的 v11.3.2。
二、步骤
抓个包
_t 参数,看上去像是时间戳加上一个md5(掰指头数了数,一共32位)。
jadx搜一搜 _t , 我去,10几万条结果。一时激动,都忘了我的独门秘籍了。这种签名一般会以字符串的方式存入一个map。所以我们应该搜索 "_t"
嗯,真香。
代码就很清晰了,字符串加上个salt和当前时间,然后做md5。
找接口
从抓包数据可以看到,返回了不少mm照片。但是对李老板这种黄金单身汉来说,一次返回一个照片多没意思,一把就返回一堆mm照片才是李老板的风格。
但是很奇怪在主界面无论如何点选,就是没有抓到返回mm列表的包。不科学呀。
签名函数定位法
App好不容易搞了签名,那肯定能用的请求都会用上。
返回列表的请求一般来说应该也会带上 _t 签名,所以我们试试hook 做签名的函数,然后打出堆栈,看看有么有没抓到的请求过程。
var strUtilCls = Java.use('com.bxxxx.libs.framework.utils.j');
strUtilCls.a.overload('java.lang.String').implementation = function(a){
var rc = this.a(a);
console.log(a);
console.log(">>> _t = " + rc);
var stack = threadinstance.currentThread().getStackTrace();
console.log(" ==== Rc Full call stack:" + Where(stack));
return rc ;
}
strUtilCls.a.overload('java.io.InputStream').implementation = function(a){
var rc = this.a(a);
console.log("InputStream >>> _t = " + rc);
var stack = threadinstance.currentThread().getStackTrace();
console.log(" ==== Rc Full call stack:" + Where(stack));
return rc ;
}
结论是,确实有做了签名而没有抓到的请求,但是目前掌握的证据,还是没法定位返回列表的请求在哪里。
\u670d\u52a1\u672a 的翻译
寻找数据包的过程中发现了几个返回值是 "msg":"\u670d\u52a1\u672a 的包,\uxxx肯定是中文了,写个python小程序可以很容易解析出来。不过这里有个在线解析的,就比较方便了
搜相似
正在一筹莫展之际,李老板凑过来: 奋飞呀,这个mm不错,下面还有个搜相似的按钮。
一搜一大把,返回值是一个长长的json,里面有一堆mm的数据,头像,详情和照片。
https://cpi.bxxxx.com/search/Searchuser
找到这个数据包之后,按照正常逻辑我们有理由推断,App启动的时候获取的mm列表的接口应该也在这个域名之下。
继续上jadx
这个域名下的接口不少呢,有点耐心,慢慢翻翻,真相应该不远了。
不过李老板没有这个耐心等了,他又下了个新的App,叫啥食色?难道他要学做菜了?
三、总结
大多数人都有路径依赖的,好不容易设计了一个签名,必须得用上呀。所以追踪签名函数的堆栈,是个定位的好方法。
字符串加密很重要,一堆接口url直接暴露,太不高级了。最土的办法做个base64嘛,起码不会被jadx轻松搜到。
为学之道常将狮子为喻,盖以狮子游行,不求伴侣。行动一步,群兽绝野,肝胆裂。为学之人亦复如是。
关注微信公众号,最新技术干货实时推送
文章作者 奋飞
上次更新 2021-11-16
许可协议 奋飞安全原创,转载请注明出处。