《道德经》第二十三章 【原文】希言自然。故飘风不终朝，骤雨不终日。孰为此者？天地。天地尚不能久，而况于人乎？故从事于道者同于道；德者同于德；失者同于失。同于道者，道亦乐得之；同于德者，德亦乐得之；同于失者，失亦乐得之。信不足焉，有不信焉！【译文】不言政令、不扰民是合乎于自然的。所以狂风刮不了一整个早晨，暴雨也下不了一整天。谁造成的呢？是天地。天地（的狂暴）尚且不能持久，何况是人呢？因此，求道的人，言行就合于道；求德的人，言行就合于德；失道失德的人，行为就会背离道与德。（行为）合于道的人，道也乐于成全他；合于德的人，德也乐于成全他；而背离道与德的人，也会得到背离的结果。（统治者的）诚信不足，才会有人不信任他。道家讲“清静无为”，主张的并非消极避世，而是不妄为、不强为。即便是天地掀起的暴风骤雨，其势虽猛，却也无法长久。同理，那些来势汹汹的谣言与纷扰，其生命力也终究有限。

码制 为什么需要码制？计算机只认识0和1，但我们需要表示正数和负数。码制就是用来解决"如何在计算机中表示有符号数"的问题。三种码制的通俗理解1.原码 - "最直接的想法"就像我们日常写数字一样直接：最高位表示符号：0=正数，1=负数其余位表示数值的绝对值例子（8位二进制）：+5 的原码：00000101-5 的原码：10000101问题：计算时很麻烦！ 00000001 (+1)10000001 (-1)= 10000010 (-2) ❌ 结果错误！2.反码 - "第一次改进"负数的反码 = 原码的数值位取反（符号位不变）例子：+5 的反码：00000101（与原码相同）-5 的反码：11111010（原码10000101取反）改进：计算比之前好一点，但仍有问题00000001 (+1的反码)11111110 (-1的反码)= 11111111 (-0的反码) ❌ 出现了"-0"！补码 - "最终解决方案" ⭐负数的补码 = 反码 + 1例子：+5 的补码：00000101（与原码相同）-5 的补码：11111011（反码11111010 + 1）神奇之处： 00000001 (+1的补码)11111111 (-1的补码)= 00000000 (0的补码) ✅ 结果正确！补码的核心优势：统一了0的表示：没有+0和-0的问题简化了运算：加减法都可以用加法器完成增加了表示范围：能多表示一个负数（-128）为什么程序员要理解这些？理解整数溢出问题调试底层程序时查看内存数据理解位运算操作面试常考题现代计算机：所有整数运算都使用补码浮点数使用IEEE 754标准字符使用Unicode编码

