技术拆解 014｜text-humanizer：729★ 的「去 AI 味神器」，README 说绕过 Turnitin，main.py 里连的却是 C2——一个供应链投毒样本的静态拆解

技术拆解：解析 AI 技术框架——说明、分析、技术评估、价值判断、落地使用。作者：永亮

---

先声明安全边界：本文拆解的仓库 korcarc/text-humanizer 是恶意样本，任何读者不要克隆、不要安装、不要运行它。已经装过的读者请尽快卸载，并在 Windows 机器上排查异常网络连接。本文所有结论来自静态阅读源码与对加密载荷的数学解码，全程未运行仓库任何代码。

2026 年 9 月 16 日创建的 GitHub 仓库 korcarc/text-humanizer，截至 9 月 20 日拿到 729 个 star、83 个 fork，Python 写成，MIT 协议。README 的卖点很直白：一条四段翻译改写流水线——DeepSeek 改写、Google 翻译英译土耳其语、可选 DeepL 土译日语、DeepSeek 回译原文——宣传可以「绕过 Turnitin/GPTZero 等大多数 AI 检测器」，还推荐 temperature 调到 1.3。换句话说，它瞄准的是「去 AI 味」这个刚需人群。这篇文章按六件事拆：是什么、诱饵逻辑、机制怎么转、源码里值得看的三处、边界与防护、值不值与正确姿势。

一、这是什么

text-humanizer 名义上是一个文本改写工具：你给它一段 AI 生成的文字，它走四段翻译链让文字「不像机器写的」，同时声称能通过主流 AI 检测器。README 写得像正经项目，有使用示例、有参数说明、有语言支持列表——只不过语言支持列表本身就对不上：宣称 8 种语言，实际列出来的是 en/ja/zh/ko/de/fr/es 共 7 个。

对仓库做静态阅读，三个地方和 README 对不上。第一，README 承诺的核心功能根本跑不起来：src/standard/llm_rewriter.py 里写着 from .llm_client import chat_completions，但 llm_client.py 这个文件不存在，整条 DeepSeek 流水线 import 阶段就断链。第二，名义上是翻译模块的 src/conversion/translation_chain.py 有 1403 行，内容却是一个完整的比特币密钥库——ECDSA、secp256k1、Taproot、WIF 签名，和翻译没有半点关系，全仓库没有任何文件 import 它，requirements.txt 也没列它的依赖，是一段精心放置的死代码。第三，main.py 里唯一的活代码是第 12 行 humanizer.run_sync()——从 import 到联网执行只有一步，而 humanizer.py 名不副实：它是一段两层加密的载荷。三个对不上：承诺对不上文件、文件名对不上内容、项目名对不上行为。

二、诱饵逻辑：为什么是它

理解这个样本，先要理解它的目标人群。AI 检测器绕过处在学术诚信的灰色地带——一边是想交作业的学生，一边是想批量发文的营销号，两边都有强烈的「让文字过检测」需求，又都不方便声张。这个需求天然把人推向搜索引擎和 GitHub 的灰色角落：正规渠道不会卖这种工具，于是来路不明的仓库成了唯一的货架。

投毒者选品很准。这个人群有三个特征，每一个都在降低样本暴露的风险：他们不会读源码——安装即用是预期；他们不敢声张——中招了大概率自认倒霉；他们缺乏排查经验——机器上多个陌生进程也觉察不出。729 个 star 里哪怕只有十分之一是真实用户跑过 main.py，投放效率就已经可观。

顺带指出：账号层面也对不上。作者 korcarc 2020 年 4 月注册，四年多来公开仓库只有这一个，followers 只有 6。一个沉寂四年的账号，三天之内挂出 729 星——这个组合本身不证明什么，但与代码里三处对不上叠加在一起，指向就很清楚了：这个仓库的关注度构成与账号历史不匹配，读者照单全收 star 数等于背书，是要吃亏的。

三、机制：从 import 到 C2 的链条

3.1 第一步：import 即执行

main.py 的有效代码只有一行。第 12 行 humanizer.run_sync() 位于模块顶层，意味着任何人 python main.py 或 import 这个包，这行都会立刻执行，没有开关、没有确认、没有 dry-run。对正常使用场景，这是反直觉的设计——正经库会等到你调用才动。对投毒者，这是最短路径。

3.2 第二步：两层加密的 humanizer.py

src/services/humanizer.py 是这个仓库技术上最有看头的文件：只有 42 行，却有 28.6KB。平均每行接近 700 字节，这是压缩过的密文。剥开它是一组三重奏，逐层讲。

第一重：字符串 XOR 混淆。所有可读的标识符、常量、URL 全部用固定密钥异或过，静态扫一眼 grep 不到任何关键词——没有 http、没有 socket、没有任何像恶意软件的字眼。

