深入解析 Orion：Discord 任务自动化原理及 Webpack 内部机制探索

Discord 长期以来一直试图将客户端打造成不仅仅是一个即时通讯工具。前不久，任务系统上线了。看直播、玩半小时游戏，或者浏览宣传视频，就能获得头像框、Orbs 或个人资料装饰作为奖励。

在一个毫无兴趣的游戏上浪费时间充其量是值得商榷的。很自然地，社区立刻涌现出各种方法来"玩转"客户端。开发者 nyxxbit 的 Orion 项目可能是从浏览器控制台直接逆向工程 Discord Webpack 内部机制最详尽的案例之一。

Orion 内部工作原理

Orion 有两种形式：DevTools 控制台脚本和 Vencord 插件。它模拟游戏状态、视频观看和语音频道活动。而且整个过程无需安装笨重的 Node.js 环境或外部模拟器。

最有趣的部分隐藏在技术实现中。通常，这类脚本会在每次 Discord 更新后失效。客户端开发者会对构建产物进行混淆，函数名会变成毫无意义的 .A、.zP 或 _y，导致硬编码的路径在第二天就无法工作。

Orion 的作者采用了不同的方法。脚本通过构造函数名称搜索内部状态管理器（QuestStore、RunStore、StreamStore）——即 constructor.displayName。为了找到 Dispatcher，需要检查对象结构：是否存在订阅以及 dispatch 方法。这种方法在大多数小版本客户端更新中都能存活而不会损坏。

五种任务类型及其欺骗方式

Discord 目前有五种任务类型。Orion 对每种类型都有各自对应的处理逻辑：

• 视频任务。脚本以 7-9 秒的伪随机间隔发送时间戳 video-progress，并带有小数秒值。这精确模拟了标准 Chromium 播放器的行为。
• 游戏任务。Orion 不启动真正的游戏，而是向 RunStore 注入一个伪造的进程，从 Discord 注册表中获取真实的应用程序 ID。
• 直播。脚本修补 StreamStore.getStreamerActiveStreamMetadata，向客户端提供伪造的广播元数据。
• 活动。心跳被发送到语音频道以模拟参与。
• 活动成就（ACHIEVEMENT_IN_ACTIVITY）。以前只需发送简单的心跳就够了，但 Discord 封闭了这个漏洞。现在脚本请求应用程序的 OAuth2 令牌，生成代理票据，向服务器发送伪造的进度 discordsays.com，然后立即撤销授予的权限。

绕过浏览器保护和本地中继

对于活动任务，开发者遇到了一个硬性限制。Discord 客户端中的内容安全策略（CSP）禁止从渲染进程向 fetch 等第三方域名发送直接的 14 请求。

为了在控制台版本中绕过这个限制，Orion Relay 被添加到了仓库中。这是一个用 PowerShell 编写的微型本地 HTTP 服务器，代码仅有 100 行。浏览器允许连接到 127.0.0.1:* 以与游戏悬浮窗交互，所以用户脚本将请求发送到本地代理，再由代理转发到 Discord 的服务。如果你使用的是 Vencord，插件的原生模块会直接从 Electron 主进程发起请求，那里 CSP 并不适用。

有一个真正的风险需要考虑：Discord 积极监控任务自动化行为，并标记异常的发进度模式。虽然以前最坏的后果只是不收到头像框或皮肤，但现在系统会发出账户级别的警告。Orion 的作者在 README 开头就明确警告了这一点：获取奖励的速度伴随着被封号的非零风险。

与其他方案的对比

Orion 的方法并非 GitHub 上唯一的方案。例如，项目 markterence/discord-quest-completer 选择了用 Rust 和 Tauri 开发原生应用程序的路线。它不在 Discord 的内存中注入，而是通过在操作系统中创建伪造的可执行文件来欺骗 Windows 的进程检测系统。

这种方法完全不触及客户端的文件或内存，从结构上更能抵抗封号。但它有缺点：它只适用于普通的游戏任务，忽略视频和活动任务，而且仅支持 Windows。

界面和易用性

Orion 有一个纯 JS 构建的内置悬浮窗，使用 Discord 自身的原生 CSS 变量布局。正因如此，它能适配任何主题（浅色、深色、AMOLED）。

你可以按奖励类型筛选任务，禁用自动领取（避免触发验证码），或配置循环之间延迟的随机化以防止被检测。

值得一试吗

研究 Orion 至少值得一看，因为它展示了如何在一个普通用户脚本中优雅地处理 Webpack 和 Electron 内部机制。这是逆向工程客户端 Web 应用和编写抗更新代码的绝佳范例。

在主账户上运行它完全由你自己承担风险。如果你决定尝试，最好用一个废弃账户来做实验。