逆向记录 完整逻辑演进：两周走了哪些路，为什么走到今天阶段一：代理抓包 + 协议分析（7/6）我们当时怎么想的："先别碰客户端，让数据自己说话。搭个中间人代理，看看客户端和服务器到底在聊什么。"做了什么：公网服务器搭 TCP 代理（:13000 → 150.158.48.18:13000）+ HTTP 更新服（:8888）轻量版代理抓了 602 个包，31KB验证了握手结构：7B → 25B → 23B → 加密验证了加密是确定性的（重放客户端包 → 服务器返回相同密文）收获了什么：包 0/1 明文，包 2 是 23B 子密钥，之后全加密子密钥首字节固定 0x12，但跨会话可变穷举标准密码全失败（MD5/SHA/RC4/MT19937）知道了有加密，但不知道加密在哪发生的为什么停在这里：代理只能看密文。看不到加密前的数据，就永远不知道协议字段长什么样。认知升级：这是正确的起点——先搞清楚"对手长什么样"。但这个阶段的结论也很明确：只看密文不够，必须深入客户端。阶段二：neasec 补丁（7/6）— 死路我们当时怎么想的："目录里有个 neasec.dll，导出 StartSecInput、SetSecVersion，名字带 sec，肯定就是加密器。废掉它就能拿到明文。"做了什么：StartSecInput 补丁（c3 ret 直接返回）→ 加密仍在DllMain 补丁（mov eax,1; ret）→ 加密仍在空壳 DLL 替换（4 个导出全 ret）→ 游戏正常启动，加密仍在为什么这条路是死路：三次补丁全部无效，学到一个事实：neasec 不是加密器。它是什么？反作弊/HTTP 遥测。名字里的 "sec" 是 "security"（反外挂），不是 "security"（密码学）。我们被名字误导了。为什么停在这里：事实证明 neasec 和网络加密完全无关。继续折腾它是浪费生命。认知升级：第一次撞墙，但学到关键教训：文件名和导出名会骗人。唯一可信的是运行时行为。阶段三：静态分析找加密入口（7/7）— 死路我们当时怎么想的："neasec 不是加密器 → 加密在 my.exe 里 → 反汇编找。一个大加密函数肯定有巨型栈帧、多轮循环、状态机。"做了什么：capstone 反汇编 my.exe，找到大栈帧函数 0x1e6a7（632B 栈帧、8 状态机）找到格式序列化入口 0x16974找到调用点 0x406C10为什么这条路是死路：全部零触发。这些地址在运行时不走。为什么停在这里：静态分析能定位"看起来像加密"的函数，但没法告诉我们"游戏实际走不走这里"。认知升级：第二次撞墙，学到第二个关键教训：静态分析和运行时是两回事。 一个函数"看起来像加密"不等于"游戏调用它"。静态分析给的是可能性，不是事实。阶段四：Frida 真机 Hook — 系统化探索（7/7-7/9）— 转折点我们当时怎么想的："不猜了。让 CPU 自己告诉我们调用链。Hook 网络发送的底层 API，反查谁调用了它。"做了什么：模块枚举 → 发现 xymain.dll 两个进程都不加载这直接推翻了之前所有基于 xymain 的分析方案ws2_32.send Hook → 稳定抓密文 ✅证明我们能抓到真实的网络数据Thread.backtrace → 拿到调用链：send ← c9485 ← c953c ← c9cc1 ← 69df6逐层 Hook 验证：函数 触发频率 数据内容 结论send_wrapper (c9485) 每 send 1 次 密文 唯一可靠的 send 入口caller_2 (c953c) 每 send 272 次 未知参数 热函数，高频触发caller_3 (c9cc1) 每 send 448 次 未知参数 热函数，高频触发py_bridge (69df6) 零触发 — 调用链不完整encrypt 函数 Hook 成功但零触发 — rotor 只解密 NPK，不走网络xygame Hook 成功但零触发 — 处理渲染，不走网络PyRun_SimpleString 直接调 crash — 时机/上下文不对收获了什么：send_wrapper @ 0xc9485 是唯一可靠的 send 入口（1:1 对应）c953c 和 c9cc1 是 send 路径上的热函数69df6 零触发意味着 backtrace 采样不完整，调用链更深处还有东西c953c/c9cc1 的高频触发不是噪音——这正是逐字段构建数据包的行为为什么当时没继续这条线：我们被"找到加密函数"的目标框住了。c953c/c9cc1 是 272 次/448 次的触发频率，在当时看来是"调试噪音"，我们过滤掉了它，继续去追想象中的"加密函数"。认知升级（回头看才知道的）：这是整个探索最大的教训。我们已经踩到了明文字段构建的入口，但认知框架让我们把它当噪音丢弃了。 如果当时 hook 了这两个函数 dump 参数，协议破解可能当天就完成了。阶段五：KVM Windows VM（7/7-7/8）— 死路我们当时怎么想的："需要一个 Windows 环境自动化 Frida 抓密钥。用 Docker 起 KVM，预配好所有东西，一键跑。"做了什么：dockurr/windows 起 KVM磁盘预配置（Python + Frida + 游戏 + 自启动脚本）迭代调试循环（停→挂盘→查日志→改脚本→重启，每轮 7 分钟）为什么这条路是死路：KVM 在 Intel N100 4核12G 上太勉强Python 3.12 兼容性问题pip 在 VM 里可能回退到源码编译卡死为什么停在这里：资源太重 + 你有 Windows 真机可以直接跑 Frida，完全不需要 VM 绕路。认知升级：第三次撞墙。技术方案的选择要考虑执行环境的约束。N100 跑 KVM 就是小马拉大车，每轮迭代 7 分钟的反馈周期太慢，直接拖死生产力。阶段六：NPK 解密 → PyRun_SimpleString 自举（7/8）— 进行中我们当时怎么想的："NPK 加密是 rotor，key 已知（j2h56ogodh3se），算法已复现。卡在自定义 opcode 153。与其猜 opcode，不如让游戏 Python 引擎自己跑解密。用 PyRun_SimpleString 注入代码，把解密后的 Python 源码写到文件。"做了什么：v1：PyEval hook 内调 PyRun_SimpleString，输出到 C:\frida_pyout.txtv2：修 tasklist 解析（正则）、修触发时机（setTimeout 8s 替代计数 300）、加 try/except现状：v2 脚本已经写好，等你跑结果。如果跑通意味着什么：一次性拿到所有 Python 源码、协议定义、密钥。社区说的"python里都有"——NPK 是加密的 Python 脚本包，解密 NPK = 拿到全部协议逻辑。这条路的风险：PyRun_SimpleString 可能 crash（v1 就崩了）时机难把握（v2 用 setTimeout 8s 延迟触发）输出重定向可能失败但这个方向是对的——攻陷 Python 层可以一次性解所有问题，不用在 C 层和加密函数死磕。逻辑主线总结想抓协议明文 │ ├─→ 代理抓密文 ✓（知道有加密，不知道在哪） │ ├─→ neasec 补丁 ✗（证明非加密器） │ └─ 教训：名字会骗人，只有运行时行为可信 │ ├─→ 静态分析找加密入口 ✗（运行时不走） │ └─ 教训：静态分析和运行时是两回事 │ ├─→ Frida 动态探索 ✓（找到调用链，但追加密函数卡住） │ └─ 最大教训：c953c/c9cc1 是明文字段构建入口，我们当时当噪音过滤掉了 │ ├─→ KVM 自动化 ✗（太重） │ └─ 教训：执行环境约束决定方案可行性 │ └─→ PyRun_SimpleString 自举 ⏳（正确方向——攻陷 Python 层一次性解所有问题）核心教训"python里都有"这句话从头就在那，我们花了快两周才真正理解它的分量。整个探索从 C 层逆向开始，在加密函数上绕了最远的路。neasec 不是加密器、静态分析零触发、VM 太重——这些死路的共同根源是一个认知框架问题：我们默认加密发生在 C 层，默认需要逆向才能拿到协议定义。但事实是：加密是 Python 层调 C 层做的协议定义在 Python 源码里Python 源码就在 NPK 里NPK 解密需要的 rotor key 我们已经有了如果第一周就全力攻 PyRun_SimpleString 自举，可能早就拿到源码了。

