网络 on LiaoKe的个人博客

学习笔记 | 头歌破解考试的防复制粘贴

Thu, 23 Jul 2026 00:00:00 +0000

前言

有段时间被头歌的防复制粘贴搞得挺头痛的。网上能搜到的脚本，基本只能用于作业的防复制粘贴，到了考试就不行了。于是乎趁着一场模拟考试，研究了一下考试的防复制粘贴机制，最后成功写出来了用于考试的破解的油猴脚本(脚本的完整文件在博客末尾)。

作业场景：限制只在"配置层面"

作业页面的复制限制，本质上只是后端下发的一份"权限配置"，前端页面读到这份配置后，才决定要不要在界面上禁用复制粘贴、右键菜单这些功能。限制并不是靠浏览器事件层面的硬拦截实现的，而是看配置文件——配置说不能复制，页面才会去阻止你。

这种实现方式的好处是开发简单，但坏处也很明显：只要能在配置到达页面之前把它篡改掉，页面自然就会"以为"自己是被允许复制的，后面所有的限制逻辑都不会触发。

所以作业脚本的思路就非常直接：拦截页面发出的所有网络请求，找到返回题目/实训配置的那几个接口，把里面跟复制权限相关的字段统一改成"允许"，再把改过的响应交还给页面。整个过程页面完全无感，因为它拿到的还是一份合法的 JSON，只是内容被偷偷换了。

具体做法是重写全局的 fetch，在真正请求发出后、页面拿到响应前insert一层处理：

function hookFetch() {
    const nativeFetch = window.fetch;
    const hookedFetch = async (...args) => {
      const request = new Request(...args);
      const response = await nativeFetch(...args);
      const clonedResponse = response.clone();
      await saveTaskJson(request, clonedResponse);
      const modifiedResponse = await modifyTaskCopy(request, clonedResponse);
      return modifiedResponse;
    };
    window.fetch = hookedFetch;
}

把 shixun（实训）和 challenge（题目）对象里那些 forbid_copy、can_copy、diasble_copy之类的字段，全部改写成允许复制的状态：

if (json.shixun) {
  json.shixun.can_copy = true;
  json.shixun.forbid_copy = false;
  json.shixun.copy_for_exercise = true;
  json.shixun.active_copy = true;
  ...
}
if (json.challenge) {
  json.challenge.diasble_copy = false;
}

因为限制只存在于配置层面，所以我们只需要在配置被页面消费之前拦截并篡改它，就能解除限制，不需要碰任何浏览器原生的复制、粘贴、选中事件。

考试场景：事件层面的硬拦截

但是头歌的考试模式更为复杂。考试系统显然是在作业限制被人破解过太多次之后专门加固的，它不再只依赖一份后端配置——即便你把配置改成"允许复制"，考试页面依然会在浏览器事件层面把 copy、cut、paste、contextmenu 这些事件死死摁住。同时还配合了 CSS 的 user-select: none 让你连文字都选不中，甚至连 document.queryCommandSupported('paste') 这种底层探测接口的返回值也被动了手脚。也就是说，考试限制是"多层设防"的：配置层、CSS 选中层、DOM 事件层，缺一不可。

这就意味着单纯改配置字段是没有用的——页面的编辑器（Monaco Editor）内部有自己的一套事件监听逻辑，考试脚本会在事件冒泡的过程中调用 preventDefault、stopPropagation、stopImmediatePropagation，把复制粘贴事件在到达 Monaco 自己的处理逻辑之前就地"截杀"。所以要破解考试，思路必须从"改数据"转向"改浏览器事件系统本身的行为"：既然网站是靠调用这几个事件方法来实现拦截的，那就在这几个方法上做手脚，让"调用了但没有真正生效"。

具体做法是直接重写 Event.prototype 上的三个方法，对来自 Monaco 编辑器内部的复制/剪切/粘贴/右键事件做"选择性失效"：

Event.prototype.preventDefault = function () {
  const t = this.type;
  if ((t === "copy" || t === "cut") && insideMonaco(this.target)) {
    return; // 中和网站对 copy/cut 的阻止
  }
  return _origPreventDefault.call(this);
};

