失踪人口回归~~~

今天给大家带来的是一个简单的js加密分析，废话不多说，先上目标站

定向传送门

我们的目标就是采集到这个累计热卖xxx件。 右键查看源码可以发现并没有藏在静态的HTML中，可以分析出是通过XHR传递到页面上的，所以接下来我们进行抓包操作。

可以很轻松地找到这个接口，发现返回的数据里面有我们需要的，然后开始分析这个接口里面的参数，很明显我们发现了api_sign这个参数，但是现在我们还不知道有什么用，先标注起来，后面我们再分析，我们接下来看看接口中的param有些什么。

看到这个包的参数，是不是一时竟无语凝噎，这么多参数，如何下手？

---

其实如果这类js加解密的东西做得多了，就不难猜出，里面大部分参数都是可以写死的，比如functions， uiSwitch，app_name，app_version 等等

仅通过经验来看，我们目前觉得很可疑的参数有以下几个 --> headers–api_sign, param–app_key, param–cid, param–mars_cid.

接下来其实可以通过fiddler的重新发包来验证这个事情，我们通过修改param中的参数，来进行验证。

当我们任意修改了这几个参数中的一个时，不难发现，接口就无法正常返回数据了，所以不难猜出这个几个参数一定是经过了强验证的，如果无法找出加密手法，那就无法正常拿到数据了。 所以接下来就是喜闻乐见的js逆向了。

首先直接全局搜索api_sign，不难发现这个参数是通过了几个参数拼接合成，然后使用了sha1加密而形成的。

Anyway,我们先一步一步走，把每一个步骤都跑出来，这里我使用的是webstorm，直接把网站中的js代码复制粘贴下来，然后补环境补包，比如sha1，我这边直接是用的npm install sha1,然后在nodejs里面require即可。

经过断点调试剥离出js算法后我们可以发现实际上这个参数就是利用了param中的所有参数，以及cookie中的mid，拼接合成为一个新参数，其中需要注意的是secret参数用了AES加密，我们可以用crypto-js来进行操作。

最后我们经过调试，不难发现cookie, mid, cid, app_key都是可以写死为固定参数，而app_sign会因为brandid以及province_id的改变而改变，后面这两个参数也就是不同商品对应的唯一ID了。

---

至此 结束 感谢观看

---

Ending

Github传送门

持续更新ing （欢迎各种star与fork）

联系方式: 442891187(QQ)

如有权益问题可以发私信联系我删除