crass 0.4.14.0：老牌GalGame封包提取工具，命令行拆解立绘与BGM

简介：crass 0.4.14.0 是一款面向 GALGAME 资源提取的经典工具，配套 CrageGUI 图形界面，解决视觉小说类游戏中封包文件无法用普通压缩软件打开、图像音频与剧本素材难以取出和编辑的问题。压缩包为 RAR 格式，约 4.85MB，共 510 个文件；其中 319 个 txt 说明与 170 个 cui 插件是主体，覆盖 Kirikiri2、EntisGLS、RealLive、Leaf 等多个引擎的封包解析，另有 9 个 dll 运行库、5 个 exe 程序及少量 loc、jar、xml 等辅助文件。CrageGUI.exe 为主程序，配合 libeay32、zlib1、libbz2 等动态库可识别不同压缩与加密方式；压缩包内还包含 acui_core.dll、resource_core.dll、io_request.dll、package_core.dll 等核心模块，分别负责界面、资源、输入输出与封包处理，并内置中文说明，便于非编程用户直接使用。已有 712 人浏览学习。整体目录按插件、运行库与主程序分层，适合玩家、汉化者和游戏资源研究者提取素材、分析封包结构，也可作为了解 GALGAME 资源封装思路的参考，对汉化、素材整理与逆向分析都有实用价值。

1. crass 0.4.14.0：老牌GalGame资源提取工具，一条命令拆出立绘与BGM

搞单机游戏素材拆包的人，大概率都听过 crass 0.4.14.0。这工具很老了，但直到今天，想从老旧 GalGame 的封包里抽出立绘、CG、BGM 和脚本，它依然是绕不开的那个选择。它的核心价值就一句话：把各种加密或打包后的游戏资源容器，还原成一堆你能直接看的图片和音频。适合三类人——做素材整理的老游戏爱好者，需要拆包确认引擎和资源结构的从业者，以及单纯想看看某个游戏里到底塞了哪些文件的折腾党。但它不是万能钥匙，新引擎的封包经常解不开，这一点想提前认清。

2. 封包格式与选型：为什么它能解XP3、ARC，却对某些新引擎没辙

2.1 封包容器与crass的识别原理

游戏厂商很少把资源裸放出来，几十上百张图片、音频和脚本，通常会被塞进一个大文件里。这个文件有自己的文件表结构，记录每个资源的偏移、大小、文件名甚至压缩方式，方便游戏运行时一次性读取。这类容器就是封包。crass 的工作，是把这些容器的壳拆开，按文件表还原出内部资源。

识别封包的关键在于文件头。crass 对这事的处理思路比较直接：先按扩展名猜，猜不中就扫描文件头特征。举例：

这也就是为什么把 .dat 文件改成 .bin 后缀，crass 往往照样能认。它读的是文件头特征，不是扩展名。我实际拆过一个连后缀都没有的封包，crass 在扫描阶段认出了特征，照样把内容吐了出来。

2.2 为什么 0.4.14.0 到现在还在用

接触 crass 比较晚的人可能会问：版本号停在 0.4.14.0，为什么不去找更新版？答案是：这个版本针对老式脚本引擎的加密格式覆盖最全，后来的更新主要在修个别插件崩溃，整体解包能力没有质变。再加上 crass 这类工具更新不积极，网上流传的资源版本五花八门，但被验证能稳定跑老封包的，反而还是 0.4.14.0。

选型建议要分场景：

• 拆 10 年前的老游戏封包，0.4.14.0 够用
• 拆引擎比较新的游戏，crass 大概率直接报格式不支持，这时候别死磕，换引擎专用提取器更省时间
• 拿不准封包类型时，先用 crass 扫一遍，报不支持再换工具

常见的误用是把 crass 当万能提取器，任何封包都往里面丢。真实情况是它对老格式优化充分，对新引擎的反应很迟钝。务实做法是同时备一个支持新引擎的提取工具，按格式分流，两个配合覆盖大部分需求。

2.3 内置图像解码能力与输出格式