Event.prototype.stopPropagation = function () {
  const t = this.type;
  if ((t === "paste" || t === "contextmenu" || t === "copy" || t === "cut") && insideMonaco(this.target)) {
    return; // 放行，让事件能继续传播给 Monaco 的正常处理逻辑
  }
  return _origStopPropagation.call(this);
};

这里有个很细节但很关键的取舍：为什么 paste 和 contextmenu 的 preventDefault 要原样保留，只中和 copy/cut？因为 Monaco 的右键菜单是它自己用 JS 画出来的浮层，并不是浏览器原生右键菜单；如果把网站对 contextmenu 的 preventDefault 也中和掉，浏览器原生菜单和 Monaco 自己的菜单就会同时弹出来，造成"双重菜单"的问题。同理，paste 事件如果被完全放行，浏览器会执行一次"裸粘贴"，把内容直接怼进 textarea，绕过了 Monaco 自身的格式化粘贴逻辑，导致粘贴进去的代码缩进全部错乱。所以这两个事件只中和网站的 stopPropagation（让事件能传到 Monaco 手上），但保留网站对浏览器默认行为的 preventDefault（把决定权交还给 Monaco 自己）。

除此之外，脚本还补了两个容易被忽略的口子：一是给整个页面强制注入 CSS，把 Monaco 编辑器相关节点的 user-select 都改回 text，解决"事件放行了但文字根本选不中"的问题；二是遍历并监听页面里动态插入的 iframe，因为考试页面的编辑器很可能是内嵌在 iframe 里加载的，如果只处理主文档，iframe 内部的限制会完全不受影响：

function handleIframe(iframe) {
  try {
    const d = iframe.contentDocument || iframe.contentWindow.document;
    injectCSS(d);
    patchQCS(d.constructor.prototype);
  } catch (_) { /* 跨域 */ }
}

总结

作业和考试的防复制粘贴的实现思路完全不一样：

作业：限制信息完全来自后端下发的配置字段。破解只需要在数据到达页面前把配置篡改成"允许"，一次 fetch hook 就能解决所有问题。
考试：在配置层之上又叠了一层针对 DOM 事件的硬编码拦截（copy/cut/paste/contextmenu），外加 CSS 选中限制和 iframe 隔离。这时候光改数据没用，必须深入到浏览器事件系统本身，精确地区分"网站到底想阻止浏览器的默认行为，还是想阻止事件冒泡到别的处理器"，才能在解除限制的同时不破坏编辑器自身正常的复制粘贴功能。

最后完整的头歌考试破解防复制粘贴的油猴脚本如下（脚本仅用于技术交流，禁止用于任何非法途径）

// ==UserScript==
// @name         头歌平台 (EduCoder) 解除复制粘贴限制
// @namespace    https://github.com/example/educoder-unlocker
// @version      3.0.1
// @description  解除头歌平台代码编辑器的复制粘贴限制（修复右键双重菜单）
// @author       AI Assistant
// @match        https://www.educoder.net/*
// @run-at       document-start
// @grant        GM_log
// ==/UserScript==

