目标:🐟的搜索商品接口
这个站异步有点多,好在代码没什么混淆。加密的sign值我们可以通过搜索找到位置
sign值通过k赋值,k则是字符串拼接后传入i函数加密
除了开头的aff...,后面的都是明文没什么好说的,我首先想的是,明文知道了,加密结果又是个32位的,会不会是标准的md5?
于是乎,先拿着明文去尝试md5
还真是,这种站这么简单我是没想到的~~
然后是aff...这个值
关键词:token,this.option。盲猜是其它接口传过来的,搜索一下
就其它接口返回的cookie值!!!
那就没啥好逆的了,,,到此sign的加密逻辑就结束了,没错就是这么简单
如果真这么简单,这么水文好像也没啥意义。。。
考虑到cookie会过期,我们再看看返回cookie的请求是怎么构建的。
跟我们的搜索请求是同一个接口,请求参数也大差不差,这个时候要思考一个问题。
这里同样有个sign值,但是我们前面说了,sign的加密是要传入cookie._m_h5_tk作为参数的,如果说这时候cookie还没有生成,那么这个sign是传入什么进行的加密?
方法很多,我就插了个桩,如图:
然后清掉缓存cookie,刷新,看结果:
注意看我圈出来的,上面的红框就是返回我们需要的cookie的请求的sign值的加密结果跟明文,下面的红框就是传入了拿到了_m_h5_tk的明文跟加密结果sign值。(自己去看一下两个请求的sign值,对比一下就知道了)
所以我们要做的是请求两次同一个接口,第一次拿返回cookie中的_m_h5_tk以及_m_h5_tk_enc(两个是绑定的,必须在第二次请求的时候一起传,否则会返回非法令牌的响应),然后加密得到sign发第二次请求。然后就over了~
总得来说这个站没什么难度,可能是我鱼哥刚入驻web,没体验到世间险恶,后面大概率会大改吧。趁现在赶紧拿去上分,冲~
哦对,其它cookie参数的有效性我没验证,大家可以去研究看看,如果发现其它参数也需要追踪,可以私我,有空再看看。
python发请求的完整代码,需要可以私我(没整理有点乱,只是草草实现了功能,勿喷)