crass 强的地方不只是拆包，还自带了一组图像解码器。很多游戏容器里存的图片不是标准 BMP 或 PNG，而是带额外通道信息或加密的特殊格式。crass 在解包的同时会把这些数据转成通用格式，常见的输出是 32 位 BMP，带 Alpha 通道。这对后续做立绘抠图、换背景非常重要，透明信息可以在转换时直接保留。

我一般会把素材提取成 BMP 而不是立刻转 PNG，原因是 BMP 是原始位图，通道信息无损耗，后续批量转换工具处理时更稳。等确认提取结果没问题，再做统一格式转换。这样做的另一个好处是排查方便：如果某个图片转出来花屏，回头重新看原始 BMP，能快速判断是解包问题还是转换工具问题。

2.4 命令行基础参数与使用习惯

GUI 适合单文件操作，批量拆包时命令行更实际。crass 0.4.14.0 的常见调用方式是直接把封包路径作为参数传进去：

Crass.exe "D:\game\data.xp3"

把封包路径作为第一个参数传给 crass，它会自动识别格式并解到相应位置。指定输出目录时，常见写法是：

Crass.exe "D:\game\data.xp3" -o "D:\extract"

参数说明：

• 第一个参数是封包文件路径，必须存在且不能是乱码路径
• -o 后接输出目录，目录不存在时会自动创建
• 不带 -o 时，不同版本的默认输出位置不太一样，有的在当前目录，有的在工具目录下，最好先跑一次确认

有一点要提醒：某些版本的 crass 在传参后依然会弹出 GUI 窗口，而不是纯命令行静默运行。遇到这个情况别急着判断命令无效，看看输出目录里有没有新生成的文件，大概率已经解完了，只是窗口没关而已。

3. 实战流程：拖拽提取与命令行批量解包全记录

3.1 GUI 提取：三步走

先说最省事的 GUI 流程。建议先复制一份封包到工作目录再操作，避免在对原始文件操作时弄脏数据，尤其是在封包较大或网络下载不完整的情况下。

第一步，双击运行 Crass.exe，把封包文件直接拖进窗口。拖进去后，窗口会自动识别封包类型并显示相关信息，比如文件数量、封包体积。第二步，在输出路径栏选择一个空目录，最好建一个专门放提取结果的文件夹，方便后续整理。第三步，点开始提取，等进度条走完。

这个流程简单，但有两个细节值得注意。其一，拖拽时不要同时拖多个文件，部分版本对多文件拖拽支持不好，会只认第一个文件。其二，输出目录不要选成游戏安装目录本身，crass 会按封包内部结构生成子目录，混在一起后期很难清。

3.2 命令行批量解包：for 循环遍历目录

游戏封包通常不止一个。常见情况是 data.xp3、data2.xp3、bgm.xp3、se.xp3 一堆分卷，GUI 一个一个拖太慢。这时可以用批处理脚本统一处理：

@echo off setlocal enabledelayedexpansion set TOOL=D:\tools\Crass\Crass.exe set OUT=D:\extract_all if not exist "%OUT%" mkdir "%OUT%" for /r "D:\game" %%i in (*.xp3 *.arc *.dat) do ( echo now processing: %%i "%TOOL%" "%%i" -o "%OUT%" ) echo all done pause

逻辑说明：

• for /r "D:\game" 递归遍历该目录及所有子目录
• %%i 依次拿到每个匹配的封包完整路径
• 对每个封包调用 crass 并统一输出到 D:\extract_all
• mkdir 保证输出目录存在，echo 用于跟踪进度

注意点有三个。第一，TOOL 和 OUT 路径如果含空格，必须用引号包住，否则命令会断在空格处。第二，%%i 在 for 循环里是当前遍历项的变量，记得是双百分号；直接在命令行写单百分号会报错。第三，如果你的 crass 版本不支持 -o 参数，去掉它，解包结果会输出到默认目录，只是后期整理要多走一步。

这里有个弹窗问题值得说清楚：如果批处理跑起来后发现 crass 弹 GUI 而不是静默执行，说明当前版本把命令行参数忽略掉了。此时的应对方法有两个——要么换一个带纯命令行核心的版本；要么老老实实用 GUI，但可以把封包统一复制到某个文件夹，用鼠标快速拖拽进窗口，效率也能接受。