(function () {
  "use strict";

  const TAG = "[EduCoder-Unlocker]";
  const log = (...a) => {
    try { GM_log(TAG + " " + a.join(" ")); } catch (_) { /* noop */ }
    console.log(TAG, ...a);
  };

  log("v3.0.1 启动");

  // ═══════════════════════════════════════════════════════════
  // Tools
  // ═══════════════════════════════════════════════════════════

  function insideMonaco(el) {
    if (!el || !el.closest) return false;
    return !!el.closest(".monaco-editor");
  }


  const _origPreventDefault = Event.prototype.preventDefault;
  const _origStopPropagation = Event.prototype.stopPropagation;
  const _origStopImmediate = Event.prototype.stopImmediatePropagation;

  Event.prototype.preventDefault = function () {
    const t = this.type;
    if ((t === "copy" || t === "cut") && insideMonaco(this.target)) {
      return;
    }
    return _origPreventDefault.call(this);
  };

  Event.prototype.stopPropagation = function () {
    const t = this.type;
    if ((t === "paste" || t === "contextmenu" || t === "copy" || t === "cut") && insideMonaco(this.target)) {
      return;
    }
    return _origStopPropagation.call(this);
  };

  Event.prototype.stopImmediatePropagation = function () {
    const t = this.type;
    if ((t === "paste" || t === "contextmenu" || t === "copy" || t === "cut") && insideMonaco(this.target)) {
      return; 
    }
    return _origStopImmediate.call(this);
  };

  log("✓ 三件套补丁已生效");
  log("  preventDefault:   copy/cut → 中和  |  paste/contextmenu → 保留原始");
  log("  stopPropagation:  全部中和");
  log("  stopImmediate:    全部中和");

  // ═══════════════════════════════════════════════════════════
  // paste 兜底
  // ═══════════════════════════════════════════════════════════

  document.addEventListener("paste", function (e) {
    if (!insideMonaco(e.target)) return;
  
    e.preventDefault();
  }, true);

  log("✓ paste 兜底拦截器已注册");

  // ═══════════════════════════════════════════════════════════
  // CSS
  // ═══════════════════════════════════════════════════════════

  const UNLOCK_CSS = `
    /* [EduCoder-Unlocker] 恢复 Monaco 编辑器文本选择 */
    .monaco-editor,
    .monaco-editor .monaco-scrollable-element,
    .monaco-editor .view-lines,
    .monaco-editor .view-lines .view-line,
    .monaco-editor .view-lines *,
    .monaco-editor .lines-content,
    .monaco-editor .view-overlays,
    .monaco-editor .view-overlays .current-line,
    .monaco-editor .margin-view-overlays,
    .monaco-editor .line-numbers,
    .monaco-editor .margin .line-numbers {
      -webkit-user-select: text !important;
      -moz-user-select: text !important;
      -ms-user-select: text !important;
      user-select: text !important;
    }
  `;

  function injectCSS(doc) {
    if (!doc || !doc.head) return;
    if (doc.getElementById("educoder-unlocker-css")) return;
    const s = doc.createElement("style");
    s.id = "educoder-unlocker-css";
    s.textContent = UNLOCK_CSS;
    doc.head.appendChild(s);
    log("✓ CSS 注入: " + (doc === document ? "主文档" : "iframe"));
  }

  // ═══════════════════════════════════════════════════════════
  // queryCommandSupported
  // ═══════════════════════════════════════════════════════════

  function patchQCS(docProto) {
    if (docProto.__unlocker_qcs) return;
    const orig = docProto.queryCommandSupported;
    docProto.queryCommandSupported = function (cmd) {
      if (cmd === "paste") return true;
      return orig.call(this, cmd);
    };
    docProto.__unlocker_qcs = true;
  }

  patchQCS(Document.prototype);

  // ═══════════════════════════════════════════════════════════
  // iframe 支持
  // ═══════════════════════════════════════════════════════════

  function handleIframe(iframe) {
    try {
      const d = iframe.contentDocument || iframe.contentWindow.document;
      if (!d) return;

      function doInject() {
        if (!(d.readyState === "complete" || d.readyState === "interactive")) {
          setTimeout(doInject, 50);
          return;
        }
        injectCSS(d);
        patchQCS(d.constructor.prototype);
      }

      doInject();
    } catch (_) { /* 跨域 */ }
  }

  function scanIframes() {
    document.querySelectorAll("iframe").forEach(handleIframe);
  }

  const mo = new MutationObserver(function (mutations) {
    for (const m of mutations) {
      for (const n of m.addedNodes) {
        if (n.tagName === "IFRAME") handleIframe(n);
        if (n.querySelectorAll) n.querySelectorAll("iframe").forEach(handleIframe);
      }
    }
  });

  function onDOMReady() {
    scanIframes();
    mo.observe(document.documentElement, { childList: true, subtree: true });
  }

  if (document.readyState === "loading") {
    document.addEventListener("DOMContentLoaded", onDOMReady);
  } else {
    onDOMReady();
  }

  injectCSS(document);

  log("✓ v3.0.1 就绪 — 文本选择 | 复制 | 粘贴(格式正确) | 剪切 | 右键菜单(仅 Monoco)");
})();

