Switch homebrew team 2168-0002 releases dedbae xci2nsp: A smarter, faster XCI to NSP converter
Find xci2nsp releases here: https://gitlab.com/roothorick/dedbae/tags/
A pretty minor release for 2168, but don't ever say we hoard our creations!
This is an XCI to NSP converter that's smarter and faster than 4nxci.
Use
An x86-64 Windows binary is provided; for non-Windows (note: little endian CPU required) you'll need to build it yourself (see below), and if you bought a Switch but your main computer doesn't have a 64bit processor you need to re-evaluate your life choices.
Place your keyfile in the correct location (this works a bit differently from most tools! See below). Put xci2nsp.exe just anywhere. Run it from the command line with file names as arguments. NSPs will be saved to the current working directory irrespective of the XCI's location.
Alternately, just drag-and-drop XCI files on top of the exe. In this case the NSPs will be saved to the same directory as the XCIs. You can select and drag multiple at once and it will batch-convert them in sequence.
When installing the produced NSPs, Tinfoil will print a warning about failing to install the ticket. This is normal; there is no ticket to install.
Keyfile location
I'm very tired of every tool expecting keys to be in a different place under a different name, usually in the current working directory so you have a dozen copies laying all around your system. So, I'm taking a step towards standardizing that by copying hactool's search paths.
You'll need your keyfile to be "~/.switch/prod.keys" (Linux) or "C:\Users\<username>\.switch\prod.keys" (Windows), unless you have a weird setup that moves the home dir/user profile dir, in which case I expect you to already know what you're doing.
I really would like current and future tools to either do the same, or adopt a different standard location for all apps to go to.
Known issues
Building from source
If you're cloning the repository, note that there are two submodules; you will need to specify --recursive.
Dependencies are basically nonexistent; just the standard GNU toolchain and libc/libstdc++. On Windows you will need MinGW-W64 and MSYS2. Extract/clone wherever, cd into the dir and make. The binary will be copied into the bin/ folder.
OSX will probably not work without a special build environment as GCC extensions are in use. Either way, I don't intend to support OSX; don't have the hardware, don't want the hardware, and really really don't want to mess around with hackintosh.
Why?
When I first started working on this, 4nxci wasn't correctly handling a number of common cases resulting in NSPs that didn't work correctly. In addition,it was re-encrypting with titlekey crypto, something that really isn't necessary, correction: 4n informed me it was just a fake ticket to work around a bug in early Tinfoil, it still left extra cruft on the system in the form of fake tickets in the ticketdb. I think his current version has resolved most of those issues, but I've been using this instead for a while, and it is better, so I should share.
I'll fix any issues people run into, and make updates if we discover XCIs that change things up too much to not work. Beyond that, though, I'm moving on to something considerably more exciting. Expect Big Things from 2168 soon.
Changelog
1.0.0-1: libgcc and libstdc++ are now statically linked in the Windows build. There actually are no meaningful runtime dependencies now.
A pretty minor release for 2168, but don't ever say we hoard our creations!
This is an XCI to NSP converter that's smarter and faster than 4nxci.
- A single, self-contained executable with no dependencies worth mentioning.
- Reads and writes the game exe/assets -- the part that actually takes more than a few seconds -- only once, without decrypting/re-encrypting. No interstitial files. This is as fast as I can make it; the bottleneck is the throughput of your HDD.
- Handles all known XCI/gamecard formats.
- Produces output NSPs with the human-readable game name, title ID, and version ID in hex (much more readable than CDNSP's decimal translation).
- Identifies and extracts embedded updates as a separate NSP.
- No fake tickets, no recrypting with titlekey crypto, no cruft in your ticketdb. Only the update NSPs have tickets, and they're real, official tickets.
Use
An x86-64 Windows binary is provided; for non-Windows (note: little endian CPU required) you'll need to build it yourself (see below), and if you bought a Switch but your main computer doesn't have a 64bit processor you need to re-evaluate your life choices.
Place your keyfile in the correct location (this works a bit differently from most tools! See below). Put xci2nsp.exe just anywhere. Run it from the command line with file names as arguments. NSPs will be saved to the current working directory irrespective of the XCI's location.
Alternately, just drag-and-drop XCI files on top of the exe. In this case the NSPs will be saved to the same directory as the XCIs. You can select and drag multiple at once and it will batch-convert them in sequence.
When installing the produced NSPs, Tinfoil will print a warning about failing to install the ticket. This is normal; there is no ticket to install.
Keyfile location
I'm very tired of every tool expecting keys to be in a different place under a different name, usually in the current working directory so you have a dozen copies laying all around your system. So, I'm taking a step towards standardizing that by copying hactool's search paths.
You'll need your keyfile to be "~/.switch/prod.keys" (Linux) or "C:\Users\<username>\.switch\prod.keys" (Windows), unless you have a weird setup that moves the home dir/user profile dir, in which case I expect you to already know what you're doing.
I really would like current and future tools to either do the same, or adopt a different standard location for all apps to go to.
Known issues
- File permissions related problems are handled poorly and may produce cryptic errors.
- Disk space is not checked. If you're not paying attention, you may get most of the way through a conversion only to get a "No space left on device" error.
- The output file names are deliberately ASCII only, to avoid a bug in Horizon. Non-ASCII characters are translated using a C++ version of Unidecode, which doesn't handle Japanese very well. Names composed mainly of kanji will be badly bastardized. (If you've used CDNSP in the past you may be familiar with what this looks like.)
- On Windows, xci2nsp may fail to open XCI files if their filename contains "wide" characters (e.g. Japanese alphabets). Filenames with such characters tend to cause problems with a lot of things, so you really should just rename them.
- If an English translation for a game was added in an update (e.g. Taiko), and the update is embedded in the XCI, the base game NSP's filename will have the game's name in the original language (e.g. Japanese), but the update NSP's filename will have the English name.
Building from source
If you're cloning the repository, note that there are two submodules; you will need to specify --recursive.
Dependencies are basically nonexistent; just the standard GNU toolchain and libc/libstdc++. On Windows you will need MinGW-W64 and MSYS2. Extract/clone wherever, cd into the dir and make. The binary will be copied into the bin/ folder.
OSX will probably not work without a special build environment as GCC extensions are in use. Either way, I don't intend to support OSX; don't have the hardware, don't want the hardware, and really really don't want to mess around with hackintosh.
Why?
When I first started working on this, 4nxci wasn't correctly handling a number of common cases resulting in NSPs that didn't work correctly. In addition,
I'll fix any issues people run into, and make updates if we discover XCIs that change things up too much to not work. Beyond that, though, I'm moving on to something considerably more exciting. Expect Big Things from 2168 soon.
Changelog
1.0.0-1: libgcc and libstdc++ are now statically linked in the Windows build. There actually are no meaningful runtime dependencies now.
Attachments
Last edited by roothorick,
