Hacking What's the challenge with the XCI loader?

[Khar00f]

Good day everyone,

I'm an SX OS user and arguably their biggest accomplishment has been XCI loading.

This thread is not to debate the merits of NSP over XCI or vice versa.

I personally prefer XCI over NSP and I keep wondering with all the great coders for switch and the guys doing the various CFW (except Atmosphere as we know it's reason is of ethical nature) what's the hold-up on release an XCI loader? Is it lack of interest or technical hurdles?

What's your understanding or take on it? Would love to hear from some devs if any.

 

[r5xscn]

I assume an XCI loader greatly correlates to piracy. Can you give me other reasons for using XCI loader that cannot be accomplished with NSP outside of ease of loading ROMs? As a programmer myself, I don't want to have piracy in my portfolio (which I assume is totally different than enabling homebrews).

 

[midstor]

It's 100% possible but takes way too much work, team xecuter has money to back them up open source developers such as ReiNX developers do not have money behind them to work on a giant project like that maybe if someone made one for that bountry

 

[Draxzelex]

It's 100% possible but takes way too much work, team xecuter has money to back them up open source developers such as ReiNX developers do not have money behind them to work on a giant project like that maybe if someone made one for that bountry

This makes no sense. .NSP support was easily developed shortly after ReiNX became public (initially it used pre-patched ES firmware but then developed on-the-fly patching) as well as by Atmosphere via rajkosto (shortly after ReiNX developed on-the-fly ES patching) because .NSP are superior over .XCI. Neither CFW had any money backing these developments. There's no reason to emulate .XCI loading outside of convenience since .NSP already does everything .XCI does but better.

 

[Gullwing]

This makes no sense. .NSP support was easily developed shortly after ReiNX became public (initially it used pre-patched ES firmware but then developed on-the-fly patching) as well as by Atmosphere via rajkosto (shortly after ReiNX developed on-the-fly ES patching) because .NSP are superior over .XCI. Neither CFW had any money backing these developments. There's no reason to emulate .XCI loading outside of convenience since .NSP already does everything .XCI does but better.

Care to elaborate as to why .NSP is better than .XCI for an SX OS user? I mean, .XCI is way more convenient than having to install a file from your SD card.

 

[solitaire4eva]

I love not having to install anything with XCI. Whats so bad about being simple right out of the box lol

 

[Draxzelex]

Care to elaborate as to why .NSP is better than .XCI for an SX OS user? I mean, .XCI is way more convenient than having to install a file from your SD card.

• You can install DLC and updates with .NSP unlike .XCI which have to rely on buying/downloading them (or using .NSP in conjunction which defeats the purpose using a .XCI in the first place)
• .NSP are smaller than even a trimmed .XCI file
• .NSP have faster load times than .XCI files
• .NSP can be installed without an SD card
• .NSP can be launched without an SD card

 

[jajamundo]

• You can install DLC and updates with .NSP unlike .XCI which have to rely on buying/downloading them (or using .NSP in conjunction which defeats the purpose using a .XCI in the first place)
• .NSP are smaller than even a trimmed .XCI file
• .NSP have faster load times than .XCI files
• .NSP can be installed without an SD card
• .NSP can be launched without an SD card

But NSP get you ban without a doubt. At least with XCI you can avoid this if you connect to the Internet. I always update my XCI games via official method. Try doing this with a nsp and you get your free ban

 

[Draxzelex]

But NSP get you ban without a doubt. At least with XCI you can avoid this if you connect to the Internet. I always update my XCI games via official method. Try doing this with a nsp and you get your free ban

If you make a clean NAND backup, or use an EmuNAND solution, you can avoid a ban regardless if you use .NSP or .XCI. Not to mention that there are plenty of users not banned for using .NSP files if you take a look at the spreadsheet. Lastly, there are still people banned for using .XCI files, both online and offline.

 

[Philourer]

I assume an XCI loader greatly correlates to piracy. Can you give me other reasons for using XCI loader that cannot be accomplished with NSP outside of ease of loading ROMs?

Personally, I use backups (including unique cert) of physical carts I have. Three Switches, three kids. Imagine the wear and tear the carts and the Switches' cart readers would take (if you don't have kids, then don't comment "not that much, I'm constantly changing carts and they look brand new!"). Arguments because everyone wants to play the same game at the same time (only an issue if they can't...since giving them full access to all games at all times, they miraculously are able to both play on the same Switch). No worrying about lost carts (my daughter lost an SX Pro at a sleepover, not to mention the sand that got in the case and Switch itself). It's easier to pack up all your games and move across country if they are all digital (I do this with DVDs, we've moved multiple times and I can keep them all at my mom's house).

 

[midstor]

This makes no sense. .NSP support was easily developed shortly after ReiNX became public (initially it used pre-patched ES firmware but then developed on-the-fly patching) as well as by Atmosphere via rajkosto (shortly after ReiNX developed on-the-fly ES patching) because .NSP are superior over .XCI. Neither CFW had any money backing these developments. There's no reason to emulate .XCI loading outside of convenience since .NSP already does everything .XCI does but better.

Saying that nsp is better is ignorant and just an opinion. And .NSP is installable via nintendo's actual horizon OS so all they needed to do was make sig patches. You need to write a system module and a homebrew app to interact with that sys module. It's not as easy as you think.

 

[Khar00f]

If you make a clean NAND backup, or use an EmuNAND solution, you can avoid a ban regardless if you use .NSP or .XCI. Not to mention that there are plenty of users not banned for using .NSP files if you take a look at the spreadsheet. Lastly, there are still people banned for using .XCI files, both online and offline.

So what i'm gathering so far is really a lack of interest as devs don't see a benefit and mainly for niche group of users.

I can vouch for the fact that using NSP's doesn't equal BAN (for now), I currently use a combination of XCIs and NSP's and update them all by official means by being connected to WiFi, I just don't have any NNID connected to that switch.

Speaking of EmuNAND, currently the only solution is SX OS, are you aware if both NAND's share the same telemetry report or if the EmuNAND has it's own or redirects it's telemetry flags to creport (or soemthing like that)?

 

[r5xscn]

Personally, I use backups (including unique cert) of physical carts I have. Three Switches, three kids. Imagine the wear and tear the carts and the Switches' cart readers would take (if you don't have kids, then don't comment "not that much, I'm constantly changing carts and they look brand new!"). Arguments because everyone wants to play the same game at the same time (only an issue if they can't...since giving them full access to all games at all times, they miraculously are able to both play on the same Switch). No worrying about lost carts (my daughter lost an SX Pro at a sleepover, not to mention the sand that got in the case and Switch itself). It's easier to pack up all your games and move across country if they are all digital (I do this with DVDs, we've moved multiple times and I can keep them all at my mom's house).

I haven't tinkered with my switch yet, but can't you use NSP with the certificate? It should work the same I assume. In the 3DS days, I prefer CIA over Gateway loading (I have a gateway card).
The only benefit of XCI/Gateway loading that I can think of you don't need to install it on your system, plug and play.

 

[Draxzelex]

Saying that nsp is better is ignorant and just an opinion. And .NSP is installable via nintendo's actual horizon OS so all they needed to do was make sig patches. You need to write a system module and a homebrew app to interact with that sys module. It's not as easy as you think.

You're not making any sense nor are you reading my posts. There are objective advantages that .NSP files have over .XCI which you cannot nor even tried denying.

So what i'm gathering so far is really a lack of interest as devs don't see a benefit and mainly for niche group of users.

I can vouch for the fact that using NSP's doesn't equal BAN (for now), I currently use a combination of XCIs and NSP's and update them all by official means by being connected to WiFi, I just don't have any NNID connected to that switch.

Speaking of EmuNAND, currently the only solution is SX OS, are you aware if both NAND's share the same telemetry report or if the EmuNAND has it's own or redirects it's telemetry flags to creport (or soemthing like that)?

I mean I don't have anything against .XCI support; the more formats a CFW supports, the more options a user has. Although since we already have .XCI installation which shares the same detection as loading a .XCI, the implementation of raw .XCI loading is just to prove a point than offer it to users.

Speaking of EmuNAND, because TX's implementation is a resized NAND, simply loading it will generate error reports and telemetry that would spell a ban for any user who accidentally goes online with it. However since SysNAND and EmuNAND share no telemetry, this is not an issue normally. What is worrisome is the modification to boot1 with the "EmuNAND magic" and the up to 15 GB file in the USER partition. Now similar to how .XCI files are installed, EmuNAND is installed into the USER partition which Nintendo does not scan supposedly. However that can all change in a future firmware update which TX cannot patch in OFW which a user would be going online with if they are using EmuNAND. There has also been no bans for proper utilization of TX's EmuNAND (technically one user reported a ban for using EmuNAND but he did not restore a clean NAND before installing it) but that can change at anytime.

 

[Khar00f]

Saying that nsp is better is ignorant and just an opinion. And .NSP is installable via nintendo's actual horizon OS so all they needed to do was make sig patches. You need to write a system module and a homebrew app to interact with that sys module. It's not as easy as you think.

I don't think calling people ignorant is going to score you any points.

Draxzelex does have valid arguments regarding NSP benefits, they just might not have the same weight for your particular usage (coming from an SX Pro user).

my concern with the whole XCI and NSP came from the fact that I purchased a bigger mSD card today and as I'm moving my XCI's over, it got me thinking about my "nintendo" folder and whether i can simply move it to the new mSD as it contains various installations that were installed via .NSP, would that make them corrupt because it's not the original card on which they were installed on.

The ease of management for me trumps many of the arguments made above (albeit valid), space saver and speed are a low priority as the speed gains are a few seconds in various scenarios.

 

[Philourer]

I haven't tinkered with my switch yet, but can't you use NSP with the certificate? It should work the same I assume. In the 3DS days, I prefer CIA over Gateway loading (I have a gateway card).
The only benefit of XCI/Gateway loading that I can think of you don't need to install it on your system, plug and play.

At the time I purchased SX Pro, that wasn't possible. Also, I'm a bit paranoid. If the xci truly looks like a cart that's inserted, the ban risk should be minimal. Having an xci loaded will block the Switch from seeing a physical cart that's inserted, that appears to be pretty good emulation. Now, if I convert my legit cart to nsp, but the Switch detects that I don't actually have it in, that's a ban risk. Try explaining to Nintendo how you were playing a MK8 cart online, but with a BotW cart inserted. I don't even inject certs from one game to another, they're all legit backups.

IOW, the risk of a ban using nsp is too high for me. The risk of a ban using xci is barely tolerable (even so, I haven't loaded an xci under 6.0 yet, waiting for SX OS 2.1 before attempting that). That's me, your risk tolerance may differ.

I should note, only one of the three hacked Switches has been allowed online recently, the other two are strictly offline and do have nsp installed. A fourth Switch has only seen Hekate long enough to perform a Nand backup, it's been 100% legit other than that.

 

[Draxzelex]

my concern with the whole XCI and NSP came from the fact that I purchased a bigger mSD card today and as I'm moving my XCI's over, it got me thinking about my "nintendo" folder and whether i can simply move it to the new mSD as it contains various installations that were installed via .NSP, would that make them corrupt because it's not the original card on which they were installed on.

As long as they are being used on the same console, you can just copy the Nintendo folder from your SD card onto any other SD card and it will work.

 

[Khar00f]

At the time I purchased SX Pro, that wasn't possible. Also, I'm a bit paranoid. If the xci truly looks like a cart that's inserted, the ban risk should be minimal. Having an xci loaded will block the Switch from seeing a physical cart that's inserted, that appears to be pretty good emulation. Now, if I convert my legit cart to nsp, but the Switch detects that I don't actually have it in, that's a ban risk. Try explaining to Nintendo how you were playing a MK8 cart online, but with a BotW cart inserted. I don't even inject certs from one game to another, they're all legit backups.

IOW, the risk of a ban using nsp is to high for me. The risk of a ban using xci is barely tolerable (even so, I haven't loaded an xci under 6.0 yet, waiting for SX OS 2.1 before attempting that). That's me, your risk tolerance may differ.

I should note, only one of the three hacked Switches has been allowed online recently, the other two are strictly offline and do have nsp installed. A fourth Switch has only seen Hekate long enough to perform a Nand backup, it's been 100% legit other than that.

I've never looked at the telemetry report myself, and many people find it "safer" to run XCI's over NSP's, here are my reservations on that argument.

You are running your switch in RCM, although i have not validated the following, if Nintendo tracks RCM loading, and they see that Horizon OS is running from RCM, they'll know something is up instantly, irrelevant on whether you loaded XCI's or NSP's. I think the only reason myself and others have not been banned yet even though we're online (WiFi active but no NNID, for me at least), is because i'd like to believe that the telemetry report only gets sent if you are logging to their online servers through your NNID (could be very wrong on this, but then i don't see why i'm not banned yet).

But I do believe SciresM mentioned in his extensive post about eshop, that they validate purchase at some point, which I think is where the info started spreading that NSP's are not as safe (in people's beliefs).

Right now there's so many Unknown's when it comes to BAN's, even myself I expect to be banned at anytime since i'm on WiFi but if it does happen, i'm OK with it, since this is my second switch specifically for that purpose, just like yours above, my legit switch has only seen hekate for a nand backup but i also did save backups using checkpoint. but so far no bans and all the games are original cartridges with a couple of eshop purchases.

 

[alantgw]

I mean I don't have anything against .XCI support; the more formats a CFW supports, the more options a user has. Although since we already have .XCI installation which shares the same detection as loading a .XCI, the implementation of raw .XCI loading is just to prove a point than offer it to users.

Maybe I am wrong but are you sure you mean which shares the same detection as loading a .XCI but not which shares the same detection as loading a .NSP?

May you provide the source for me to update myself if I am wrong?
What I mean is all sort of those cert stuff concerning the XCI but not found in NSP files.

 

[Draxzelex]

Maybe I am wrong but are you sure you mean which shares the same detection as loading a .XCI but not which shares the same detection as loading a .NSP?

May you provide the source for me to update myself if I am wrong?

Certainly. Unlike .XCI files, raw .NSP files typically need a ticket to be launched. These can be either real or fake; real ones are obtained by purchasing them from the eShop while fake ones are generated via CFW. Now you can just modify an .NSP file to no longer launch without a ticket so it functions like an .XCI but for the purposes of this argument, let's just stick to .XCI files. .XCI files are simply launched without modification since the Switch natively supports these; these are 1:1 copies of retail cartridges. However you can install a .XCI file into the USER partition similar to how .NSP files are installed and launch it from there.

What causes users to be banned for using .NSP files are not the .NSP files themselves (these are 1:1 copies of eShop games once installed) but the fake tickets used to install/launch them. Therefore, if you install anything that doesn't need a fake ticket, then Nintendo won't know that you're launching it using CFW (because it won't have a fake ticket).