3.3 提取结果的核对：文件数量与日志

提取完成后先别急着删原始封包，核对和解包同样重要。crass 在解包过程中会输出日志信息，有时会生成类似 extract_log.txt 的文件，里面记录了每条文件是否成功解出。我习惯先看日志里有没有 fail 或 error 关键字，有的话重点排查对应文件。

然后统计输出目录的文件数量：

dir /s /b "%OUT%" | find /c ".bmp"

这条命令递归列出输出目录下所有路径，再统计包含 .bmp 的行数，作用就是快速看提取出的图片总数。把图片数量和音频数量分别统计，再和封包内文件表里对应的条目数对比。对得上说明这次解包比较完整；对不上就要重新提取一次。

3.4 解包后的文件命名问题

提取出来的文件名分三种情况：保留原始文件名、按内部编号命名、或因编码问题变乱码。前两种问题不大，乱码需要处理。日本游戏的封包内部文件名大多是日文编码，中文系统下直接显示成乱码，不处理的话后期整理会很难受。

常见做法是先用转区工具启动 crass，让它以日语代码页运行，提取出的文件名就是正常日文。输出日文文件名虽然看起来还是不懂，但至少不是乱码，配合在线翻译或字符映射能还原出含义。另一种做法是提取后批量重命名，但游戏素材之间可能存在引用关系，文件名被改动后关联会断，所以优先用转区方式，实在不行再重命名。

4. 解包避坑清单：杀软误报、黑边、乱码、解不开的五个血泪记录

这一部分单独拿出来写，因为 crass 给人留下的“玄学工具”印象，基本都来自这五个问题。每条都按实际场景拆开讲。

4.1 现象：杀毒软件把 crass.exe 隔离了

把 crass 下载解压后，杀毒软件直接把 exe 给删了，或者加压缩包时提示“检测到风险程序”。这个情况在很多机器上都出现过。

原因有几个：crass 是很久以前的工具，加壳方式老旧，数字签名过期甚至没有签名；同时解包工具的行为本身接近文件读取和还原，容易触发隔离策略。这不代表工具一定有问题，但也不能排除网上流传的版本确实被某些人动过手脚。

解决方法是先别急着关杀毒软件。把下载的压缩包丢到虚拟机或隔离沙箱里跑一遍，确认它只做文件解包相关的操作后，再把 crass 所在的目录加入杀毒软件白名单，允许目录内程序运行。之后每次使用都从这个固定目录调用，不要从压缩包里临时解压到别处。

4.2 现象：解出的 BMP 立绘带黑边或紫边

立绘提取出来，用看图软件打开，发现人物边缘和透明区域全是黑块或者紫块，以为是提取失败。实际上素材本身没问题，问题出在 Alpha 通道上。

原因：游戏素材是带透明通道的 32 位位图，透明区域在游戏里被引擎处理成不可见。看图软件不会自动处理 Alpha，直接把透明区域按默认黑色显示，就出现了黑边。紫色边一般是因为 BMP 内部某些通道数据被看图软件错误解释。

解决：把 32 位 BMP 批量转成 PNG，转换工具会让透明通道信息以 PNG 方式保留，看图软件也就能正确显示透明。转换工具选常见的批量转换即可，注意勾选“保留 Alpha 通道”选项，否则转出来还是会出问题。

4.3 现象：文件名日文乱码，素材没法整理

提取出来的文件名全是“锟斤拷”之类的乱码，或者干脆是“?????”，没法判断哪个文件是哪个角色。

原因：crass 在中文系统下运行，输出文件名时使用了日文编码的字符串，而系统代码页是简体中文，两者不对应，就显示成乱码。

解决：用转区工具，只对 crass 进程启用日语环境，然后再运行提取。这样输出文件名就是正常的日文。如果转区后依然乱码，再看是不是压缩包内的文件名本身在打包时就已经损坏，这种情况只能接受编号文件名，后期靠图片内容逐个整理。

