破解反爬虫策略 /_guard/auto.js（一）原理

背景

当用代码或者postman访问一个网站的时候，访问他的任何地址都会返回<script src="/_guard/auto.js"></script>，但是从浏览器中访问显示的页面是正常的，这种就是网站做了反爬虫策略。本文就是带大家来破解这种策略，也就是反反爬虫。

思路

寻找关键参数

既然在浏览器中访问没问题，那我们就把浏览器的请求复制下来，看是哪些参数让请求可以正常访问，将curl复制到postman中，把请求头一个个去掉，看去掉哪些请求头会让请求无法正常访问

最终发现是Cookie和User-Agent一起使得请求合法，如下

Cookie：guardret=BQgG; __51vcke__K1rw5p3uprPRftXo=21f5dde6-91d9-520b-a429-4a6e99d44523; __51vuft__K1rw5p3uprPRftXo=1720509084853; guardok=9DltyP8ERJnWJaolNInDWV03ft30EOzKt4tqyEk7ovRpu+YeNMKAWDqyyT9DwacZaxy9brXjs+8M+k2pbxhhWw==; PHPSESSID=khol0nbd4esktf48ddmecbidb6; __vtins__K1rw5p3uprPRftXo=%7B%22sid%22%3A%20%22045d7540-b7de-543b-830f-f3cb437c85bd%22%2C%20%22vd%22%3A%201%2C%20%22stt%22%3A%200%2C%20%22dr%22%3A%200%2C%20%22expires%22%3A%201721135512843%2C%20%22ct%22%3A%201721133712843%7D; __51uvsct__K1rw5p3uprPRftXo=7
User-Agent：Mozilla/xxx

可以看到Cookie中有好几项，我们继续在Cookie中删除，发现只有guardok有用，其他的都没用，所以最终有用的请求头如下

Cookie：guardok=9DltyP8ERJnWJaolNInDWV03ft30EOzKt4tqyEk7ovRpu+YeNMKAWDqyyT9DwacZaxy9brXjs+8M+k2pbxhhWw==
User-Agent：Mozilla/xxx

js混淆

这么看来关键的东西就是这个guardok，那我们看看这个是什么时候生成的，把浏览器的cookie删除，再打开开发者模式

但是发现在开发者模式下，这个js在无限的debug，这是一个很常见的防debug的代码，就是定时循环执行含有debugger的代码，如果没在开发者模式那么debug就不会生效（遇到debugger断点不会停），但如果是在开发者模式下就会停到断点处，并且这个方法还会不断的自己调自己直到下一次定时时间，所以即使我们调试通过这个断点也会立刻到这个断点处。

由于这个代码的存在我们不能查看network，因为会一直卡在debuger。那我们就直接用postman访问这个js看看guardok是不是在这个js中生成的。

但是这个js返回的内容还是混淆过的，直接看是看不懂的，比如他会把 "location" 混淆成 _0x10a691(0x215, 'lIIz')，其实这个的意思是将一个初始值_0x10a691 进行位偏移，偏移后就变成了另一个值"location" ，并且这个在浏览器上运行也是能正常运行，只不过加大了我们的翻译成本。

分析关键参数guardok生成过程

既然翻译成本大，那我就先确认这个guardok是否和这个js有关，别翻译了半天发现跟他没关系，那心态就崩了。这个也好确认，在浏览器上访问一次看这个guardok是什么时候生成的就行，但因为这个debbuger的问题我们不能直接在浏览器上访问，所以就抓个包看看这个接口就行，比如使用Charles。

通过抓包可以看到，同一个接口访问了两次

第一次访问，在响应头中的cookie里返回了guard，并且返回的报文体中返回了那个js文件
第二次访问，在响应头中的cookie里返回了guardok，并且返回的报文体中返回了正常的页面数据

可以看到第二次访问的请求中并没有任何地方携带guardok，但是在响应头中有guardok。那么就说明第二次的请求中有参数会传给后端，由后端生成guardok并放到Set-Cookie中，后续的请求就都携带了guardok。

查看第二次的请求只是在请求的cookie中多了guardret和guard这两项。由此可以知道是根据guardret和guard去服务端换取guardok，而guard会在第一次请求的响应中返回到Set-Cookie，无需客户端手动生成。而guardret则只可能会由第一次请求返回的那个js中生成，那我们只需在js中把生成guardret的算法找出来就行了

反js混淆

到这里也就只能对js进行反混淆了，只有知道生成guardret的算法，那一切就都通了。我试过好多反混淆工具都无法解析出实际的代码。没办法只能花时间一点点的还原了。重头戏来了，还原的方法其实并不难，相反还很简单，就是苦力活。比如这个方法


var _0xd750ee = _0x5391;

