学习笔记 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模式即可.
此时网络适配器中将会多出一张其他的网络设备
此时右击该网卡属性点击共享，然后设置共享的网络为本地连接(相当手动指定热点的上级网络),便可以实现绕过校园网检测

学习笔记 | openwrt25.10设置vlan实现单线复用

Wed, 25 Feb 2026 00:00:00 +0000

原理解析

(特别注意:有一些路由器的系统是不支持设置vlanid的,所以建议所有路由器都为openwrt软路由，方便操作.)

在传统方案中,当光猫设置桥接模式,软路由负责拨号,此时光猫的其他网口在正常情况下是无法工作的,因为光猫此时只做光电转换，不做路由ip下发.

此时我们便需要用到一项技术实现光猫在桥接模式下光猫的其他网口也能正常工作.这便是vlanid.vlanid并不只有单线复用这一个功能,它也可以用来划分局域网,从本质上来讲，它的作用就是给流量打上标记.

当光猫桥接主路由拨号时,其他房间网口的流量是流向光猫的网口,在流量没有打vlanid标识的情况下，光猫也不知道要把这些流量弄到哪里去,所以光猫其他网口便无法正常通讯.

所以这个时候我们便用vlanid来实现单线复用(即一条网线，负责实现两个功能,也就是说我们主路由与光猫连接的那根网线既负责主路由的拨号，又负责主路由dhcp服务器下发ip到光猫的其他网口),我们在其他网口的房间里的路由器里面设置vlanid,然后在光猫的管理员后台里也设置的vlanid,最后在主路由里面设置一样的vlanid.就这样在三台设备中都设置了vlanid,设备就知道这些流量该如何传输.

具体操作

在房间的子路由中把wan接口删除,只留lan口,然后在设备中添加连接网线的网口的vlan设备,然后把这个设备添加到br-lan的网桥设备集合之中
在光猫的管理员后台(不同的型号的光猫进入管理员后台的方法不同，有一些甚至进不去管理员后台，这里就不细讲了),把对应连接方式的lan口绑定全部取消,然后设置对应网口的vlanid和vlan绑定 以上这张图中，网络连接二是用于主路由和光猫拨号的，而网络连接五则是用于设置vlanid来实现单线复用的。
在主路由进行和子路由中一样的操作,只是这一次不用把wan口删除了,把wan口对应的连接端口设置vlanid,然后也一并添加到br-lan中即可完成配置

完成了以上三个步骤,就可以实现光猫在桥接模式下，房间的子路由仍然可以接收到主路由下发的ip了

学习笔记 | Hugo自动修正文章最后修改时间的最佳方案

Sun, 25 Jan 2026 00:00:00 +0000

Hugo 全自动修正文章修改时间的最佳实践（Serverless 场景）

在使用 Hugo 构建静态博客时，文章的修改时间（Last Modified Time） 是一个非常重要但又容易踩坑的问题，尤其是在 Serverless / CI 自动部署 场景下。

Hugo 官方目前提供了多种用于确定文章修改时间的方式：

Hugo 支持的修改时间来源

:filemodtime
使用文件本身的最后修改时间作为文章的修改时间。
lastmod
需要在文章 Front Matter 中手动维护 lastmod 字段。
:git
使用 Git 中该文件的最后一次提交时间作为修改时间（依赖 gitinfo）。
date
使用文章的发布时间作为修改时间。

各方案的自动化可行性分析

在上述方案中：

✅ 可自动化
- :filemodtime
- :git
❌ 不适合全自动
- lastmod（需要人工维护）
- date（语义不符）

:filemodtime 在 Serverless 场景下的问题

使用 Hugo 的一个重要原因，正是为了 方便地将网站部署到 Serverless 平台（如 Cloudflare Pages、Vercel、Netlify 等）。

然而在 Serverless / CI 场景中：

每次部署都会重新 git clone 仓库
所有文件的 文件系统修改时间 都会变成「拉取时间」
这会导致：
- 所有文章的修改时间被错误地更新为“本次部署时间”
- 完全失去文章真实修改时间的意义

因此，:filemodtime 在默认情况下并不适合 Serverless 场景。

:git 方案的现实问题

理论上，:git 是最理想的方案：

修改时间与 Git 提交严格一致
完全自动化
不依赖文件系统时间戳

但在实际使用中：

即使开启了 enableGitInfo = true
某些情况下 :git 无法正确生效
在 CI / Serverless 环境中尤为明显

不确定这是环境限制、Git shallow clone、还是 Hugo 本身的 Bug，但结果是：该方案在实践中不够稳定。

最终解决方案：修改文件时间戳为Git 提交时间 + :filemodtime

综合以上问题，我最终总结出了一套最适合 Serverless 管理的全自动方案：

核心思路

在 Hugo 构建之前，将文件的修改时间戳“伪装”为 Git 最后提交时间。

具体流程如下：