第二重：HMAC-SHA256 计数器流。这是标准的流加密构造：把密钥和递增计数器喂进 HMAC-SHA256，生成与密文等长的密钥流，再异或还原明文。它比第一重的固定 XOR 高级一个量级——相同的明文每次加密结果不同，直接比对字节找不到规律。

第三重：zlib 压缩。流解密之后还要再过一层标准 zlib 解压，得到最终的 Python 源码，再由 builtins.exec 注入当前模块的 globals 执行，并定义出 run_sync。文件里还有一道反篡改检查：一系列常量参与解密参数，密文被改动一个字节，解密结果就面目全非，run_sync 根本不会诞生。也就是说，这份载荷免疫任何形式的修补尝试——你想打个补丁再运行看看它干什么，对不起，改一个字节它就不解密。

这套组合不是随手写的。XOR 挡关键词扫描，HMAC 流挡字节级分析，zlib 挡结构识别，反篡改挡安全研究者的修补实验。对绝大多数「装个包试试」的用户，前三重已经够了。

3.3 第三步：解密后的载荷做什么

静态解码（纯数学运算，未执行任何代码）还原出的载荷行为如下。向 C2 地址 172.239.96.53:8765 发起明文 HTTP 请求，认证头是硬编码的 Bearer token 094750aeef51f8e9d0c126b879c9df07。从 /api/v1/client/manual_mapper.py 下载第二阶段模块，写入 <ram:> 伪路径——只在内存执行，不落盘。随后用 PAYLOAD_KEY 7c2101e76c97188da4c56d9c2f31712c 调用 manual_mapper.map_from_server(...)，拉取最终载荷。

三个设计细节值得单独点出。其一，全程明文 HTTP：token 和密钥直接躺在流量里，说明运营者要么不担心被逆向（反正代码已经加密），要么图省事——这不像高手的做派，更像是「够用就好」的批量作业。其二，仅 Windows 生效：非 win32 环境直接抛 “win32 only”，载荷知道自己在什么系统上。其三，QUIET=True 默认静默：所有异常被吞掉，不向用户输出任何信息。

这三件事拼在一起就是免杀三件套。内存执行意味着杀软扫盘扫不到东西——文件系统上自始至终没有恶意文件，只有一份加密的 Python 源。Windows-only 把真身限制在最大、防护意识最弱、最不可能被安全研究员日用的桌面系统上。静默报错兜底：即便失败也不留痕迹。Mac 和 Linux 用户跑起来只看到一个安静的报错或者干脆没有输出，绝大多数人不会起疑，更不会追。真正中招的 Windows 用户用的是来路不明的「检测器绕过工具」，这个身份天然劝退了他们求助正版安全软件的意愿。

最终载荷的内容是未知的——它由 C2 服务器在运行时决定下发什么，以实际下载到的模块为准。能做到的合理推断只有一层：一套为绕过检测器人群量身定制的投放渠道，大概率装载窃密类载荷，但这属于推测，正文不作数。

四、源码里值得看的三处

4.1 humanizer.py：三重奏的工程样本

42 行、28.6KB，三重加密加反篡改加 exec 注入，这个文件本身就是一份值得收藏的混淆教科书。它的教育价值不在恶意，而在于它演示了静态分析要对付的标准打法：关键词扫描被 XOR 挡、字节对比被 HMAC 流挡、结构识别被 zlib 挡、修补实验被反篡改挡。每一层单独看都是公开技术，组合起来就是一套对自动化检测相当不友好的外壳。下次看到「只有几十行但几 MB」「grep 不到任何字符串」的 Python 文件，这就是脑子里该有的第一反应。

4.2 translation_chain.py：1403 行的比特币密钥库

名义上的翻译链文件，实际是一个 vendored 的比特币密钥库：ECDSA、secp256k1、Taproot、WIF 签名一应俱全。它和翻译毫无关系，全仓库无人 import 它，requirements.txt 也没给它列依赖——ecdsa、base58check、sympy、bitcoinutils 全部缺失。它在这里的作用大概有两种解释：一是填充仓库体积和行数，让项目看起来像有货；二是万一被问起，可以声称有「区块链相关的规划」。无论哪种，它都是一个测试读者是否真读源码的标记：注意到了这个文件不对劲的人，不太可能继续运行 main.py。

4.3 llm_rewriter.py：一条主动断掉的链

