一、目标

最近也不让加班了，李老板每天早早的就回家，小视频也刷的没意思了。还是好好找个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小程序可以很容易解析出来。不过这里有个在线解析的，就比较方便了

http://www.msxindl.com/tools/unicode16.asp

搜相似

正在一筹莫展之际，李老板凑过来: 奋飞呀，这个mm不错，下面还有个搜相似的按钮。

一搜一大把，返回值是一个长长的json，里面有一堆mm的数据，头像，详情和照片。

https://cpi.bxxxx.com/search/Searchuser

找到这个数据包之后，按照正常逻辑我们有理由推断，App启动的时候获取的mm列表的接口应该也在这个域名之下。

继续上jadx

这个域名下的接口不少呢，有点耐心，慢慢翻翻，真相应该不远了。

不过李老板没有这个耐心等了，他又下了个新的App，叫啥食色？难道他要学做菜了？

三、总结

大多数人都有路径依赖的，好不容易设计了一个签名，必须得用上呀。所以追踪签名函数的堆栈，是个定位的好方法。

字符串加密很重要，一堆接口url直接暴露，太不高级了。最土的办法做个base64嘛，起码不会被jadx轻松搜到。

为学之道常将狮子为喻，盖以狮子游行，不求伴侣。行动一步，群兽绝野，肝胆裂。为学之人亦复如是。

TIP: 本文的目的只有一个就是学习更多的逆向技巧和思路，如果有人利用本文技术去进行非法商业获取利益带来的法律责任都是操作者自己承担，和本文以及作者没关系，本文涉及到的代码项目可以去 奋飞的朋友们 知识星球自取，欢迎加入知识星球一起学习探讨技术。有问题可以加我wx: fenfei331 讨论下。

关注微信公众号: 奋飞安全，最新技术干货实时推送