目标：🐟的搜索商品接口

这个站异步有点多，好在代码没什么混淆。加密的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发请求的完整代码，需要可以私我（没整理有点乱，只是草草实现了功能，勿喷）