4.4 现象：解包卡死或进度条不动

提取到某个文件时，进度条不走了，也不报错，等很久都没反应。第一次遇到时容易误判是工具崩溃。

原因：封包内部有损坏的压缩块，或者文件表里记录的偏移与实际数据不一致，导致读取循环没结束。这种情况在网络下载不完整的游戏资源里尤其常见。

解决：先给 crass 几分钟时间，确认是真卡死还是处理慢文件。如果确实一直不动，结束进程，把原始封包重新校验一遍完整性，比如对比压缩包大小或哈希值，确认没问题再提取。如果封包本身损坏，当前版本的工具救不回来，重新下载游戏资源包往往比定位哪个字节坏了更省事。

4.5 现象：“格式不支持”或缺少运行库

双击 crass 时报“应用程序配置不正确”，或者提取某个封包时提示“格式不支持”或“unknown format”。

这两个是不同问题。前者是系统缺少旧版运行库，常见做法是安装对应的 VC++ 运行库，或者从完整压缩包里把 dll 依赖文件一起放好再运行。后者是封包格式超出了 crass 的认知范围，一般是新引擎封包，需要用其他工具处理。

解决“格式不支持”的最稳路径是去查封包的引擎类型，确认它属于哪个脚本引擎，再找对应的引擎专用提取器。不建议开着 crass 硬试，因为 crass 对不认识的封包只会输出一个通用错误，再多试也没有额外信息。

4.6 现象：双封包混装时只解出其中一个

某些游戏会把多个封包合并成一个，或者一个封包里嵌套另一个封包。crass 解第一层没问题，解到嵌套部分时直接跳过或报错。

原因是 crass 的文件表解析只处理当前容器，嵌套容器被视为普通文件，不会递归解包。解决方法是先解外层，看输出里有没有大体积的未知后缀文件，再用 crass 对这个文件单独识别一次。很多嵌套包实质上就是另一个封包文件换了个后缀，单独丢进去就能解出来。

5. 进阶技巧：批处理脚本批量提取与结果验证

5.1 提取后批量转 PNG

提取完的 BMP 数量大、体积也大，直接转成 PNG 能省不少空间，也让透明通道的预览更直观。用 PowerShell 批量处理很方便，前提是使用 Windows PowerShell 5.1，因为脚本里依赖的 System.Drawing 在较新的 PowerShell Core 里可能不可用。

Get-ChildItem -Path D:\extract_all -Recurse -Filter *.bmp | ForEach-Object { Add-Type -AssemblyName System.Drawing $img = [System.Drawing.Image]::FromFile($_.FullName) $out = $_.FullName -replace '\.bmp$', '.png' $img.Save($out, [System.Drawing.Imaging.ImageFormat]::Png) $img.Dispose() }

脚本逻辑是递归查找输出目录下所有 BMP 文件，逐个加载并保存为同名的 PNG 文件，最后释放资源。注意 .bmp 原文件不会被自动删除，确认转换无误后可以手动清理。转换过程中如果某些图片加载失败，先把原始 BMP 用看图工具打开确认是否损坏，别急着重新提取。

5.2 解包完整性验证

完整验证比想象的重要。以前踩过这样的坑：提取出的文件数量差几个，但没有报错，直到后期做素材整理时才发现某个立绘缺失。复盘后发现是封包本身有多卷文件，crass 只读取了第一卷，后续分卷没联动分析。

从那以后我每次解包都强制走一遍验证流程：

• 第一步，统计原始封包大小和提取目录大小，差距过大时优先怀疑文件表解析不完整
• 第二步，用文件数量命令核对，图片和音频分别统计
• 第三步，抽查压缩率最高的几个文件，这类文件最容易在提取时出问题

这套流程虽然不能保证百分百捕获所有异常，但能把大多数静默错误拦下来。crass 0.4.14.0 能解决的问题边界其实很清晰：老封包、老引擎、批量解包它都在行；新游戏、嵌套结构、损坏压缩块这些场景就别硬抗。工具是死的，搭配确认流程，用起来才能真正省心。希望帮到你。

本文还有配套的精品资源，点击获取