向量模型 向量 = 给语义“拍一张数字照片”你可以把向量想象成一种语义坐标。每个文字片段（一句话、一段记忆）送到向量模型里，出来的那串数字（比如 [0.12, -0.34, 0.78, …]）就是它在“语义世界”中的位置。这张“数字照片”抓住了这段话的意思，而不是具体的用词。举个例子：“我养了一只狗” → 向量 A“我的宠物是柯基” → 向量 B“明天会下雨” → 向量 C在语义世界里，A 和 B 的点会很近，因为它们都和“养狗/宠物”有关。而 C 的点会离它们俩都很远，因为它在讲天气。为什么近就代表“相关”？——靠训练时的拉近与推远向量模型在训练时，做的事情非常直接：把意思相近的文本拉近，把意思无关的文本推远。训练数据是大量的“文本对”和相似度标签，比如：正例：“今天好热”→“气温很高”（拉近）负例：“今天好热”→“今天股票跌了”（推远）经过几亿次这样的“拉”和“推”，模型就学会了一套规则：把语义相近的任何文本，都映射到空间中彼此靠近的位置。所以，当把记忆文本和当前问题都映射到同一个空间后，距离自然就代表了语义相关性。检索时发生了什么？——在语义地图上找邻居当你问 Agent：“我的宠物叫什么名字？”这句问题被向量模型转换成查询向量 Q，也就是问题在语义空间里的一个点。向量数据库里，保存着每条记忆的向量位置，比如：M1：“我养了一只狗叫旺财” → 在位置 P1M2：“我喜欢吃披萨” → 在位置 P2M3：“我家狗狗是柯基” → 在位置 P3计算 Q 到所有 P 的距离，发现 P1 和 P3 离 Q 非常近，P2 离得远。于是 M1、M3 被提取出来，因为它们在语义地图上和问题站在了同一个街区。这就是“怎么知道哪些记忆是当前问题所需要的”本质：不是靠关键词匹配，而是靠在意思构成的高维空间中，找离问题点最近的那些记忆点。一个形象的二维类比（实际是几百维）想象你把世界上所有文本的意思，压平到一个巨大的二维地图上：“狗”、“宠物”、“遛狗”相关的内容，都集中在“宠物区”。“机票”、“航班”、“出行”集中在“旅行区”。“代码”、“调试”、“报错”集中在“编程区”。当你问一个关于“宠物”的问题，这个问题会被定位到地图的宠物区。然后你划一个半径很小的圆，圆里所有的记忆就都和宠物有关。那些“机票”“代码”的记忆远在别的区，根本不会被选中。真实模型用的是几百上千维的空间，它比你想象的地图要细腻得多，能区分“狗”和“猫”的细微差异，也能捕捉“可爱”和“凶猛”这种抽象关系。一个容易被忽略的关键：同一个模型映射能实现这种效果，还有一个硬性要求：记忆入库时用的向量模型，和查询时用的向量模型，必须是同一个。因为每个模型创造的“语义世界”不同，地图比例尺、街道命名都不一样。只有用同一张“地图”，查询向量才能准确地落在记忆旁边。总结向量：就是语义的数字坐标，意思相近 = 坐标靠近。怎么知道哪些记忆相关：把问题也变成坐标，在坐标空间里找离它最近的那些记忆点。这背后是模型被训练成了把相似文本映射到相近位置的规则。整个过程完全基于语义理解，而不是关键词匹配，所以即使问题说“宠物”，记忆里写的是“狗”，它们也能撞到一起。

不依赖入站连接的 Cloudflare Worker 方案 一、问题Cloudflare Worker 部署后默认的 *.workers.dev 域名在国内被 DNS 污染，无法直接访问。常规解决方案（绑定自定义域名）需要将域名 DNS 托管给 Cloudflare 或购买付费套餐（Cloudflare for SaaS）。如果你不想转移 DNS 管理，也没有预算，怎么办？二、解决思路核心思想：让 Worker 只做出站请求，不依赖入站连接。Worker 从 Cloudflare 边缘节点主动抓取 RSS/API（出站 fetch 不受任何限制）抓取到的数据通过 HTTP POST 发送到你的一台公网服务器公网服务器经 WireGuard 隧道转发给本地容器容器既可接收推送，也可主动抓取备用数据源这样，用户（或下游系统）通过访问你的公网服务器获取数据，完全无需触碰 workers.dev 域名。