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.

  • 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, 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.
 

Attachments

  • 2168.png
    2168.png
    9.7 KB · Views: 3,295
Last edited by roothorick,

blahblah

Well-Known Member
Member
Joined
May 16, 2018
Messages
1,136
Trophies
0
Age
32
XP
1,440
Country
United States
Well, now that it works, it is fast. Probably will use this, though I may modify it to get rid of the idiotic 'put your keys in a dot folder, because I am offended by copying and pasting a text file' thing.
 

DocBo

Well-Known Member
Member
Joined
Apr 11, 2018
Messages
240
Trophies
0
XP
532
Country
Germany
i have dumped my keys and i placed the keys.txt into prod.key directory but still error message:
Unable to load key header_key!
Make sure you have a valid key list at C:\Users\******\.switch\prod.keys and it contains the header keys and all five application key area keys.
 

Adran_Marit

Walküre's Hacker
Member
Joined
Oct 3, 2015
Messages
3,163
Trophies
1
Location
42*South
XP
3,180
Country
Australia
i have dumped my keys and i placed the keys.txt into prod.key directory but still error message:
Unable to load key header_key!
Make sure you have a valid key list at C:\Users\******\.switch\prod.keys and it contains the header keys and all five application key area keys.

prod.keys is the actual file name

Rename you keys.text to prod.keys and place in \.switch and try again

prod.keys is not a directory y think but the name of the txt file?

you are correct
 
  • Like
Reactions: DocBo

Adran_Marit

Walküre's Hacker
Member
Joined
Oct 3, 2015
Messages
3,163
Trophies
1
Location
42*South
XP
3,180
Country
Australia

Which keys are you using?

and they are located at c:\users\username\.switch\file

--------------------- MERGED ---------------------------

Also do you have file extensions visible? if so make sure it isn't prod.keys.txt
 

whateverg1012

Well-Known Member
Member
Joined
Sep 23, 2016
Messages
573
Trophies
0
XP
1,405
Country
United States
Thanks for sharing! Compatibility seems to be low though, I tried this on 3 different xcis (Touhou Kobuto V Burst Battle, Neo Atlas 1469, and MUSYNX) and although it created a NSP for all of them, only Touhou Kobuto V Burst Battle was able to run properly, everything else crashed on application start.
 

Adran_Marit

Walküre's Hacker
Member
Joined
Oct 3, 2015
Messages
3,163
Trophies
1
Location
42*South
XP
3,180
Country
Australia
Thanks for sharing! Compatibility seems to be low though, I tried this on 3 different xcis (Touhou Kobuto V Burst Battle, Neo Atlas 1469, and MUSYNX) and although it created a NSP for all of them, only Touhou Kobuto V Burst Battle was able to run properly, everything else crashed on application start.

do you meet the FW requirements for the games at are crashing?
 
General chit-chat
Help Users
    Spring_Spring @ Spring_Spring: and post it uwu