Hugo 中使用 :filemodtime 作为文章修改时间来源

1
2

[frontmatter]
lastmod = [':fileModTime']

将脚本放在文件夹根目录
将自动执行脚本的命令和正式部署命令合二为一(这里需要注意的是一般的serverless平台拉取项目只是浅层克隆不会把文件的最后提交信息给拉取过来，所以我们要在最前面要执行完整的拉取命令。)

`1`	`git fetch --unshallow && chmod +x 1.sh && ./1.sh && hugo`

Serverless平台设置环境变量TZ为Asia/Shanghai(不然的话，一般Serverless平台默认应该是美国的时间,会影响构建出来的网站的文章的最后修改日期的准确性)

这样就可以做到：

✅ 修改时间与 Git 提交时间一致
✅ 完全自动化
✅ 与 Serverless / CI 环境完美兼容

自动同步 Git 提交时间到文件修改时间的脚本

下面的脚本用于：

将当前目录下所有文件的最后修改时间，统一修改为对应的 Git 最后提交时间

# （此处放置你的脚本内容）
#!/bin/bash
# git-set-filetime.sh
# 功能：将 git 仓库中所有被追踪文件的修改时间改为最后一次提交时间

# 确保当前目录是 git 仓库
if [ ! -d ".git" ]; then
    echo "Error: 当前目录不是 git 仓库根目录"
    exit 1
fi

# 获取所有被追踪文件（包含特殊字符/空格/中文）
git ls-files -z | while IFS= read -r -d '' file; do
    # 获取最后一次提交的 Unix 时间戳
    timestamp=$(git log -1 --format="%ct" -- "$file")
    
    if [ -n "$timestamp" ]; then
        # 使用 touch 修改文件修改时间
        # -d "@$timestamp" 表示从 Unix 时间戳设置时间
        touch -d "@$timestamp" "$file"
        echo "Updated: $file -> $(date -d "@$timestamp" '+%Y-%m-%d %H:%M:%S')"
    else
        echo "Skipped (not tracked): $file"
    fi
done

echo "All tracked files' modification times updated."

学习笔记 | GKI 内核不完全编译实战

Fri, 05 Dec 2025 00:00:00 +0000

Android内核编译

以编译5.10以上的内核为例,所需资源:

一台配置较好的电脑
linux系统
内核源代码
编译链工具

linux系统

各大Linux系统(Ubuntu系/arch系/fedora系/Wsl2)都可以，网上教程多以Ubuntu lts版本为例(便于找依赖和教程)

内核源代码

从github上搜索自己机型的内核源代码
如https://github.com/Evolution-X-Devices/kernel_xiaomi_sm8450(项目名一般采用 kernel_厂家名_芯片组代号的形式,5.10之后都是gki内核,所以内核名称基本是以芯片组命名如sm8450,有些项目也可能是按机型代号命名，而不是芯片组)

编译链工具

5.10以上的内核一般采用纯clang/llvm进行编译(低版本内核也可尝试，但有可能能成功编译但会开不了机)

Clang/llvm

Clang 一般情况下采用的是google的正式分支,也可以采用测试分支

编译过程

更新环境依赖

以Ubuntu24.04为例,执行以下命令安装依赖

sudo apt-get install git-core gnupg flex bison build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 libncurses5 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z1-dev libgl1-mesa-dev libxml2-utils xsltproc tar xz-utils cpio findutils

克隆内核源代码和编译链工具

内核:git clone https://github.com/Evolution-X-Devices/kernel_xiaomi_sm8450.git --depth=1
编译链工具:git clone https://android.googlesource.com/platform/prebuilts/clang/host/linux-x86.git --depth=1
depth=1只拉取文件，不拉取历史提交，可以极大减少下载时间
如果想拉取其他的测试分支，也可以在后面加-b 测试分支名字
如拉取测试版的编译链则添加-b mirror-goog-main-prebuilts

设置环境变量

注:以下操作需要在同一个终端环境下执行，因为添加的变量是临时变量
此时在你的工作目录下面应该会有两个文件夹，一是内核文件夹，二是编译链工具文件夹
打开终端,执行cd 编译链工具文件夹路径,当前目录下应该会有若干个clang-rxxxx子文件夹，选择后缀数字最大的最新版本即可,将它下面的/bin添加到环境变量中

`1`	`export PATH="$PATH:/../../编译链工具文件夹/clang-rxxxx/bin"`

然后再cd 内核源代码文件夹
设置编译环境变量

export ARCH="arm64"
export SUBARCH="arm64"
export CC="clang"
export LLVM=1
export LLVM_IAS=1
export HOSTCC=clang
export LD=ld.lld
export CLANG_TRIPLE="aarch64-linux-gnu-"

如果电脑的内存不太够，可以额外设置

`1`	`export LTO=thin`

执行编译命令

1
2

make ARCH="arm64" gki_defconfig
make -j$(nproc --all)

