用CDecrypt批量解开Wii U NUS文件：从编译到出结果的完整流程

用CDecrypt批量解开Wii U NUS文件：从编译到出结果的完整流程

【免费下载链接】cdecryptDecrypt Wii U NUS content — Forked from: https://code.google.com/archive/p/cdecrypt/项目地址: https://gitcode.com/gh_mirrors/cd/cdecrypt

CDecrypt 是一个专门解密 Wii U NUS 内容文件的命令行工具：给它一个包含title.tmd、title.tik和内容文件的目录，它会把每个文件按原目录结构还原出来。Wii U 的 NUS 文件是 AES-CBC 加密的，不先解掉这层壳，里面的资源根本读不了。这个版本的 cdecrypt 解密 走纯 C99 实现，内置 AES 和 SHA-1，不链接 OpenSSL，编译完就是一个可执行文件，扔在哪都能跑。

🏗 为什么它能做到单文件运行：三个设计决策

不链 OpenSSL，算法代码直接内置

大多数解密工具要么依赖系统里的 OpenSSL，要么动态链接加密库，换台机器就可能缺依赖。这个 fork 把 mbed TLS 的 AES 实现（aes.c，Apache-2.0 许可）和 SHA-1 实现（sha1.c）直接编进二进制，Makefile里SRC一行就列了全部四个源文件：cdecrypt.c util.c aes.c sha1.c。代价是体积里多了约 100KB 的算法代码，换来的是 Windows、Linux、macOS 三平台行为完全一致。

AES_ROM_TABLES：用空间换时间的查表方案

Makefile第 13 行开了-DAES_ROM_TABLES宏，aes.c里会预先生成FSb[256]/RSb[256]两张 S-Box 查找表而不是运行时计算。对这种按 32KB 大块（0x8000字节）循环解密 CBC 数据的场景，查表比逐轮计算快得多。配合-O2 -std=c99 -Wall -Werror的编译参数，整个项目没有一条外部库依赖链。

UTF-8 处理是怎么做的

Wii U 日版游戏文件名常带日文，Windows 控制台默认 ANSI 编码会直接把路径搞坏。utf8.h里的CALL_MAIN宏在 Windows 下展开为wmain：先用utf16_to_utf8把参数转成 UTF-8，再调SetConsoleOutputCP(CP_UTF8)，之后所有文件操作走_wfopen_s（宏名fopen_utf8）。所以含中文、日文的 NUS 路径可以直接拖进cdecrypt.exe而不乱码，Linux/macOS 下则退化为普通fopen。

🚀 三步跑通：从 make 到第一次出结果

步骤 1：获取与编译

# 克隆仓库并编译，无需任何第三方依赖 git clone https://gitcode.com/gh_mirrors/cd/cdecrypt cd cdecrypt make # 产出 cdecrypt（MinGW/Windows 下为 cdecrypt.exe）

Windows 上如果用 MSVC，直接打开cdecrypt.sln编译；macOS 可以用 Xcode 打开cdecrypt.xcodeproj，也可以照跑make。

步骤 2：第一次解密

# 最简用法：指向含 title.tmd/title.tik 的目录，原地解出 ./cdecrypt /srv/nus/0005000E00012800 # 指定目标目录，中间路径会自动创建 ./cdecrypt /srv/nus/0005000E00012800 /out/zelda_kirby

预期输出会先打印Title version、Content count、FST entries，然后逐文件输出一行Size / Offset / CID / 路径。Windows 下也可以直接把目录拖到cdecrypt.exe图标上。

步骤 3：确认结果可用

解出来的就是明文目录树：FST 文件系统的每个条目按 TMD 里的 ContentID 对应解密，产物可直接喂给资源查看器（如用 hex 工具核对.rpf/资源文件头）、反汇编工具，或作为修改后再打包的输入。原文件全程只读，不被改动。

🔧 三个日常工作流：把 CDecrypt 嵌进你的流程

如果你在做模组资源提取

