用CDecrypt批量解开Wii U NUS文件从编译到出结果的完整流程【免费下载链接】cdecryptDecrypt Wii U NUS content — Forked from: https://code.google.com/archive/p/cdecrypt/项目地址: https://gitcode.com/gh_mirrors/cd/cdecryptCDecrypt 是一个专门解密 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.cApache-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 -stdc99 -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 # 产出 cdecryptMinGW/Windows 下为 cdecrypt.exeWindows 上如果用 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 标志位0x02extract_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_hashaes.c/aes.h— 内置 AES入口aes_crypt_cbc、aes_setkey_decsha1.c/sha1.h— 一次性接口sha1()只服务 .h3 校验utf8.h—fopen_utf8和 Windows 下的CALL_MAINutil.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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 用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/cdecryptCDecrypt 是一个专门解密 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.cApache-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 -stdc99 -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 # 产出 cdecryptMinGW/Windows 下为 cdecrypt.exeWindows 上如果用 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 标志位0x02extract_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_hashaes.c/aes.h— 内置 AES入口aes_crypt_cbc、aes_setkey_decsha1.c/sha1.h— 一次性接口sha1()只服务 .h3 校验utf8.h—fopen_utf8和 Windows 下的CALL_MAINutil.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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考