当前位置:   article > 正文

斗鱼关注人数爬取 ── 字体反爬的攻与防_斗鱼 爬虫 逆向

斗鱼 爬虫 逆向

之前因为业务原因需要爬取一批斗鱼主播的相关数据,在这过程中我发现斗鱼使用了一种很有意思的反爬技术,字体反爬。

打开任何一个斗鱼主播的直播间,例如 这个主播,他的关注人数数据显示在右上角:
在这里插入图片描述
斗鱼在关注数据这里使用了字体反爬。什么是字体反爬?也就是通过自定义字体来自定义字符与渲染图形的映射。比如,字符 1 实际渲染的是 9,那么如果 HTML 中的数字是 111,实际显示就是 999。

在这种技术下,传统的通过解析 HTML 文档获取数据的方式就失效了,因为获取到的数据并不是真实数据。

下文中所谈的具体细节高度依赖斗鱼网页的实现,很有可能当你阅读这篇文章的时候已经不再是那样。虽然代码会过时地很快,但是,技巧和方法是永远不会过时的。

进攻

感兴趣的读者可以打开控制台,看看显示关注人数的那个 span 元素里面的内容,会发现根本不是显示的数字。

在这里插入图片描述
从上图可以看出,显示的是 59605,这个是真实值,但是字符却是 96809,这个是虚假值。右边的 font-family 告诉我们这个元素使用了一个自定义字体。

从 Network 面板中的我们可以找到这个字体,具体链接是 mpepc5unpb.woff

如果大家将字体下载下来,使用如下的 HTML 代码来渲染它,我们就可以看得很清楚:

<!DOCTYPE html>
<html>
<head>
  <style type="text/css">
    @font-face {
     
      font-family: test;
      src: url(mpepc5unpb.woff);
    }

    div {
     
      font-family: test;
      font-size: 80px;
      text-align: center;
      margin: 200px 0;
    }
  </style>
</head>
<body>
  <div>
  0123456789
  </div>
</body>
</html>
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25

在这里插入图片描述

在这个字体中,字符 0 会渲染图形 0,字符 1 会渲染图形 7,以此类推,因此,HTML 中的字符 96809 渲染的图形就是 59605

这个原理不难理解,我们甚至不需要知道字体文件内部的具体格式。因为不管怎样,字体内部一定有一个映射关系。这个关系规定了什么样的字符渲染什么样的图形。

正常情况下,字符 1 对应的图形是 1 的形状,但是通过修改字体,我们就可以让字符 1 对应的图形是 9 的形状,或者说,其他任意形状。

这样以来,HTML 中的字符就完全失去了意义,这个字符所代表的的含义要依据字体来定。

上面这个字体实际上定义了一个 01234567890741389265 的映射,拿到 HTML 中的字符我们需要根据这个映射才能得到真正的值。

刷新斗鱼你会发现,字体又变了,所以它那边肯定是有一个字体库的,但是这个不关键,解决一个就解决了所有。

那么,如何解决字体反爬从而得到真实关注人数?

分析

现在我们知道,如果要获取关注人数,我们必须要获取

  • HTML 中的原始值,也就是假值
  • 字符与真正数字之间的映射关系

这两个问题都不太好解决,我们先谈第一个。

斗鱼的这个关注人数很明显是 JS 渲染的,我们有两条路可以走:

  • 使用 Headless Browser。也就是使用一个完整的浏览器来渲染整个页面,然后获取 DOM 中的值。这个是兜底办法,永远可行,但是缺点是效率太差。大家可以看一下打开斗鱼直播间页面的速度,正常情况下等到关注人数显示的时候至少需要 5 秒钟。
  • 我们找到数据源。找到斗鱼的 JS 是请求了哪个接口获取到了数据,然后直接请求该接口。

第二个办法的效率会高很多,但是同时也困难很多。因为 JS 通过什么手段获取了数据实在是灵活性太高了,有太多的办法:

  • 可以请求多个接口,然后拼接得到数据
  • 可以请求某个接口,返回变形后的数据,然后 JS 再反向处理
  • 组合上面两种方式

面对一堆压缩后的 JS 代码,我们想通过分析代码的方式来找到数据源是不可行的。不过我们还是有别的手段,这个后面再说。

考虑到性能以及让生活变的更有乐趣,这里我们选择第二种办法。

第一种办法我顺带提一下,使用 Selenium 或者
Puppeteer 都可以。加载网页以后,轮询直到对应的
DOM 中有值即可,通杀任何网站。

现在我们来看第二个问题,也就是如何通过字体来获取映射关系。

通过解析字体文件可以办到吗?不可以,字体文件中存储的是字符和图形的映射,那么对于一个图形,它是我们眼中的 “0” 还是我们眼中的 “1” 字体文件也没法知道,在字体文件眼中就是一堆坐标。

那还能怎么办呢?只能渲染好以后找个人来看吗?

如果时光倒退 20 年回到 2000 年,恐怕只能这样做了。虽然那个时候也有图形识别技术,但是不像现在这样成熟也不像现在这样随手可得。

但是现在是 2020 年,OCR 图形识别技术已经非常成熟了,我们随便找个 OCR 库应该就够用了。

所以这个问题的解决方案也有了,我们使用字体渲染好图形,然后调用 OCR 识别图形对应的数字便可以获取到映射关系。

