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,351
Last edited by roothorick,

RattletraPM

Well-Known Member
Member
Joined
Jan 18, 2017
Messages
897
Trophies
1
XP
8,184
Country
Italy
Neat stuff, I literally just got (and hacked) my Switch yesterday and I was wondering why converting a XCI to NSP took so much.

Great job! :yayswitch:
 

blahblah

Well-Known Member
Member
Joined
May 16, 2018
Messages
1,136
Trophies
0
Age
33
XP
1,451
Country
United States
"No dependencies" yet it depends on a ton of *Nix toolchain shit. And wants the user to use nix style dot folders. Typical...

Another 'fine release' from the 2168 kids.
 
Last edited by blahblah,
  • Like
Reactions: nmkd

Crusatyr

Well-Known Member
Member
Joined
Jul 31, 2016
Messages
197
Trophies
0
XP
863
Country
United States
"No dependencies" yet it depends on a ton of *Nix toolchain shit. And wants the user to use nix style dot folders. Typical...

Another 'fine release' from the 2168 kids.

"no dependencies worth mentioning" is different than "No dependencies." It's to be expected if you're compiling something that you have the basic toolchain shit right?

As far as your second comment. Sure, we're just getting our foot in the door, but we aren't complaining about the releases other groups put out. We see something we like, and we try to do it better. But who knows, eventually, you may see our name in lights. But first, baby steps my man, and let us celebrate small victories as a community of Switch enthusiasts, not attacking one another like children.
 

roothorick

Well-Known Member
OP
Newcomer
Joined
Jan 30, 2008
Messages
51
Trophies
0
XP
477
Country
United States
"No dependencies" yet it depends on a ton of *Nix toolchain shit. And wants the user to use nix style dot folders. Typical...

Another 'fine release' from the 2168 kids.

Oh please. "GCC and friends" isn't "a ton". That's barely the minimums for compiling anything on Linux. And that's only compile time. The finished binary only depends on basic runtime libraries you'll find already present on pretty much every system.

The dotfolder replicates hactool's behavior, because I wasn't interested in striking out on my own on the standardization. If you've got a better folder structure in mind, make some pullreqs to various projects to implement it.
 
  • Like
Reactions: enarky

blahblah

Well-Known Member
Member
Joined
May 16, 2018
Messages
1,136
Trophies
0
Age
33
XP
1,451
Country
United States
Oh please. "GCC and friends" isn't "a ton". That's barely the minimums for compiling anything on Linux. And that's only compile time. The finished binary only depends on basic runtime libraries you'll find already present on pretty much every system.

The dotfolder replicates hactool's behavior, because I wasn't interested in striking out on my own on the standardization. If you've got a better folder structure in mind, make some pullreqs to various projects to implement it.

No one gives a fuck about Linux. Running this app on Windows is a massive pain in the ass, that's the issue here. 4nxci just runs. Your app wants a boatload of GCC dlls.

There is no need for standardization of the location of key.txt. Copy and pasting a tiny .txt file is not a big deal.

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

"no dependencies worth mentioning" is different than "No dependencies." It's to be expected if you're compiling something that you have the basic toolchain shit right?

As far as your second comment. Sure, we're just getting our foot in the door, but we aren't complaining about the releases other groups put out. We see something we like, and we try to do it better. But who knows, eventually, you may see our name in lights. But first, baby steps my man, and let us celebrate small victories as a community of Switch enthusiasts, not attacking one another like children.

It has dependencies to run. Try running the posted .exe on a bare Windows install and 'enjoy'.
 

jakkal

Well-Known Member
Member
Joined
Apr 27, 2018
Messages
2,298
Trophies
1
Age
42
XP
3,861
Country
United States
"No dependencies" yet it depends on a ton of *Nix toolchain shit. And wants the user to use nix style dot folders. Typical...

Another 'fine release' from the 2168 kids.
What have you released? Let's see your Homebrew that you've shared with the community. Ungrateful incel
 

MSearles

Well-Known Member
Member
Joined
Jan 4, 2016
Messages
564
Trophies
0
Age
34
XP
2,026
Country
United States
Why does everyone want all of their files in nsp format? Almost all of mine are xci. Is it s better format somehow?
 

Draxzelex

Well-Known Member
Member
Joined
Aug 6, 2017
Messages
18,029
Trophies
1
Age
28
Location
New York City
XP
11,948
Country
United States
Why does everyone want all of their files in nsp format? Almost all of mine are xci. Is it s better format somehow?
You cannot load certain things as .XCI such as updates or DLC. .NSP are also faster than .XCI when it comes to load times as well as smaller. Lastly, you can not only play .NSP files without an SD card but you can install them without one as well. .XCI files are inferior to .NSP format in nearly every single way imaginable.
 

roothorick

Well-Known Member
OP
Newcomer
Joined
Jan 30, 2008
Messages
51
Trophies
0
XP
477
Country
United States
No one gives a fuck about Linux. Running this app on Windows is a massive pain in the ass, that's the issue here. 4nxci just runs. Your app wants a boatload of GCC dlls.

There is no need for standardization of the location of key.txt. Copy and pasting a tiny .txt file is not a big deal.

It has dependencies to run. Try running the posted .exe on a bare Windows install and 'enjoy'.

Boy are you ever a pleasant person.

The DLL issue was a bug and has been fixed.

Given your demeanor, I don't consider it worthwhile to discuss the other points with you.

Doesnt work, because it can't find libstdc++-6.dll & libgcc_s_seh-1.dll

Sorry! Fixed in 1.0.0-1
 

Der_Blockbuster

Well-Known Member
Member
Joined
Mar 2, 2016
Messages
866
Trophies
0
Age
22
XP
2,666
Country
Germany
Did you install c++ library installed? You can get it from the Microsoft website
Because there is like not only 1 library exisiting_

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

Boy are you ever a pleasant person.

The DLL issue was a bug and has been fixed.

Given your demeanor, I don't consider it worthwhile to discuss the other points with you.



Sorry! Fixed in 1.0.0-1
Works like a Charm now!
Thanks for this tool!
 
General chit-chat
Help Users
    Dark_Phoras @ Dark_Phoras: Prey - this kicks Alien's ass all day