学习笔记 | 一次网页端逆向到 OpenAI 接口封装的完整过程

Tue, 21 Jul 2026 00:00:00 +0000

前言

最近看到 Orchids 给了免费的 Claude 和 GPT 额度，但它只提供网页端，没有开放后端 API。
我就做了一个小实验：不去改它服务端，只复用网页端已有调用链路，把能力封装成一个 OpenAI API 兼容网关，方便接入各类客户端和工具链。

这个方案可以跑通，支持流式、思考模式和文件上传，但并不适合做高并发号池，额度和速率都受原平台会话机制限制。本文主要是技术复盘与工程总结。

一、协议适配

这次的目标很明确：

复用网页端已有会话与鉴权流程
把上游 SSE 数据流转换成标准 OpenAI 返回结构
对外暴露常见 OpenAI 接口，做到低改造接入

最终本地服务提供了这些路由：

GET /health
GET /v1/models
POST /v1/chat/completions
POST /v1/responses
POST /v1/files
GET /v1/files
GET /v1/files/{file_id}
GET /v1/files/{file_id}/content
GET /v1/files/{file_id}/url
DELETE /v1/files/{file_id}

二、链路分析：从网页请求里抽象最小参数集

在网页端实际请求里，可以定位到这几个关键参数：

clerk_active_context
projectId
userId
__client

其中：

projectId 来自对话创建后的项目上下文
clerk_active_context 与 __client 用于会话鉴权
userId 用于拼接上游请求体

这四个参数就是整个中转服务的最小可用配置。程序启动时交互输入，避免硬编码到源码里。

三、程序架构

1) 配置与服务启动

服务启动后读取配置并初始化两个 HTTP Client：

jwtClient：用于向 Clerk 换取 JWT
upstreamClient：用于请求 Orchids 的 stream-run SSE 接口

同时挂载 OpenAI 风格路由，作为统一入口。

2) 鉴权流程

核心流程是：

调用 Clerk token 接口（带 __client Cookie）
获取临时 JWT
用 JWT 访问上游推理 SSE

也就是说，本地网关没有伪造新鉴权体系，而是复用了网页端已有会话链路。

3) 上游请求与容错

上游请求采用以下策略：

Authorization: Bearer <jwt>
Accept: text/event-stream
网络可重试错误自动重试一次
失败时返回清晰错误（包含状态码与上游响应）

这块是工程稳定性的关键，不然很容易因为临时网络抖动导致误判不可用。

四、协议转换：把 Orchids SSE 映射成 OpenAI 语义

上游事件流里主要有三类信息：

文本增量（text_delta）
思考增量（thinking_delta）
最终结果与 usage

程序分两套解析逻辑：

parseOrchidsSSEForFinalResult：非流式聚合
parseOrchidsSSEStream：流式逐段回传

再映射为：

Chat Completions：chat.completion / chat.completion.chunk
Responses API：response.output_text.delta / response.completed

并且 reasoning 开关打开时，会把 thinking 内容透传到对应字段，保证“思考模式”可用。

五、文件能力：兼容 OpenAI Files 接口

除了聊天接口，程序还实现了文件链路：

POST /v1/files 接收 multipart 文件上传
本地落盘并生成 file-xxxx 形式的 file_id
在消息输入中提取 input_file 的 file_id
映射为上游可访问的 attachmentUrls

这意味着可以兼容部分依赖 Files API 的客户端工作流，而不只是纯文本对话。

六、支持模型

当前版本内置模型列表如下：

claude-sonnet-4-6
gpt-5.4
gpt-5.3-codex
claude-opus-4.6
claude-opus-4.5
gpt-5.2-codex
gpt-5.2
gemini-3-flash
gemini-3-pro
gemini-3.1-pro

可通过 GET /v1/models 查询。