按照这个思路,我们整个流程便是

  • 寻找数据源
  • 根据数据源获取字体文件和假数据
  • 根据字体文件渲染图形
  • 使用 OCR 识别图形得到映射关系
  • 根据映射关系和假数据得到真数据

数据源

现在我们来找数据源,看看斗鱼的 JS 到底是从哪里获取的字体信息和假数据。

这其实是一个很有意思的过程,我建议有兴趣的同学先暂停下来,花点时间自己试着找找,看能不能找到。

我的第一个想法很简单,JS 一定是通过某个接口得到了这些数据,那么,我们把所有网络请求导出为 HAR 格式,然后在里面搜索试试。

在这里插入图片描述

点击上图中标记为红色的按钮就可以导出请求为 HAR 格式,HAR 是一个文本格式,非常有利于搜索。

我试了用假数据也就是 96809 和字体 ID mpepc5unpb 来搜索,都没有任何结果。

只能说我们的运气不太好,这里情况实在太多了,有可能返回的值经过了一定的处理比如 base64 或者 rot13,也有可能是多接口返回然后再拼接组装。我们没办法进一步验证,只能放弃这条路。

其实在大部分情况下,使用关键词搜索一下 HAR 是很有效的手段,很容易找到对应的接口。

既然此路不通,我们换个思路,请求到了数据以后,JS 代码一定会调用相关 API 去修改 DOM,能不能监听到这个动作?在它修改 DOM 的时候打上断点,这样就可以通过调用栈知道是哪段 JS 在做此操作,然后顺腾摸瓜找到对应的接口。

答案是是可以的,通过使用 MutationObserver 我们可以监听任意 DOM 的修改事件。

new MutationObserver((mutations, observer) => {
   
  const el = document.querySelector("span.Title-followNum")
  if (el != null) {
   
    observer.disconnect()
    new MutationObserver((mutations, observer) => {
   
      debugger
    }).observe(el, {
   childList: true, subtree: true})
  }
}).observe(document, {
   childList: true, subtree: true})
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14

通过 Tampermonkey 加载上面的代码,刷新,等待断点触发。

在这里插入图片描述
从上面的调用栈可以看出,数据来源自 WebSocket。

去 Network 面板中看一下,果然是这样。

在这里插入图片描述

之后爬取像斗鱼这样的复杂网站,应该先检查一下 WebSocket 中的消息。

这个消息格式很好理解,我们可以猜到 cfdc@=63206 表示字符为 63206,ci@=t3gadgbaon 表示字体 ID 是 t3gadgbaon,和 DOM 对照一下,确实如此。

至此我们的数据源问题解决了一半,我们知道了数据是来自 WebSocket 发送的响应。但是,如何程序化去获取这个响应?

协议

分析 WebSocket 消息会发现,客户端连接以后会发送一条登录消息,然后服务端会回复多个消息,其中,就有我们感兴趣的 followed_count

客户端发送的消息如下:

在这里插入图片描述

虽然是二进制消息,但是可以看到消息主体都是可读的文本,很明显,斗鱼这里是自己实现了一个内部协议格式。

开头 12 个字节暂时不清楚什么含义,然后紧跟着一段键值对数据,使用 @= 连接键和值,使用 / 分割,最后跟上 /\x00

多查看几个直播间以后,对于开头的 12 个字节,我们不难分析出前四个字节和消息长度有关,使用 Little Endian,中间四个字节和前四个字节相同,而最后四个字节是固定值 0xb1 0x02 0x00 0x00

上面的消息长度是 287 个字节,而 0x0000011b = 283,所以,长度编码的值实际上是整个消息的长度减去 4。

这里设计其实挺奇怪的,长度信息比实际长度少了四个字节,同时开头又多了四个字节的冗余数据,怎么看怎么都像是设计失误,第二个四字节是多余的。

对于一个协议来说,作为外部人员,我们是永远无法弄清楚有些问题的成因的。可能这四个字节有其他用处,可能就是设计失误,也有可能一开始没有这四个字节,后来因为
bug 不小心加上了,然后为了后向兼容,就一直带上了。

现在我们来看具体的键值对:

type@=loginreq
roomid@=7874579
dfl@=sn@AA=105@ASss@AA=1
username@=
password@=
ltkid@=
biz@=
stk@=
devid@=4d9c39a8a93746b6db53675800021501
ct@=0
pt@=2
cvr@=0
tvr@=7
apd@=
rt@=1593623035
vk@=6e9dfb63cdae310f97700a750b2fa47f
ver@=20190610
aver@=218101901
dmbt@=chrome
dmbv@=83
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20

这些参数中,type, roomid, devid 都很好理解,dfl, ver, aver, dmbt, dmbv 这些看起来像是不重要的信息携带字段。

rt 很容易发现是一个秒级时间戳,现在唯一剩下的就是 vk 这个字段。我们可以通过修改字段值的方式来大致判断字段的作用和重要性。

如果我们原封不动的使用这个请求体(在检查器中右键选择 Copy message... -> Copy as hex)请求斗鱼的 WebSocket 服务,会发现一开始是有正常响应的,但是过几分钟后就报错了。

const WebSocket = require("ws")

const ws = new WebSocket("wss://wsproxy.douyu.com:6672/")

ws.
  • 1
  • 2
  • 3
  • 4
声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/爱喝兽奶帝天荒/article/detail/998550
推荐阅读
相关标签
  

闽ICP备14008679号