猫抓Cat-Catch的取舍之道一个嗅探扩展凭什么敢碰加密视频、多线程下载和实时转封装【免费下载链接】cat-catch猫抓 浏览器资源嗅探扩展 / cat-catch Browser Resource Sniffing Extension项目地址: https://gitcode.com/GitHub_Trending/ca/cat-catch先抛一个反常识的现象一个定位为嗅探的浏览器扩展代码库里却躺着 HLS 解密器、TS 转 MP4 的转封装模块、可调线程数的分片下载器、边下边存的流式写入器甚至还有 MQTT 推送通道。嗅探这个词本意是看一眼就走——列出页面资源、给出直链任务就结束了。可猫抓 Cat-Catch 偏偏长成了一个小型媒体处理平台。这不合理。一个嗅探工具凭什么越界到这种程度答案是它不这么做用户的真实需求就落不了地。而支撑它做到这一点的是几十个在平台限制里讨价还价的技术取舍。先看用户怎么用再看架构怎么长还原一个再普通不过的场景用户点开某个视频页页面通过 MediaSource 扩展MSE把视频切成几十上百个分片喂给video标签地址栏里永远只有一行blob:。用户想要的是把这个视频存下来浏览器给他的却是一段不可寻址的临时内存。嗅探这件事就这样从找到 URL被硬生生升级成了在播放链路里扒出分片清单、解密密钥、以及带 referer 的完整请求上下文。从场景反推架构必须回答三个问题资源会从哪几层冒出来网络层还是页面里的 JS 调用资源以什么形态出现直链、HLS 清单、MPD 清单还是加密分片下载之后要不要二次加工合并、改名、转码。于是猫抓的代码被场景逼成了清晰的三段捕获、解析、输出。catch-script/catch.js驻在页面里当内应js/background.js挂在 webRequest 上当门卫js/m3u8.js与js/downloader.js各自开一个独立页面当车间。架构不是设计出来的是被用户的使用路径一点点撑出来的。三个为什么被放弃的方案往往比被采用的更值钱为什么存储选了会话级宁可重启就丢摆在桌面上的备选有两个storage.local持久但每次写入都可能抛 IO 错误一旦写坏用户的配置跟着陪葬storage.session稳定但会话结束即清空。猫抓的做法是 session 为主、local 兜底、再用alarms定时落盘让持久化变成一件有节奏的、可失败的事而不是一次豪赌。把丢得起的瞬时数据放在高稳定性区把丢不起的配置放在持久区——这就是对存储分级最直白的注脚。嗅探结果本质是可再生数据丢了重抓一遍即可而扩展别崩、配置别丢是不可妥协的信任线。// background.js 中的定时任务周期把捕获数据落盘 chrome.alarms.onAlarm.addListener(function (alarm) { if (alarm.name save) { (chrome.storage.session ?? chrome.storage.local) .set({ MediaData: cacheData }); // session 不可用则降级 local return; } });为什么敢跟 Service Worker 的强制回收掰手腕Manifest V3 里Service Worker 大约 5 分钟就会被浏览器强制回收代码注释里直接引用了 Chromium 的 bug 编号1271154。可嗅探是全天候守门的活SW 一睡网络监听就断。备选方案都不好看彻底不守会错过用户要的资源每次唤醒重建全部状态又慢得没法用。猫抓的选择是心跳保活注册webNavigation的空监听制造活动事件每 25 秒调一次chrome.runtime.getPlatformInfo再开一条名为HeartBeat的 Port 定时重连。这招谈不上正统却是把平台规则摸透之后的务实解。它不是对抗平台而是把平台的回收策略当作约束条件来求解——先承认规则存在再找出规则允许的生存空间。为什么解密功能选择内嵌而不是甩给外部工具HLS 流的 AES-128 加密太常见一个解析器不会解密等于只完成了一半工作。外包给 m3u8DL 这类命令行工具确实省事但用户得先装环境内嵌解密器则是直接塞进主包。猫抓从 hls.js 里剥离出AESDecryptor单独内置让用户在界面上填 key/IV也可以一键跳过解密。代价是包体变大、攻击面变宽换来的却是零外部依赖的完整闭环在浏览器里拿到密钥就在浏览器里解密、合并、转封装全程不落地。对一个面向非技术用户为主的扩展来说这条取舍线的方向几乎不用犹豫。把嗅探讲成两句话装水表和分段接管可以把嗅探理解成在黑箱上装水表。webRequest是装在大门口的总水表每个请求进出都会读数但看不清水管内部的流态MediaSource 代理则是在水管内部再装一只流量计——通过改写页面里的 MediaSource 方法能看见播放器真正吞进了哪些分片。双路并举正好覆盖直链文件和分片流两类主流场景。捕获数据是如何配对的这段逻辑值得细看// background.js按 requestId 暂存请求头响应到达时再配对 chrome.webRequest.onSendHeaders.addListener(data { G.requestHeaders.set(data.requestId, data.requestHeaders); // 先记账 findMedia(data, true); }, { urls: [all_urls] }, [requestHeaders]); chrome.webRequest.onResponseStarted.addListener(data { data.allRequestHeaders G.requestHeaders.get(data.requestId); G.requestHeaders.delete(data.requestId); // 配对完立即释放防止 Map 膨胀 findMedia(data); }, { urls: [all_urls] }, [responseHeaders]);每个请求都以requestId为钥匙暂存区用后即焚——所以G.requestHeaders是个 Map 而不是数组这背后是防止内存无限增长的工程自觉。下载阶段的类比是水管工分段接管几百个 ts 分片不可能一次性塞进内存downloader.js借助 StreamSaver 边下载边写磁盘浏览器内存始终保持平稳。所有这些能力最后都被收敛进一个可视化界面从线程数到密钥框、从下载范围到合并开关一目了然。演进不是推倒重来是顺着 bug 一格格打补丁翻CHANGELOG.md会看到一条特别不性感、却异常有效的演进线2.6.8 支持 EXT-X-BYTERANGE 分片合并2.7.0 从浏览器缓存直接读 m3u8解决一次性 URL问题2.7.1 下载失败自动重试2.7.2 隐藏已下载切片。没有一次宏大叙事的重构全是顺着真实用户 bug 逐个击破。这种打法能成立靠的是模块边界足够干净catch.js只动页面层background.js只动网络层m3u8.js只碰解析改一处不连累全局。有意思的是工程决策不只写在代码里也写在许可证里。1.0 版用 MIT2.0 版改成了 GPL v3README 里直言为了生态希望使用了猫抓源码的扩展保持开源。把防闭源套壳固化进许可证是另一种把社区价值做成规则的手段。国际化的处理同样工程化tools/sync-locales.js以英文为基准其它语言缺失的 key 自动用英文占位贡献者只需要翻译自己负责的那一份文件。从韩语、俄语到越南语CHANGELOG 里长长的致谢名单就是社区驱动模式最好的证据。三条能带走的东西把平台限制当作需求文档来读。SW 回收、存储报错、Trusted Types 强制、iframe sandbox 阻断每一条限制背后都是一个真实的运行环境问题。猫抓的大部分聪明设计都是被限制逼出来的解而不是炫技——比如为了绕过 sandbox 阻断而重写 iframe 节点的处理逻辑这类补丁在代码里俯拾皆是。给数据分级而不是一刀切持久化。瞬时数据放高性能区可再生数据丢了就重抓只有配置这种丢不起的东西才值得放进持久存储。分清丢得起和丢不起能省掉一大半存储架构的复杂度。把社区治理也做成工程。许可证策略、i18n 同步脚本、拒绝抓取的 Opt-Out 清单——这些不是文档是代码是可以被版本管理和持续演进的资产。最后留一个开放问题Chrome 已经不止一次收紧 Service Worker 的存活策略假如某天心跳保活这类技巧被彻底堵死猫抓的监听架构该往哪里走嗅探这个行当大概永远在与平台的不许赛跑——而这恰恰是它最迷人的地方。【免费下载链接】cat-catch猫抓 浏览器资源嗅探扩展 / cat-catch Browser Resource Sniffing Extension项目地址: https://gitcode.com/GitHub_Trending/ca/cat-catch创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 猫抓Cat-Catch的取舍之道：一个嗅探扩展，凭什么敢碰加密视频、多线程下载和实时转封装
猫抓Cat-Catch的取舍之道一个嗅探扩展凭什么敢碰加密视频、多线程下载和实时转封装【免费下载链接】cat-catch猫抓 浏览器资源嗅探扩展 / cat-catch Browser Resource Sniffing Extension项目地址: https://gitcode.com/GitHub_Trending/ca/cat-catch先抛一个反常识的现象一个定位为嗅探的浏览器扩展代码库里却躺着 HLS 解密器、TS 转 MP4 的转封装模块、可调线程数的分片下载器、边下边存的流式写入器甚至还有 MQTT 推送通道。嗅探这个词本意是看一眼就走——列出页面资源、给出直链任务就结束了。可猫抓 Cat-Catch 偏偏长成了一个小型媒体处理平台。这不合理。一个嗅探工具凭什么越界到这种程度答案是它不这么做用户的真实需求就落不了地。而支撑它做到这一点的是几十个在平台限制里讨价还价的技术取舍。先看用户怎么用再看架构怎么长还原一个再普通不过的场景用户点开某个视频页页面通过 MediaSource 扩展MSE把视频切成几十上百个分片喂给video标签地址栏里永远只有一行blob:。用户想要的是把这个视频存下来浏览器给他的却是一段不可寻址的临时内存。嗅探这件事就这样从找到 URL被硬生生升级成了在播放链路里扒出分片清单、解密密钥、以及带 referer 的完整请求上下文。从场景反推架构必须回答三个问题资源会从哪几层冒出来网络层还是页面里的 JS 调用资源以什么形态出现直链、HLS 清单、MPD 清单还是加密分片下载之后要不要二次加工合并、改名、转码。于是猫抓的代码被场景逼成了清晰的三段捕获、解析、输出。catch-script/catch.js驻在页面里当内应js/background.js挂在 webRequest 上当门卫js/m3u8.js与js/downloader.js各自开一个独立页面当车间。架构不是设计出来的是被用户的使用路径一点点撑出来的。三个为什么被放弃的方案往往比被采用的更值钱为什么存储选了会话级宁可重启就丢摆在桌面上的备选有两个storage.local持久但每次写入都可能抛 IO 错误一旦写坏用户的配置跟着陪葬storage.session稳定但会话结束即清空。猫抓的做法是 session 为主、local 兜底、再用alarms定时落盘让持久化变成一件有节奏的、可失败的事而不是一次豪赌。把丢得起的瞬时数据放在高稳定性区把丢不起的配置放在持久区——这就是对存储分级最直白的注脚。嗅探结果本质是可再生数据丢了重抓一遍即可而扩展别崩、配置别丢是不可妥协的信任线。// background.js 中的定时任务周期把捕获数据落盘 chrome.alarms.onAlarm.addListener(function (alarm) { if (alarm.name save) { (chrome.storage.session ?? chrome.storage.local) .set({ MediaData: cacheData }); // session 不可用则降级 local return; } });为什么敢跟 Service Worker 的强制回收掰手腕Manifest V3 里Service Worker 大约 5 分钟就会被浏览器强制回收代码注释里直接引用了 Chromium 的 bug 编号1271154。可嗅探是全天候守门的活SW 一睡网络监听就断。备选方案都不好看彻底不守会错过用户要的资源每次唤醒重建全部状态又慢得没法用。猫抓的选择是心跳保活注册webNavigation的空监听制造活动事件每 25 秒调一次chrome.runtime.getPlatformInfo再开一条名为HeartBeat的 Port 定时重连。这招谈不上正统却是把平台规则摸透之后的务实解。它不是对抗平台而是把平台的回收策略当作约束条件来求解——先承认规则存在再找出规则允许的生存空间。为什么解密功能选择内嵌而不是甩给外部工具HLS 流的 AES-128 加密太常见一个解析器不会解密等于只完成了一半工作。外包给 m3u8DL 这类命令行工具确实省事但用户得先装环境内嵌解密器则是直接塞进主包。猫抓从 hls.js 里剥离出AESDecryptor单独内置让用户在界面上填 key/IV也可以一键跳过解密。代价是包体变大、攻击面变宽换来的却是零外部依赖的完整闭环在浏览器里拿到密钥就在浏览器里解密、合并、转封装全程不落地。对一个面向非技术用户为主的扩展来说这条取舍线的方向几乎不用犹豫。把嗅探讲成两句话装水表和分段接管可以把嗅探理解成在黑箱上装水表。webRequest是装在大门口的总水表每个请求进出都会读数但看不清水管内部的流态MediaSource 代理则是在水管内部再装一只流量计——通过改写页面里的 MediaSource 方法能看见播放器真正吞进了哪些分片。双路并举正好覆盖直链文件和分片流两类主流场景。捕获数据是如何配对的这段逻辑值得细看// background.js按 requestId 暂存请求头响应到达时再配对 chrome.webRequest.onSendHeaders.addListener(data { G.requestHeaders.set(data.requestId, data.requestHeaders); // 先记账 findMedia(data, true); }, { urls: [all_urls] }, [requestHeaders]); chrome.webRequest.onResponseStarted.addListener(data { data.allRequestHeaders G.requestHeaders.get(data.requestId); G.requestHeaders.delete(data.requestId); // 配对完立即释放防止 Map 膨胀 findMedia(data); }, { urls: [all_urls] }, [responseHeaders]);每个请求都以requestId为钥匙暂存区用后即焚——所以G.requestHeaders是个 Map 而不是数组这背后是防止内存无限增长的工程自觉。下载阶段的类比是水管工分段接管几百个 ts 分片不可能一次性塞进内存downloader.js借助 StreamSaver 边下载边写磁盘浏览器内存始终保持平稳。所有这些能力最后都被收敛进一个可视化界面从线程数到密钥框、从下载范围到合并开关一目了然。演进不是推倒重来是顺着 bug 一格格打补丁翻CHANGELOG.md会看到一条特别不性感、却异常有效的演进线2.6.8 支持 EXT-X-BYTERANGE 分片合并2.7.0 从浏览器缓存直接读 m3u8解决一次性 URL问题2.7.1 下载失败自动重试2.7.2 隐藏已下载切片。没有一次宏大叙事的重构全是顺着真实用户 bug 逐个击破。这种打法能成立靠的是模块边界足够干净catch.js只动页面层background.js只动网络层m3u8.js只碰解析改一处不连累全局。有意思的是工程决策不只写在代码里也写在许可证里。1.0 版用 MIT2.0 版改成了 GPL v3README 里直言为了生态希望使用了猫抓源码的扩展保持开源。把防闭源套壳固化进许可证是另一种把社区价值做成规则的手段。国际化的处理同样工程化tools/sync-locales.js以英文为基准其它语言缺失的 key 自动用英文占位贡献者只需要翻译自己负责的那一份文件。从韩语、俄语到越南语CHANGELOG 里长长的致谢名单就是社区驱动模式最好的证据。三条能带走的东西把平台限制当作需求文档来读。SW 回收、存储报错、Trusted Types 强制、iframe sandbox 阻断每一条限制背后都是一个真实的运行环境问题。猫抓的大部分聪明设计都是被限制逼出来的解而不是炫技——比如为了绕过 sandbox 阻断而重写 iframe 节点的处理逻辑这类补丁在代码里俯拾皆是。给数据分级而不是一刀切持久化。瞬时数据放高性能区可再生数据丢了就重抓只有配置这种丢不起的东西才值得放进持久存储。分清丢得起和丢不起能省掉一大半存储架构的复杂度。把社区治理也做成工程。许可证策略、i18n 同步脚本、拒绝抓取的 Opt-Out 清单——这些不是文档是代码是可以被版本管理和持续演进的资产。最后留一个开放问题Chrome 已经不止一次收紧 Service Worker 的存活策略假如某天心跳保活这类技巧被彻底堵死猫抓的监听架构该往哪里走嗅探这个行当大概永远在与平台的不许赛跑——而这恰恰是它最迷人的地方。【免费下载链接】cat-catch猫抓 浏览器资源嗅探扩展 / cat-catch Browser Resource Sniffing Extension项目地址: https://gitcode.com/GitHub_Trending/ca/cat-catch创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考