七、实际体验与边界

这个方案的优点：

对接现有 OpenAI 生态方便
协议统一后可被多数工具直接消费
流式和 reasoning 都可跑通

但边界也很明显：

依赖网页会话参数，稳定性受平台变更影响
额度和速度都不适合当号池
上游接口一旦改字段，网关要同步维护

所以它更适合作为逆向与协议适配实践，而不是生产级高可用方案。

总结

其实本质上是：
把“网页端调用流程”重构成“标准 API 服务”。

从工程角度看，真正有价值的是：

能否抽象出最小参数集
能否稳定解析 SSE 并保持语义一致
能否用统一接口服务不同客户端

如果只是临时脚本，那是一次调用；
完成了协议映射、错误模型和流式对齐，才算一个可复用的接口封装方案。

程序下载链接：
https://www.123865.com/s/vxarVv-o7yHH

仅用于学习逆向、协议理解和网关设计；
如果想直接拿来做业务化池子，建议降低预期。

学习笔记 | 最简单的绕过校园网多设备热点检测方案

Mon, 09 Mar 2026 00:00:00 +0000

前言

弄到了一个白嫖的校园网账号,但是触发设备连接上限了(电脑只要开热点，wifi就无法访问互联网),我手机电脑无法同时连接,于是便有了接下来这篇教程

原因解析

当电脑连接WIFI的时候,网络适配器中的wlan网卡便是已连接的状态
此时我们打开热点,在网络适配器中会自动创建一个新的本地连接的网卡
在默认情况下,热点的网卡会自动寻找可以访问互联网的网卡，作为上级网卡.
但是由于校园网有检测,当热点网卡的流量转发到wlan时,校园网就会检测到有多个设备，从而断开访问

解决方法

通过手动设置热点网卡的上级网卡到其他的网卡,然后其他网卡的流量(经过这个网卡，对流量进行处理)再流入wlan,这样便不会被校园网检测.
于是我们便要用到clash/singbox这样的代理工具的tun模式创造另外一个网卡(其实也可以用wintun驱动手动创建,不过得手动配置一些东西，比较麻烦)
不一定需要添加clash的代理配置文件,只要打开tun模式即可.
此时网络适配器中将会多出一张其他的网络设备
此时右击该网卡属性点击共享，然后设置共享的网络为本地连接(相当手动指定热点的上级网络),便可以实现绕过校园网检测

方案分析 | 代理工具的选择

Wed, 03 Dec 2025 00:00:00 +0000

主流代理核心简介（代理核心 + 前端 UI）

所有代理工具本质上都是 代理核心 + 前端图形界面（UI） 组成。
前端 UI 可以千变万化，但真正承担流量处理的 代理核心只有少数几种。

以下是目前主流、最常见的核心介绍。

Clash(更新停滞)

Clash 是一个最初由 Go 编写的多协议代理核心（原项目已删除）。
使用广泛，生态庞大。

特点：

使用统一的 YAML 配置，无需因平台不同而修改
GUI 客户端数量最多、生态最大
跨平台兼容性极强

缺点：

原项目已停止维护
新协议支持较慢（如 Reality、Hysteria2 等）

Mihomo（Clash Meta）★★★

MetaCubeX 社区维护的 Clash 增强版，也是目前最主流的 Clash 继承者。

特点：

完全兼容 Clash 配置
支持现代协议（Reality、Hysteria2、TUIC 等）
活跃维护，性能更高

Sing-Box（sb）★★

由 SagerNet 开发的现代化代理核心，目前增长最快、架构最先进。

特点：

极度轻量，理论性能高
高度可定制的网络与路由配置
支持大量现代协议
跨平台优秀

缺点：

配置难度高，对新手不友好
GUI 生态较少

V2Ray(更新缓慢)

由 v2fly 社区维护的原始 V2Ray 核心。

特点：

配置灵活
结构成熟
较为轻量

缺点：

开发速度慢
新协议支持不佳
配置复杂
GUI 生态弱

Xray

V2Ray 的增强版核心，由 XTLS 项目维护。

特点：