function setRet(_0x34d4ed) {
    var _0x10a691 = _0xd750ee, WtHInZ = {
            'GIeQp': function (callee, _0xf9e2d4) {
                return callee(_0xf9e2d4);
            }, 'LYVKf': 'undefined', 'fOOLQ': function (_0x396e94, _0x39a709) {
                return _0x396e94 - _0x39a709;
            }, 'FARua': function (_0x4be905, _0x42316e) {
                return _0x4be905 * _0x42316e;
            }, 'ascvk': function (callee, _0x10b8fa, _0x4313da) {
                return callee(_0x10b8fa, _0x4313da);
            }, 'wqePU': function (callee, _0x1a7786) {
                return callee(_0x1a7786);
            }, 'dYcOv': _0x10a691(0x201, '0@TB')
        }, _0x3a9f4b = _0x34d4ed[_0x10a691(0x1ee, '6%cq')](0x0, 0x8), time_num_plain = _0x34d4ed['substr'](0xc),
        _0x305bd1 = WtHInZ[_0x10a691(0x1c8, '2qE2')](parseInt, time_num_plain['substr'](0xa));
    typeof window === WtHInZ[_0x10a691(0x1dd, 'WPXd')] && (_0x305bd1 = 0x2);
    var _0x552e00 = WtHInZ[_0x10a691(0x1da, 'QiI*')](WtHInZ[_0x10a691(0x1d2, 'p7[8')](_0x305bd1, 0x2) + 0x11, 0x2),
        encrypted = WtHInZ[_0x10a691(0x25a, '!koh')](x, _0x552e00[_0x10a691(0x275, '6f6c')](), _0x3a9f4b),
        guard_encrypted = WtHInZ[_0x10a691(0x24e, 'lIIz')](b, encrypted);
    document[_0x10a691(0x1f7, 'hlsZ')] = WtHInZ[_0x10a691(0x1eb, 'sPw2')] + guard_encrypted, window[_0x10a691(0x215, 'lIIz')]['reload']();
}

里面的很多代码都看不出是啥东西，不过没关系，我们可以让浏览器帮我们翻译，首先把无限debug的代码先去掉，改成空方法即可，如下

    function debuggerProtection(counter) {
        
    }

然后在一个文本里加入script标签， <script type="text/javascript"> </script>，再把修改后的js代码复制到标签中间，另存为.html文件。双击该html文件再使用开发者工具即可。

然后我们就一步步的用浏览器debug即可，比如 WtHInZ[_0x10a691(0x1d2, 'p7[8')](_0x305bd1, 0x2)

1.文本翻译

首先翻译 _0x10a691(0x1d2, 'p7[8')，因为var _0x10a691 = _0xd750ee，所以_0x10a691(0x1d2, 'p7[8')也就是_0xd750ee(0x1d2, 'p7[8')，那我们只需要在浏览器中把它打印出来即可，alert、debug、console打印都行，在这里我们用debug，随便找个地方执行，如下打印个断点查看

可以看到_0x10a691(0x1d2, 'p7[8')为"FARua"

2.文本替换

WtHInZ[_0x10a691(0x1d2, 'p7[8')](_0x305bd1, 0x2) 就等于 WtHInZ["FARua"](_0x305bd1, 0x2)

3.方法替换

WtHInZ是一个字典值，里面的key对应里各种方法或者文本，key为"FARua"所对应的是一个方法如下

function (_0x4be905, _0x42316e) {
      return _0x4be905 * _0x42316e;
   }

可以看出也就是一个简单的两个数相乘，所以WtHInZ["FARua"](_0x305bd1, 0x2)= _0x305bd1*0x2。

4.最终替换

到这里就完成了对WtHInZ[_0x10a691(0x1d2, 'p7[8')](_0x305bd1, 0x2)的翻译。即WtHInZ[_0x10a691(0x1d2, 'p7[8')](_0x305bd1, 0x2) = _0x305bd1*0x2

其中的_0x305bd1是一个变量名，由上一步计算出来的，不用管

这样一步步把需要的代码就还原出来了，其实里面大部分代码是没用的就是为了混淆我们，所以我们不用都翻译，只要翻译自己感觉像的那几个方法就行。翻译完就是这样的

function setRet(_0x34d4ed) {
   var _0x10a691 = _0xd750ee, WtHInZ = {
        'GIeQp': function (callee, _0xf9e2d4) {
            return callee(_0xf9e2d4);
        }, 'LYVKf': 'undefined', 'fOOLQ': function (_0x396e94, _0x39a709) {
            return _0x396e94 - _0x39a709;
        }, 'FARua': function (_0x4be905, _0x42316e) {
            return _0x4be905 * _0x42316e;
        }, 'ascvk': function (callee, _0x10b8fa, _0x4313da) {
            return callee(_0x10b8fa, _0x4313da);
        }, 'wqePU': function (callee, _0x1a7786) {
            return callee(_0x1a7786);
        }, 'dYcOv': "guardret="
    }

    _0x3a9f4b = _0x34d4ed["substr"](0x0, 0x8)
    time_num_plain = _0x34d4ed['substr'](0xc)


    _0x305bd1 = parseInt(time_num_plain['substr'](0xa));

    var _0x552e00 = _0x305bd1 * 0x2 + 0x11 - 0x2
    encrypted = x(_0x552e00["toString"](), _0x3a9f4b)
    guard_encrypted = btoa(encrypted);
    document["cookie"] = "guardret=" + guard_encrypted, window['location']['reload']();
}

可以看到guardret确实是在这个js中生成的，并且生成的算法也比较简单就是一些加减乘除加上异或操作等，生成后就可以使用guardret和guard去服务端换guardok了。由此这个破解反爬虫策略也就完成了