浏览器资源嗅探是怎么工作的一条 M3U8 请求在 Cat-Catch 里的六道关卡【免费下载链接】cat-catch猫抓 浏览器资源嗅探扩展 / cat-catch Browser Resource Sniffing Extension项目地址: https://gitcode.com/GitHub_Trending/ca/cat-catch猫抓 Cat-Catchcat-catch是一款浏览器资源嗅探扩展被动监听页面网络请求识别出视频、音频并提供 M3U8 切片解析与合并下载器结果可走浏览器保存、边下边存、在线 ffmpeg、aria2、MQTT 等通道。下面跟着一条 M3U8 请求走一遍它从被看见到落盘的全过程每到一个关卡展开一个机制事实以 v2.7.4 的代码为准。webRequest 双钩子拦截 → findMedia 多级过滤 → cacheData 按 tabId 分桶 → storage.session 落盘 → popup 读取 → m3u8.html 解析 → Downloader 切片合并 → 落盘通道关卡一 · webRequest 怎么在两个时间点截住一次请求 打个比方门卫分两次登记。第一次是出门先把访客递的证件抄一份留底第二次是进门拿同一张凭证把进出信息拼成一条完整记录。js/background.js 里挂了两组webRequest钩子onSendHeaders请求发出时触发把requestHeaders按requestId存进内存 MapG.requestHeaders顺便跑一遍用户配置的正则匹配。之所以要在这里暂存是因为 Referer 这类请求头在响应阶段拿不到了。onResponseStarted收到响应第一个字节时触发用同一个requestId取回暂存的请求头取完即删再交给findMedia做类型判断——此时content-type、content-length才可用。onErrorOccurred请求失败时清理暂存防止 Map 泄漏。留底的请求头不是全部留下。getRequestHeaders只挑有用的referer、origin、cookie、authorization 等固定名单外加名字里带auth|token|sign|key|ticket|session的x-头。这些头之后会跟着资源一起传给下载器重放请求时带上能提高下载成功率。关卡二 · 是媒体吗findMedia 的多级过滤 不是所有请求都值得入库findMedia是一套先粗后细的筛选链阶段判断依据未通过的结果全局前置G.enable开关、页面屏蔽列表黑白名单、OPTIONS预检直接丢弃自定义正则用户配置的G.Regex在onSendHeaders阶段先跑可改写 URL或标记该请求后续一律丢弃文件扩展名URL 路径取扩展名CheckExtension校验 大小判断break丢弃Content-TypeCheckType支持video/*这类通配break丢弃attachment 文件名content-disposition里提取filename重新验扩展名丢弃webRequest 类型标记data.type media直接放行其中扩展名和 Content-Type 的大小判断从 2.6.8 起支持表达式比如100 KB、500-1000 MB等于给多小算视频加了一道可调的闸门。过滤通过的资源还会做一层查重按标签维护 URL 指纹集合条目数到 500 就清空重算——避免大列表下逐条比对拖垮 CPU。webRequest只看得到真实网络流量抓不到blob:和 WebRTC 这类隐身数据。这块由注入页面主动补刀webNavigation.onCommitted里按配置注入 catch-script/search.js深度搜索、缓存捕获、WebRTC 录制脚本找到媒体后通过addMedia消息回传 background重新进入findMedia走同一套过滤。manifest.json 的commands也提供了catch、deepSearch、m3u8等快捷键入口。关卡三 · 嗅探列表存哪cacheData 分桶与 99、9999 两个数字 命中的资源按tabId分桶存进内存对象cacheData每个标签页一个桶。写入不是每条都刷盘而是一套节流列表超过 100 条时5 秒防抖攒一批再存两次写入间隔不足 500ms 时延后 2 秒再存单标签超过 99 条后停止逐条落盘改为依赖chrome.alarms的save事件周期性补写防止高频站点刷爆存储单标签超过 9999 条G.maxLength直接清空该桶防内存膨胀。落盘目标是storage.session ?? storage.local——这一行?? 降级值得单独说。类比仓库把今天收货记录放在门口的白板内存级、随会话清空把仓库规章锁在档案柜持久化里。2.5.3 之前嗅探列表写在storage.local磁盘 IO 错误会导致扩展整体不可用迁到storage.sessionChrome 104后高频写免了磁盘放大低版本浏览器又靠??自动回落storage.local。代价是列表只活在当前会话关浏览器即清空无法跨会话恢复。偏好设置、屏蔽列表仍走local/sync两类数据互不污染。popup 打开时向 background 发getData消息background 从cacheData[tabId]取出本标签的分桶数据渲染出资源列表——js/popup.js 同时还会发一条HeartBeat消息这是下一关的伏笔。关卡四 · 后台被杀了怎么办HeartBeat 保活与 500ms 自愈 MV3 的 Service Worker 空闲约 5 分钟会被强杀而嗅探列表就在它的内存里。猫抓的选择是和进程管理器打时间差// js/background.js —— 收到页面侧的 HeartBeat 长连接 chrome.runtime.onConnect.addListener(function (Port) { if (chrome.runtime.lastError || Port.name ! HeartBeat) return; Port.postMessage(HeartBeat); const interval setInterval(function () { clearInterval(interval); Port.disconnect(); // 4分10秒主动断开抢在5分钟强杀前 }, 250000); });配合 js/content-script.js 页面对onDisconnect重连续连以及每 25 秒一次的getPlatformInfo调用、webNavigation监听注册共同把 Worker 拖在死亡线上。这是保活路线。另一条是自愈路线findMedia入口先检查全局变量是否初始化完毕若进程刚被唤醒G.initSyncComplete还没就绪setTimeout500ms 后重放这次请求给醒来后的第一波流量留缓冲。Firefox 不需要这套manifest.firefox.json 用background.scripts事件页常驻。代价是 Chromium 这套保活依赖其具体实现细节浏览器升级随时可能让它失效——两条生命周期路线要长期双维护。关卡五 · M3U8 切片下载器乱序下载但按序合并 用户勾选一条 M3U8 资源会打开m3u8.html解析器。页面里用hls.js发loadSource监听MANIFEST_LOADED、LEVEL_LOADED等事件把切片对象收集进_fragments同时抓取EXT-X-KEY声明的密钥深度搜索挖出的疑似密钥经catCatchAddKey消息也能汇入。真正干活的是 js/m3u8.downloader.js 的Downloader类js/m3u8.js 中new Downloader(fragments, 线程数)实例化默认 6 线程。它的核心思路是下载和推送解耦// js/m3u8.downloader.js —— 按原始顺序推送 buffer sequentialPush() { if (!this.events[sequentialPush]) { return; } for (; this.pushIndex this.fragments.length; this.pushIndex) { if (this.buffer[this.pushIndex]) { this.emit(sequentialPush, this.buffer[this.pushIndex]); // 推给合并/流写出 delete this.buffer[this.pushIndex]; continue; } break; // 这一片还没回来就停住等绝不出乱序 } }index只管取下一片去下载pushIndex单独负责按顺序往外发buffer按切片下标存放所以下载可以完全乱序、并行而输出永远有序。围绕它还有一套字段各管一件事errorIndexesautoRetry失败切片记入集合2.7.1 起开启自动重试最多MAX_RETRIES3 次按500ms × 次数退避controller每片一个AbortController支持整单中止或只停某一片pipelineuse注册buffer 到手后过处理管线可挂剔除伪装 PNG 头部的预处理、AES 解密、转 mp4 转封装byteRange遇到EXT-X-BYTERANGE标签2.6.8 起支持合并时自动给fetch加Range请求头。针对一次性 URL刷新后 404 的临时 m3u8 地址2.7.0 的解法是让 content-script 用fetch(url, { cache: force-cache })直接从浏览器缓存里把 m3u8 文本捞出来不再依赖还能访问的服务器。关卡六 · 落盘通道与版本边界 合并完成的 buffer 有几条出口按场景选通道触发说明chrome.downloads.download默认 / 自动下载浏览器原生下载可指定文件名边下边存StreamSaver勾选StreamSaver走 lib/StreamSaver.js 的文件流sequentialPush数据边下边写直播流适用估算超过 2GB 时会弹窗强制切到该模式在线 ffmpeg勾选 ffmpegcatCatchFFmpeg消息投给 ffmpeg 网页标签2.6.8 起支持嵌套 iframe 模式免开新标签aria2 / MQTT / 本地程序send2local数据发送把资源元数据含完整请求头POST 给指定地址交给外部下载器边界方面几个硬门槛值得记住Chromium 114 以下缺少sidePanelAPI扩展无法使用2.6.3 修复记录storage.session要求 Chrome 104低版本回落storage.local磁盘写放大的老风险仍在Firefox 需 113strict_min_version且深度搜索、缓存捕获、WebRTC 录制等注入脚本类功能要 Firefox 1282.5.7深度搜索/缓存捕获是注入页面的主动脚本2.6.5、2.6.6、2.7.3 反复修复过导致某些网站无法显示/使用2.6.5 因此加入全局强制屏蔽兜底单标签 99 条后停写、9999 条上限清空高频站点下列表可能被截断。能直接搬走的有两样一是webRequest 双钩子 按requestId暂存请求头的模式任何做流量嗅探的扩展都绕不开二是index / pushIndex / errorIndexes / controller四字段状态机把乱序下载、顺序合并、失败重试、可中断四个场景各管一段。需要提醒的是HeartBeat 保活本质是和浏览器进程管理抢时间若你的扩展要长寿更稳的做法是让后台状态可重建、被杀后能自愈——猫抓的 500ms 重放正是这条路线的补丁。【免费下载链接】cat-catch猫抓 浏览器资源嗅探扩展 / cat-catch Browser Resource Sniffing Extension项目地址: https://gitcode.com/GitHub_Trending/ca/cat-catch创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考