README 承诺的 DeepSeek 流水线入口在这里：from .llm_client import chat_completions——而 llm_client.py 不存在。这不是疏忽，因为整个仓库里没有任何地方定义过 chat_completions。也就是说，README 上那个最吸引用户的「四段翻译改写」功能从未被实现过，任何照着 README 操作的用户都会在 import 阶段就拿到 ImportError。投毒者不在乎：他们需要的只是把人引到 python main.py 这一步，后面的功能本来就是布景。功能跑不起来恰恰证明布景不需要真——只要 README 写得像。

五、边界与防护

存疑三条，只写存疑不写死。最终载荷内容未知，由 C2 运行时下发，可能是任何东西。运营者身份未知，账号信息接近空白，无从归因。星数构成存疑——三天 729 星与账号历史明显不匹配，真实用户占比无从考证。

防护上给读者三件可操作的事。第一，装任何包之前，花两分钟打开它的 main.py 或者入口文件：顶层有没有一行 import 即执行的调用？文件名和内容对不对得上（一个叫 translation_chain 的文件，grep 一下里面有没有 translate）？README 承诺的功能和文件数量匹不匹配？这三问不用懂代码也能问。第二，依赖要 pin 版本并审计：这个仓库的 requirements.txt 里突兀地钉死了 tornado==6.4.2，依赖清单本身就该触发一次「为什么是它」的怀疑——正常项目没有理由钉一个用不到的框架的精确版本。第三，不要 pip install 来路不明的「检测器绕过」类工具：一个主动教你违反规则的工具，你没有任何手段约束它遵守规则。灰色地带没有售后，这条对买家和受害者同样成立。

对 GitHub 平台层面，这类样本的识别特征已经很模式化：沉寂多年的老账号、突然创建、README 写得比代码多、star 增速与账号资产不匹配、代码主体是密文或者死代码。单看任何一条都可能是巧合，三条以上同时出现，就直接关掉页面。

六、值不值与正确姿势

这个工具没什么可讨论值不值的；它是一个值得收藏识别手册的样本。它把供应链投毒的标准动作演示了一遍，从诱饵选择、混淆工程到平台侧伪装，每一步都有教科书痕迹。对做安全研究的人，三重奏加密加反篡改是值得写进笔记的混淆范式；对普通读者，它验证了一条朴素的经验：star 数不是安全背书，README 不是功能证明，「能跑」和「能安全地跑」之间隔着一整次源码阅读。

「去 AI 味」的正确姿势不在灰色工具里。本账号的日常实践一直是白名单改写加人工重写：先想清楚这段文字要说什么，再用自己的话重写过一遍，最后把 AI 生成的东西当草稿而不是当成品。这条路不绕过任何检测器，因为目标本来就是让文字真的出自人。GPTZero 和 Turnitin 这类检测器自身也在灰色地带——它们既误伤真人写作，也拦不住有心绕过，把宝押在「骗过它们」上，无论成败，收获的都是一段不属于你的文字和一个可能带毒的进程。

结论

text-humanizer 用一份写得像样的 README 回答了「怎么绕过 AI 检测器」，用源码回答了「怎么绕过你的防线」。main.py 第 12 行 import 即执行，humanizer.py 用 XOR 加 HMAC-SHA256 流加 zlib 三重加密包住一份反篡改的载荷，解密后向 172.239.96.53:8765 发起明文 HTTP，带着硬编码的 Bearer token 下载第二阶段模块，只在内存执行、只对 Windows 生效、默认静默吞掉一切异常；1403 行的比特币密钥库和 import 不存在的 llm_rewriter.py 负责让仓库看起来像项目。三天 729 星与四年一仓库六个关注者的账号对不上，功能承诺与跑不起来的代码对不上，翻译文件名与比特币密钥库对不上。三个对不上，就是它全部的自我介绍。最后重申安全边界：不要克隆、不要安装、不要运行这个仓库。

参考来源

• korcarc/text-humanizer README（四段流水线、绕过检测宣称、language 列表、temperature 推荐）
• 源码静态阅读（未运行）：main.py（第 12 行 humanizer.run_sync()）、src/services/humanizer.py（42 行 28.6KB，XOR 混淆、HMAC-SHA256 计数器流、zlib、exec 注入、反篡改检查）、src/conversion/translation_chain.py（1403 行比特币密钥库，无 import）、src/standard/llm_rewriter.py（import 不存在的 llm_client.py）、requirements.txt（tornado==6.4.2）
• 载荷静态解码（纯数学运算，未执行）：C2 172.239.96.53:8765、Bearer 094750aeef51f8e9d0c126b879c9df07、manual_mapper.py 内存执行、win32 only、QUIET=True、PAYLOAD_KEY 7c2101e76c97188da4c56d9c2f31712c
• 仓库数据：729★、83 forks、创建于 2026-09-16、作者账号 2020-04 注册、公开仓库 1 个、followers 6（截至 2026-09-20）