猫抓Cat-Catch深度解析:浏览器扩展如何在MV3沙盒规则下逆袭成专业级媒体下载平台

📅 2026/8/21 17:10:37
猫抓Cat-Catch深度解析:浏览器扩展如何在MV3沙盒规则下逆袭成专业级媒体下载平台
猫抓Cat-Catch深度解析浏览器扩展如何在MV3沙盒规则下逆袭成专业级媒体下载平台【免费下载链接】cat-catch猫抓 浏览器资源嗅探扩展 / cat-catch Browser Resource Sniffing Extension项目地址: https://gitcode.com/GitHub_Trending/ca/cat-catch猫抓Cat-Catch是一款开源的浏览器资源嗅探扩展它把网页上看到的视频、音频、m3u8流媒体统统变成可下载的文件甚至支持切片合并、AES解密、实时转码。最值得讲的技术亮点是它在Manifest V3MV3几乎苛刻的安全限制下用一套Service Worker保活 多路嗅探 流水线下载的组合拳硬是把扩展做成了一个小型媒体处理平台。本文从几个关键设计问题切入逐层拆解它如何做到。先看真实场景为什么看得到却下不到你在网页上点开一段视频浏览器把数据从服务器拉到本地视频能播、能拖进度条可你右键保存却只有一个空文件夹。原因很简单现代网页视频几乎不给你直链。它们要么藏在blob:协议里要么被切成几十个.ts分片再通过 m3u8 播放清单动态加载要么干脆用 MediaSource 接口边下边播、随播随弃。普通嗅探工具只能看到发出去的请求而猫抓面对的是三类完全不同的隐藏形态必须在一个扩展里同时破解网页媒体隐藏形态与嗅探对策 ├── 形态A普通直链.mp4 / .mp3 │ ├── 特征URL 直接带扩展名 │ ├── 对策webRequest 监听 正则匹配扩展名 │ └── 难点防盗链 Referer、动态签名 URL │ ├── 形态Bblob: / MediaSource 流媒体 │ ├── 特征数据以二进制 chunk 喂给播放器 │ ├── 对策代理 MediaSource 方法 录制 buffer │ └── 难点无法直接拿到完整文件需边收边存 │ └── 形态CHLS / DASH 分片流m3u8 / mpd ├── 特征清单文件 数十上百个分片 ├── 对策解析清单 → 下载分片 → 合并/转码 └── 难点AES-128 加密密钥、一次性 URL这个决策树决定了猫抓的整体技术路线不是选一条路走到底而是三路并行、按需兜底。这也是它区别于普通嗅探插件的根本——后面所有章节都是围绕这三个分支的落地展开。问题一MV3 把后台脚本变成30 秒处决的临时工怎么让它活着MV3 最让扩展开发者头疼的改动是常驻的后台页面被替换成 Service Worker浏览器会在空闲约 30 秒后将其强制终止所有内存中的状态一并消失。对猫抓这类需要持续监听webRequest的扩展来说这是致命的——你正在下载一半的分片任务可能因为 worker 被杀而瞬间中断。猫抓的解法很直接主动制造心跳让 worker 永不空闲。看js/background.js里的核心代码// 关键注册两个空操作监听器触发后浏览器会重新唤醒 worker chrome.webNavigation.onBeforeNavigate.addListener(function () { return; }); chrome.webNavigation.onHistoryStateUpdated.addListener(function () { return; }); // 页面侧建立长连接充当心跳让 worker 保持活跃 chrome.runtime.onConnect.addListener(function (Port) { if (Port.name ! HeartBeat) return; Port.postMessage(HeartBeat); // 每 250 秒重置一次连接规避超时上限 const interval setInterval(function () { clearInterval(interval); Port.disconnect(); }, 250000); }); // 兜底每 25 秒调用一次平台 API进一步刷新活动时间戳 setInterval(chrome.runtime.getPlatformInfo, 25 * 1000);这套心跳保活是社区公认的 MV3 破解手段但猫抓还多了一层防御所有全局数据URL 查重 Map、请求头缓存都靠chrome.storage.session定时持久化并在findMedia入口处做了worker 被强杀后自我唤醒的补偿逻辑function findMedia(data, isRegex false, filter false, timer false) { // 如果全局变量还没初始化完成worker 刚被重启500ms 后重试 if (!G || !G.initSyncComplete || !G.initLocalComplete || cacheData.init) { if (timer) return; setTimeout(() findMedia(data, isRegex, filter, true), 500); return; } // ... 正式的资源匹配逻辑 }结论猫抓证明了 MV3 不是不能做长任务而是必须为无常设计。它的经验是——要么用心跳续命要么让每次重启都无痛。这两者猫抓都做到了。问题二嗅探只看得见 URL怎么看见视频本身webRequest能告诉你浏览器向哪发了请求但拿不到响应体。对于形态 A直链这够用了猫抓在onSendHeaders和onResponseStarted两个时机都挂上监听前者拿到请求头用于防盗链后者等响应头返回后结合 Content-Type 判断媒体类型再交给init.js里预置的 30 多种扩展名与 9 类 MIME 规则去匹配。但形态 Bblob 流媒体和形态 C分片流就棘手了。猫抓针对 blob 流的核心杀招是代理 MediaSource 的addSourceBuffer等方法在网页把二进制数据喂给播放器之前先让扩展截胡一份。同时它用MutationObserver监控 DOM 中新增的 iframe把带sandbox属性的 iframe 克隆后移除该属性让脚本能渗透进隔离的子页面对应 CHANGELOG 里的 issues #576 修复。面对完全拿不到数据、只能录屏的极端场景猫抓还内置了基于MediaRecorder的录制脚本catch-script/recorder.js支持选编码、码率、帧率甚至每 1 小时自动落盘一次防止长时间录制丢数据。整个捕获层因此形成三级兜底猫抓三层捕获架构 ├── 第 1 层webRequest 网络嗅探catch 直链 │ └── 手段onSendHeaders onResponseStarted 正则规则 ├── 第 2 层MediaSource 代理 缓存捕捉catch 流媒体 │ └── 手段addSourceBuffer 重写 sandbox iframe 处理 └── 第 3 层MediaRecorder 录制catch 一切可播放内容 └── 手段Shadow DOM 悬浮面板 分时自动保存结论猫抓的嗅探哲学是分级设防——能正则匹配就匹配匹配不到就劫持 API劫持不到就录屏。每一层都只解决上一层漏掉的东西这种洋葱式设计让覆盖率最大化而每层的代码量又保持最小。问题三一个 m3u8 清单怎么变成电脑里的 mp4如果说嗅探是入口那么js/m3u8.js才是猫抓的重工业区。它直接复用了 hls.js 的解析内核把 m3u8 清单里的切片列表、加密信息、分辨率档位全部结构化再逐一下载分片并合流输出。面对 AES-128 加密它在页面侧维护了一个keyContentMap把从网页里捡到的密钥缓存起来// 来自 js/m3u8.js 的加密处理设计 const keyContent new Map(); // 缓存解密密钥避免重复拉取 const decryptor new AESDecryptor(); // hls.js 中分离出的解密器 // 支持自定义密钥用户可手动填写 HEX / Base64绕过密钥抓取失败 // 同时用 possibleKeys 集合收集疑似密钥供深度搜索兜底 let skipDecrypt false; // 用户可强制跳过解密明文流下载端则结合StreamSaver做流式落盘——不占满内存边下载边写文件分片支持任意勾选、范围下载如只下 1-64 片、EXT-X-BYTERANGE字节区间合并2.6.8 版本新增。更进阶的是转码链路猫抓把分片数据喂给页面内嵌的mux.js 转封装器实现 TS→MP4 免重编码的快速封装或把任务转发给在线 FFmpeg2.6.8 起支持嵌套 iframe 模式不再新开标签页解决了文件传丢的老问题。整条链路可以画成一条流水线每个环节都能独立替换m3u8 资源处理流水线 ├── 解析阶段hls.js 内核解析清单分片/密钥/码率档位 ├── 获取阶段按 URL 下载分片携带 Referer 与自定义头 ├── 解密阶段AESDecryptor 按 keyContent 解密支持用户手动喂 Key ├── 转码阶段mux.js 封装 TS→MP4 或转发在线 FFmpeg └── 输出阶段StreamSaver 流式写盘 / 发送 Aria2 RPC结论猫抓把下载一个 m3u8从拉文件升级成了五级流水线。它没有自己造轮子而是精准拼装hls.js、mux.js、StreamSaver 等成熟库把精力集中在它们之间的胶水逻辑密钥管理、任务编排、进度与重试上——这是开源项目控制复杂度的教科书做法。问题四下载线程到底开几个这是技术问题也是伦理问题下载线程数是个看似简单、实则敏感的旋钮。开少了速度慢开多了会把目标服务器打得喘不过气。猫抓在 m3u8 解析器里把线程数做成可配置界面默认 6可调至 32同时在下载器侧实现了失败自动重试与动态节流。选择6这个数字背后有明确权衡线程数下载速度对服务器压力失败概率适用场景最终选择1慢极低低弱网/对方限流保守档6快可控低绝大多数站点✅ 默认32极快高高易触发风控自建 CDN / 内网高级档配套的还有storage.session与storage.local的存储取舍——会话存储稳定性高、但刷新即失本地存储能持久化、但有 IO 写入风险。猫抓最终选择chrome.storage.session ?? chrome.storage.local的降级写法优先会话级个别环境自动回退本地并在alarms定时任务里定期落盘MediaData两头的好处都拿到。结论并发控制不是越大越好而是在体验与生态之间取平衡。猫抓把选择权交给用户、把默认值留给经验——6 线程是它在大量站点实测后不挨骂的甜蜜点。问题五十个语言版本靠什么撑起来还不乱猫抓从 2.5.0 开始推进国际化如今_locales/下已经有 10 种语言en、zh_CN、zh_TW、es、ja、ko、pt_BR、ru、tr、vi。关键在于它没有把翻译硬编码进 JS而是全走 Chrome 原生__MSG_xxx__机制 运行时 i18n 工具函数_locales/ ├── en/messages.json # 英语默认回退语言 ├── zh_CN/messages.json # 简体中文 ├── es/messages.json # 西班牙语 ├── ja/messages.json # 日语 ├── ko/messages.json # 韩语2.7.1 由社区贡献 ├── ru/messages.json # 俄语 ├── vi/messages.json # 越南语 └── tr/messages.json # 土耳其语这种结构的价值远超多语言本身翻译贡献者完全不需要懂代码只需编辑 JSON每种语言是独立文件合并冲突面小缺翻译时自动回退到英文界面永远不会出现空白。社区成员CHANGELOG 里逐个署名感谢通过 GitLocalize 之类的平台持续提交让国际化变成了滚动的社区活水。结论猫抓的国际化是架构先行的社区驱动模式——用标准机制降低门槛用独立文件隔离风险用回退策略兜底体验。一个 10 语言项目能靠社区持续维护靠的不是热情是结构。三条可复用的技术启示给无常设计而不是对抗它。MV3 的 Service Worker 随时可能死猫抓的答案不是让它不死而是死了能无痛复活心跳 定时持久化 重启重试。任何长任务场景下载、轮询、上传都值得抄这套组合。成熟库当零件胶水逻辑自己写。hls.js、mux.js、StreamSaver、mpd-parser——猫抓没有重写任何一个它的独创性全部在如何编排这些零件密钥缓存、任务编排、防盗链头传递。对中小型开源项目这比自研内核划算得多。默认值给保守选项给专业。6 线程默认、32 线程高级可选普通嗅探默认开、深度搜索默认关。把开箱即用和上限开放分开是工具类产品最稳妥的体验策略。至于未来猫抓的技术底座已经预留了三块跳板2.6.4 引入的MQTT 协议支持让浏览器→云端任务分发成为可能云原生方向深度搜索持续增强正在向自动发现密钥与隐藏资源进化而declarativeNetRequest权限与正则规则引擎则为浏览器端 AI 辅助的资源分类留下了想象空间。从嗅探到下载再到转码猫抓的每一步都在证明同一件事浏览器沙盒不是天花板而是逼你做出更好架构的考场。【免费下载链接】cat-catch猫抓 浏览器资源嗅探扩展 / cat-catch Browser Resource Sniffing Extension项目地址: https://gitcode.com/GitHub_Trending/ca/cat-catch创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考