您的位置:首页 > 汽车 > 新车 > 破解反爬虫策略 /_guard/auto.js(一) 原理

破解反爬虫策略 /_guard/auto.js(一) 原理

2024/12/24 1:55:25 来源:https://blog.csdn.net/cjc000/article/details/140476371  浏览:    关键词:破解反爬虫策略 /_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。

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

  1. 第一次访问,在响应头中的cookie里返回了guard,并且返回的报文体中返回了那个js文件
  2. 第二次访问,在响应头中的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 - 0x2encrypted = x(_0x552e00["toString"](), _0x3a9f4b)guard_encrypted = btoa(encrypted);document["cookie"] = "guardret=" + guard_encrypted, window['location']['reload']();
}

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

完整破解实战

下一篇文章我会实战破解两个这种反爬虫策略的网站,并用java实现

版权声明:

本网仅为发布的内容提供存储空间,不对发表、转载的内容提供任何形式的保证。凡本网注明“来源:XXX网络”的作品,均转载自其它媒体,著作权归作者所有,商业转载请联系作者获得授权,非商业转载请注明出处。

我们尊重并感谢每一位作者,均已注明文章来源和作者。如因作品内容、版权或其它问题,请及时与我们联系,联系邮箱:809451989@qq.com,投稿邮箱:809451989@qq.com