改模组前你得先拿到明文资源，手动剥加密不现实。把标题目录指向 cdecrypt 一行命令，解出来的目录结构保留 FST 原始层级（extract_file里按FEntry逐层拼路径），直接定位到要改的资源文件，改完回写即可。

如果你在 CI 里批量处理一批标题

手动一个个跑不现实，写个循环：

#!/bin/bash # 批量解密：输入目录下每个标题目录各跑一次 for d in /mnt/nus/*/; do ./cdecrypt "$d" "/out/$(basename "$d")" || echo "FAIL: $d" done

单可执行文件没有依赖，容器里装完 make 就能跑，日志里FAIL的行就是需要人工看的标题。

如果你想读一份真实的 AES-CBC 实现

aes_crypt_cbc在extract_file里的用法是教科书式的：IV 前 15 字节为 0、第 2 字节填 content_id，每块 32KB 解密后直接写盘。对照extract_file_hash还能看到 .h3 保护内容额外做的 SHA-1 校验（每0xFC00字节一块，与 16 个预存哈希比对）。读懂这两个函数，CBC 模式和流式解密就都通了。

⚠️ 踩坑与排错：四个高频报错

遇到 "Could not open" 或找不到 ticket 时

现象：刚放好 NUS 内容文件就跑，直接报错退出。原因：工具必须先读title.tmd和title.tik才能算出 title key（取title_key位于 TIK 偏移0x1BF处，用 TMD 的 TitleID 做一次 CBC 解密），没有票证就无从解起。解决：确保title.tmd、title.tik、%08x内容文件在同一目录；若直接传 TMD 或 TIK 文件，程序会把后缀改成tik/tmd去找另一个，两者必须能互找到。

遇到 "Unknown Root type" 时

现象：报错并打印 Issuer 字符串。原因：只认Root-CA00000003-CP0000000b（零售）和Root-CA00000010（开发机）两个 Issuer，分别对应源码里硬编码的WiiUCommonKey和WiiUCommonDevKey。解决：这是非 Wii U 标题或伪造 TMD，换个正确的标题目录。

遇到 "Could not verify H0 hash" 时

现象：解到某个文件就中断，stderr 上跟了几段 hexdump。原因：该文件是 .h3 保护内容（TMD 标志位0x02），extract_file_hash每0xFC00字节算一次 SHA-1 和预存哈希比对，不一致说明内容文件不完整或与 TMD 不匹配。解决：重新获取完整的 NUS 内容；hexdump 里的块号能帮你确认是哪个文件。

遇到 "Size of content is wrong" 时

现象：内容文件能打开但大小和 TMD 声明不符。原因：内容文件名大小写或后缀不对，程序按%08x.app / %08X.app / %08x / %08X四种 pattern 找，找错了同名文件也会撞上这个错。解决：保留 NUS 下载器给的原始文件名，不要手动改名。

源码地图：想改什么去哪里改

• cdecrypt.c— 主流程main_utf8；普通内容解密在extract_file，.h3 校验解密在extract_file_hash
• aes.c/aes.h— 内置 AES，入口aes_crypt_cbc、aes_setkey_dec
• sha1.c/sha1.h— 一次性接口sha1()，只服务 .h3 校验
• utf8.h—fopen_utf8和 Windows 下的CALL_MAIN
• util.c/util.h—read_file、create_path、is_directory等文件基础

想调整解密块大小，改extract_file顶部的BLOCK_SIZE（当前0x8000）；想换密钥来源或支持新的 Issuer，改main_utf8里aes_setkey_dec的选择分支。有修不动的报错，直接提交到上游仓库 VitaSmith/cdecrypt 的 issue tracker。

NUS 文件读不了的问题，到这一步已经拆干净了：编译一个可执行文件，目录喂进去，明文出来。clone 下来跑一遍make，找一个带title.tmd和title.tik的目录试一次，第一个文件几秒钟就能解出来。

【免费下载链接】cdecryptDecrypt Wii U NUS content — Forked from: https://code.google.com/archive/p/cdecrypt/项目地址: https://gitcode.com/gh_mirrors/cd/cdecrypt