第一行命令是加载配置文件gki_defconfig,他所在的目录是/内核源代码/arch/arm64/configs/gki_defconfig（可以自行修改里面的配置项）
编译出来的内核二进制文件会在/内核源代码/arch/arm64/boot/Image

打包内核

由于没有编译kernel-devicetree,也没ramdisk,所以无法和内核二进制文件打包成boot.img刷入手机分区(也可以用magiskboot把手机原本的boot.img进行解包，把其中的内核二进制文件替换之后,再打包就行了)
这个时候就需要AnyKernel3对内核二进制文件进行打包
详细教程参考
https://github.com/tiann/KernelSU/discussions/952

刷入内核

可以在twrp或一些用于刷写内核的app中刷入打包后的AnyKernel3.zip

注意

不同型号内核以及不同版本的编译器，可能对依赖和代码语法要求也有所不同，需要自行解决。

学习笔记 | Steam 假入库那些事

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

Steam假入库到底是什么？

淘宝上有很多低价的steam游戏cdk,但购买之后实际是运行脚本入库(有自己steam账号信息泄露的风险),可以在本地游玩.（换台设备重新登录账号，假入库游戏将会被清空。）

实际上账号并没有拥有游戏,别人是看不到你的账号拥有该游戏的

假入库原理分析:

Steam购买游戏相当于购买游戏的游玩资格，购买完成后，将会下载游戏的清单文件(相当于下载列表),然后steam会用游戏的depot key(正版购买用户自动下发)对清单文件进行解密下载,下载完成后，打开游戏会调用steamwork api进行验证当前运行的steam账号是否拥有该游戏,认证通过后即可正常游玩。

我们可以在其中做些手脚,便可以实现假入库。

游戏清单文件是可以公开找到的，但是需要正版账号的depot key解密才可以解密下载(游戏每一个版本的清单文件对应着一个depot key,所以想要玩到最新的游戏内容，密钥文件也需要及时更新)。假入库的商家可能会根据爬虫或者其他技术手段(如通过木马病毒从其他steam玩家账号中提取depot key)，可以搞到最新的游戏depot key
通过解密清单将游戏完整下下来后,通过steamtool/GreenLuma hook注入自己的.dll文件,对steam原有的steamwork api进行劫持,便可以实现让游戏认为账号已经获取了该游戏的游玩权限。

于是乎通过以上手段，便实现了一套完整的steam游戏假入库

在steam游戏破解游玩方面,主要有两种破解方法

一是对steam客户端进行crak

让steam认为你拥有该游戏的游玩权限,再搭配实时获取别人最新的depot key,便可实现几乎与正版购买一致的游戏体验(云存档,成就系统等等)

弊端:

无法使用联机功能
别人看不到你库中的游戏(无伤大雅,除非你想要通过玩游戏来证明自己的老资历,在某盒软件舆论战中占上风)
系统重装后，steam假入库游戏入库数据会消失(要玩的时候重新入一下库就行了，问题不大)

典型代表:

steamtool (闭源，国人大佬开发,功能强大)
GreenLuma(原版纯命令行,操作较难,闭源,外国论坛发布)
GreenLuma_CN(原版加上前端，方便操作)

二是对游戏文件本身进行修改

对游戏文件夹本身进行修改,内置一个模仿steam api行为的第三方轻量steam client,实现steam游戏脱离steam官方客户端运行,方便游戏在互联网上传播

弊端:

不方便游戏新版本的更新和获取
无法使用steam官方客户端的一些功能

典型代表:

其他:

steamlan/gbe 通过模仿steam lan api,可以实现游戏在线/离线模式下局域网联机,而不需要走steam官方服务器
steamless 移除steam端的d加密(不会绕过游戏游玩验证,并且非steam的d加密无法破解，比如说黑猴,需要使用别人的d加密密钥才可以认证游玩)

总结:

Steam假入库商家通常通过劫持steam根目录的hid.dll文件进行自定义操作,hook核心一般采用steamtool,加上不知道哪里搞来的清单depot key源,由于是黑箱代码,无法准确判断是否含有其他的木马病毒,来获取自己steam的一些信息,对账号造成隐性风险,所以不建议使用淘宝上的 steam假入库。

辨别方法:

由于steam假入库这件事已经有一定的知名度了,有些商家也学聪明了，把正版的激活流程放在介绍页，然后下面配一行小字，如果正版激活不行(100%是不成功的)，再采用其他方法(他们自己的脚本).

主要由以下两个方法判断:

cdk价格过低的，100%都是假入库
直接询问客服是否可以在手机上通过steam客户端cdk激活（假入库的脚本程序无法在手机上运行）

解除假入库

使用steam解锁文件管理器删除假入库的游戏
~~然后删除steam根目录的hid.dll~~(steam更新64位后,hid.dll劫持的方案已经失效了,换别的方案了)

最后严肃声明，本文章仅供技术探讨，支持正版从我做起