完全兼容 V2Ray 配置
支持 Reality
支持 XTLS，性能大幅提升
性能明显高于官方 V2Ray

缺点：

配置复杂
GUI 生态较弱

dae

基于 eBPF 的 Linux / 路由器高性能代理引擎，更像“下一代分流框架”。

特点：

基于 eBPF，性能极高
几乎不占 CPU
延迟极低
路由分流能力极强

缺点：

仅支持 Linux / OpenWRT
配置复杂
GUI少

各操作系统主流GUI代理客户端(整体按照知名度排序)

Windows

v2rayN★★ — 支持 Xray / sing-box / clash/others 内核,支持Windows/Linux/macOS
Clash Verge Rev★★ — 内置 Mihomo内核,支持 Linux/macOS/Windows
Mihomo Party★★★(推荐) - 支持linux/windows/macos
Karing — 基于 sing-box 内核,支持Android/ios/linux/windows/macos
Sparkle★★ — 基于 Mihomo 内核，支持 Windows / macOS / Linux
Clash Mi —支持android/ios/Windows / macOS / Linux
FlClash — 基于 Mihomo 内核,支持Android/linux/windows、macos
GUI.for.Clash — Windows / macOS / Linux
Pandora-Box — 基于 Mihomo 内核,支持linux/windows/macos

macOS

Surge★★★ — 付费高级客户端,支持ios/macos
Quantumult X★★★ — 付费,支持ios/macos
Loon — 付费,支持ios/macos
v2rayN — 支持 Xray / sing-box / clash/others 内核,支持Windows/Linux/macOS
Clash Verge Rev — 内置 Mihomo 内核,支持 Linux/macOS/Windows
Mihomo Party - 支持linux/windows/macos
Karing — 基于 sing-box 内核,支持Android/ios/linux/windows/macos
Sparkle — 基于 Mihomo 内核，支持 Windows / macOS / Linux
FlClash — 基于 Mihomo 内核,支持Android/linux/windows、macos
Clash Mi —支持android/ios/Windows / macOS / Linux
GUI.for.Clash — Windows / macOS / Linux
Stash★★ — 基于 sing-box（付费）
Pandora-Box — 基于 Mihomo 内核,支持linux/windows/macos

Linux

v2rayN★★ — 支持 Xray / sing-box / clash/others 内核,支持Windows/Linux/macOS
Clash Verge Rev★★ — 内置 Mihomo 内核,支持 Linux/macOS/Windows
Mihomo Party★★★ - 支持linux/windows/macos
Karing — 基于 sing-box 内核,支持Android/ios/linux/windows/macos
Sparkle — 基于 Mihomo 内核，支持 Windows / macOS / Linux
FlClash — 基于 Mihomo 内核,支持Android/linux/windows、macos
Clash Mi —支持android/ios/Windows / macOS / Linux
GUI.for.Clash — 支持 Linux/macOS/Windows
Pandora-Box — 基于 Mihomo 内核,支持linux/windows/macos

Android

Clash Meta for Android★★★(推荐)
Karing — 基于 sing-box 内核,支持Android/ios/linux/windows/macos
Clash Mi —支持android/ios/Windows / macOS / Linux
FlClash★★ — 基于 Mihomo 内核,支持Android/linux/windows、macos

iOS

Surge★★★ — 付费高级客户端,支持ios/macos
Shadowrocket★★★ — 付费,支持多协议
Quantumult X★★★ — 付费,支持ios/macos
Loon — 付费,支持ios/macos
Karing — 基于 sing-box 内核,支持Android/ios/linux/windows/macos
Clash Mi —支持android/ios/Windows / macOS / Linux

HarmonyOS NEXT

ClashBox — 独苗这一块

路由器（OpenWRT / Linux）

OpenClash★★ - OpenWRT 上主流的 Clash 客户端
OpenWrt-nikki★★★(推荐) — 基于clash核心
daed — 基于dae内核
Passwall2
openwrt-nekobox — 基于 Sing-box核心

总结

小白无脑选择clash系客户端，有其他要求可自定义选择。