猿人学web端爬虫攻防大赛赛题解析_第九题：js混淆-动态cookie2

一、前言

一转眼又有快两个星期没更博客了，主要是没想到第九题真的这么难，硬是让我死磕了快半个月，最终在参考其他大神的解题分享，才完全搞明白为啥自己始终算不对加密参数，还是吃了没文化的亏啊。总体来说这题坑不少，但也让我学到了不少新知识，死磕的过程中多少还有点收获。

二、加密逻辑初探

先看题目要求，这里是要求要找出所有的评论数量，按惯例还是先看看页面请求api的返回结果。

f12兴冲冲的打开了开发者模式，结果一上来就遇到一道坎，这里的udc.js文件内设置了无限debugger，第一波反扒措施，意味着不可能按以前那种方法随便调试了，肯定要想办法把这里过掉。

直接调试不行，我决定先用fiddler抓个包，看看具体请求是什么情况。删除已有缓存和cookies后，重新发起请求，在fd里观察一下：

第一次请求的是这个url：

http://match.yuanrenxue.com/match/9

响应头里返回了一个cookie，即sessionid：

响应体里是混淆后的代码，目测混淆加密逻辑应该是在这里生成

之后呢，又请求了这个udc.js文件，也就是在我们浏览器调试时，有无限debugger的那段代码：

在上面两个请求完成之后，重新请求了我们第一次访问的url：

http://match.yuanrenxue.com/match/9

只不过这次请求已经带上了cookie，其中一个是初次请求时返回的sessionid，一个是m这段字符串，很显然m应该是我们要找的关键值

再完成了上面这一系列请求操作以后，最终才请求了数据接口页，返回了包含有评论数量的json数据。

总的来看，这题的加密逻辑就放在初次请求页面的响应体里，且分为了两部分，一部分混淆代码是在udc.js文件内，一部分是直接放在源码里，通过这两部分代码完成cookie里m字段的生成，最后通过location.reload()实现页面的重载。但由于第二次请求时请求头里已经携带了cookie，所以这次得到了该页面的真实响应结果。

三、加密逻辑深入分析

由于网站设置了无限debugger来组织调试，所以这里我尝试在使用猿人学ob混淆专解工具解混淆后，使用reres插件来用本地js替换网站请求中的udc.js文件。

一万多行的混淆代码在解混淆后，被精简到了两千多行，不得不说学习下ast还是很有必要的。
在注释掉了包含debugger的这段代码之后，打开reres，开启开发者模式，重新请求网页，这次果然没有再被udc里的第一个无限debugger阻碍。

结果发现后面那段直接写在源代码里的混淆代码里也有无限debugger设置，而且是用constructor的形式生成，过掉这段debugger的方式是在运行到这段代码之前在浏览器console控制台输入下面这行代码，将构造函数置空，这样debugger设置就失效了：

Function.prototype.constructor=function(){
   }

到此总算解决了不能顺利调试的问题，于是开始搜索加密关键词，在下面这端代码里找到了包含document，decrypt等关键词，看着很可疑，于是在这里打上断点试试。

这里需要注意的是，在请求初始页面时，除了udc.js的内容不变以外，每次服务器返回的第二段混淆代码都是有略微区别的，也就是数字2标示的这部分代码。

不过代码的含义是不变的，可以通过document关键字来定位，实际上在这里我们已经可以看到document这里就是cookie最终赋值的地方

经过分析，这行代码的未经混淆的实际内容如下（每次加载具体变量名可能不一样），核心是三段字符串相加，而res就是加密的关键，在上面的for循环内明显可以看出，res是由decrypt函数对一段时间戳处理后得到的结果。

document["cookie"] = "m=" + (_0x326619 - 1)["toString"]() + res ;

顺着调用栈，找一下decrypt函数的位置，发现原来这个函数就在udc.js内，现在整个加密逻辑就更清晰了。两部分混淆代码中，前面这段负责具体加密实现，后面那段就负责给cookie赋值。

最后总结一下，这道题的整个加密分为两部分，udc里有一部分加密逻辑，这部分负责对时间戳进行加密；后面直接写在源码里的混淆代码里也有一部分逻辑，主要是控制加密函数循环次数以及为cookie赋值。

四、代码实现

4.1、ast解混淆的一个坑

在将两部分混淆代码都用猿人学ob解混淆专解工具处理以后，就是具体的补环境，在本地调试代码的环节了，这个过程中有几个在常规调试时需要注意的地方：

一是window、navigator、document等全局变量要事先定义好，并且删除代码里本身就有的多余的相关定义；

二是有些代码是只在nodejs环境下才会生效的，比如global全局变量在浏览器端是没有的，但是网站会把这作为反爬虫手段，利用条件判断或者异常捕捉等手段，让它在本地调试时生效，从而把全局变量赋值为空等操作，达到影响代码运行结果的目的。

另一个非常规问题是我苦想了一星期，硬是没找到原因的问题。按道理，在将两部分代码解混淆，并合并以后就可以顺利生成m的结果，但实际上使用同样的时间戳作为参数，浏览器的结果跟我们自己生成的却完全不一样。

比如某一次请求中，时间戳字符串为"1624783099",循环次数为4次
其最终加密后的m字符串结果是：

m=4VyTSsUbyttmHH4Sib0MO0RtkCD2kXPeSKtTwT4kmaS33LhCGr5PKNaQJSQydLjAUenSQ5k8r%2FSAmz9QNXiznmpydmN4g8xVtqW8S3EuiOdZ4GhDYbkTrnJyPOrXyfaNbbjmEIT%2FfakD%2FvFJ7tGhL%2BD8NgZ%2BqMrBz26tg3Xe4YrC5kUAaKFqRsh1gKMkjXKpkldoJ8Q%2B%2B8RQgpiYLEv6%2FkN3Xl%2FSNJQFNPSFuqAMv9pxqSDwFd8JBN3PVQnWJp3wlF3Zi63Bf8jKoWDD06KKGagAIkL4Aq7QZ43dy8mQkcGPxIlqdSRpQs93rg8STvs%2BrVDDHGLJiMmxv7cqIomH3Lw%3D%3Dr

同样的参数&#x