Hacking What's the challenge with the XCI loader?

[bundat]

the Tegra X1 (SoC) has a "publicly accessible" 3,000 page "Technical Reference Manual" (well, you need to have membership to the NVIDIA Developer Program to download it directly from developer.nvidia.com

Signing up to that was actually easier than I thought
Now I have full access to that doc

 

[Draxzelex]

is it done by the tool 'ZeroTwoXCI' by 2168-0002?

Yes, but there is another tool by the name of dOPUS which performs the same functions as the tool you're thinking about.

Usb installation? Im listening

We can load and install NSP's through USB? That's Awesome, since when?

I hope that means USB installs are close as well, would love to be able to use USB as storage.

Not load NSP files through USB but just install them without having to take out your SD card and put them on there. I'm not sure if the latest public build of Tinfoil has USB installation or if you have to use one of the semi-private builds that Adubbz distributed, but its possible. You also have to use the python script found under Tools on the GitHub page.

Also did I read you correctly when you said in your post about certs that you can change the flag of an NSP to tell the system that this NSP doesn't need to be validated?

.NSP files do not use certificates; they use tickets. However you can build an .NSP file without a ticket and then install/launch it without one installed.

 

[_hexkyz_]

Moral standpoints aside, no one will be able to replicate SX's XCI loading and distribute it as free open source software.
Not because of any technical hurdles or anything, but because it's flat out illegal.

TX reversed most of the gamecard protocol from the FS sysmodule and re-implemented it in their Loader KIP, hidden away inside a MIPS VM and a few layers of obfuscation. However, to achieve this, TX included sectors dumped from a real gamecard and the gamecard controller's certificate (which can be obtained by FS using a specific command). You can find these binaries by unpacking SX OS and searching inside the Loader KIP (simple hex editor will do) for "CERT" and "LOTUS".
Basically, any form of XCI loading requires heavily patching the FS sysmodule which can be quite a task if you want to support all firmware versions and what not. To avoid this, TX instead applies a single patch to FS which redirects gamecard commands to their MIPS VM. Then, code in their VM replies to the gamecard commands issued by FS with signed data ripped from a real gamecard.
After the authentication process has been forged, the VM is free to read data from the SD card and send it back to FS each time FS sends the gamecard sector reading command.

There are a few more details which I'm saving up for the writeup (SOON™), but that's the gist of it. A free solution will never be able to take this path for obvious reasons (instant takedown and lawsuits galore!), so a more complex approach will be necessary.

 

[synce]

I don't think morality or legality is the issue since it's not that hard to release stuff anonymously if you know what you're doing. More than likely it's an issue of skill and ego. Either no one has the skill, or they don't want to work on something they won't get credit for.

 

[Khar00f]

Moral standpoints aside, no one will be able to replicate SX's XCI loading and distribute it as free open source software.
Not because of any technical hurdles or anything, but because it's flat out illegal.

TX reversed most of the gamecard protocol from the FS sysmodule and re-implemented it in their Loader KIP, hidden away inside a MIPS VM and a few layers of obfuscation. However, to achieve this, TX included sectors dumped from a real gamecard and the gamecard controller's certificate (which can be obtained by FS using a specific command). You can find these binaries by unpacking SX OS and searching inside the Loader KIP (simple hex editor will do) for "CERT" and "LOTUS".
Basically, any form of XCI loading requires heavily patching the FS sysmodule which can be quite a task if you want to support all firmware versions and what not. To avoid this, TX instead applies a single patch to FS which redirects gamecard commands to their MIPS VM. Then, code in their VM replies to the gamecard commands issued by FS with signed data ripped from a real gamecard.
After the authentication process has been forged, the VM is free to read data from the SD card and send it back to FS each time FS sends the gamecard sector reading command.

There are a few more details which I'm saving up for the writeup (SOON™), but that's the gist of it. A free solution will never be able to take this path for obvious reasons (instant takedown and lawsuits galore!), so a more complex approach will be necessary.

Interesting, thanks for shedding some info on the topic

 

[Krenogin]

TX has teleported into the future and stolen the xci loaders code from someone else!!!!

Ps yes you can update xci files. If you couldn’t how would you update a cart normally???

 

[Philourer]

TX has teleported into the future and stolen the xci loaders code from someone else!!!!

Ps yes you can update xci files. If you couldn’t how would you update a cart normally???

You don't update a cart, if you did, then why do you need to update it again when used on a second console? Carts are read-only. If a game has an update, new carts could be made that have the updated files, but any old carts will forever need a downloaded update.

Edit: Ok, had my morning caffeine. The Switch sees an xci as a cart, so the process of updating is the same. I read it as saying you can update the xci itself, same as a cart, which is not correct (you don't update a cart, you install an update for the cart, that's the difference). I'll leave my original response for posterity (of my inept reading comprehension).

 

[Krenogin]

You don't update a cart, if you did, then why do you need to update it again when used on a second console? Carts are read-only. If a game has an update, new carts could be made that have the updated files, but any old carts will forever need a downloaded update.

Edit: Ok, had my morning caffeine. The Switch sees an xci as a cart, so the process of updating is the same. I read it as saying you can update the xci itself, same as a cart, which is not correct (you don't update a cart, you install an update for the cart, that's the difference). I'll leave my original response for posterity (of my inept reading comprehension).

Yes, you download and update just like a NSP, runs the update files from the SD or NAND.

 

[Philourer]

Yes, you download and update just like a NSP, runs the update files from the SD or NAND.

Right. I was reading the post as stating you could update the xci file directly. Like slipstreaming updates in a windows install disc. My response was technically accurate, but I was arguing against a point no one made.

 

[DocKlokMan]

Moral standpoints aside, no one will be able to replicate SX's XCI loading and distribute it as free open source software.
Not because of any technical hurdles or anything, but because it's flat out illegal.

TX reversed most of the gamecard protocol from the FS sysmodule and re-implemented it in their Loader KIP, hidden away inside a MIPS VM and a few layers of obfuscation. However, to achieve this, TX included sectors dumped from a real gamecard and the gamecard controller's certificate (which can be obtained by FS using a specific command). You can find these binaries by unpacking SX OS and searching inside the Loader KIP (simple hex editor will do) for "CERT" and "LOTUS".
Basically, any form of XCI loading requires heavily patching the FS sysmodule which can be quite a task if you want to support all firmware versions and what not. To avoid this, TX instead applies a single patch to FS which redirects gamecard commands to their MIPS VM. Then, code in their VM replies to the gamecard commands issued by FS with signed data ripped from a real gamecard.
After the authentication process has been forged, the VM is free to read data from the SD card and send it back to FS each time FS sends the gamecard sector reading command.

There are a few more details which I'm saving up for the writeup (SOON™), but that's the gist of it. A free solution will never be able to take this path for obvious reasons (instant takedown and lawsuits galore!), so a more complex approach will be necessary.

Could that solution be used if paired with the requirement that the user needs to dump their own sector data from a game card? Like, include everything up to the game card sectors? It would obviously need to come with a homebrew capable of doing that or does the type of dumping needed require specialized hardware or tools?

 

[InvisibleH8]

• 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)

XCI's can be built to include all DLC and Updates. This makes having very large amounts of games easier, especially with a large EXT HDD and multiple switch's. You don't need to install anything to the system or SDMC whatsoever, one file, everything included.

You can pack multiple games into a single file, it will also downgrade firmware requirements.

NINTENDO SWITCH CLEANER AND BUILDER
https://gbatemp.net/threads/nsc_bui...lder-game-updates-dlc-in-a-single-xci.522486/

 

[FR0ZN]

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.

Is there any way to check if I have a clean NAND dump? I have one, but i don't remember if I first installed a NSP file to see how all the jazz works - or if I was smarty enough to create backup first and THEN install a NSP file.

There has to be some sort of record that the Switch keeps correct?

 

[Draxzelex]

Is there any way to check if I have a clean NAND dump? I have one, but i don't remember if I first installed a NSP file to see how all the jazz works - or if I was smarty enough to create backup first and THEN install a NSP file.

There has to be some sort of record that the Switch keeps correct?

Well if you installed a .NSP file before you backed up the NAND, when you restore the NAND and see that .NSP file installed on the home menu, you know the NAND is tainted. But otherwise the only other way to tell if a NAND is not clean is by restoring it and checking if you're banned. The console doesn't know the difference between a clean and dirty NAND.

 

[huma_dawii]

Piracy hypocrisy. Sad honestly.

 

[Clydefrosch]

Piracy hypocrisy. Sad honestly.

Man... that's seriously deep.
Do you have a livejournal I can follow?

 

[huma_dawii]

Man... that's seriously deep.
Do you have a livejournal I can follow?

lol

 

[FR0ZN]

Well if you installed a .NSP file before you backed up the NAND, when you restore the NAND and see that .NSP file installed on the home menu, you know the NAND is tainted. But otherwise the only other way to tell if a NAND is not clean is by restoring it and checking if you're banned. The console doesn't know the difference between a clean and dirty NAND.

As far as I know there was something like a database on the 3DS where the console kept track ob every cia ever installed or something like that. Even when you uninstalled the cia or did a factory restore on the 3DS, this specific database was never flushed.
Maybe someone knows what I'm talking about and can confirm this.

Should this be true what I'm saying, I'd be surprised if Nintendo wouldn't do the same on the Switch.

 

[Draxzelex]

As far as I know there was something like a database on the 3DS where the console kept track ob every cia ever ibstalled or something like that. Even when you uninstalled the cia or did a factory restore on the 3DS, this specific database was never flushed.
Maybe someone knows what I'm talking about and can confirm this.

Should this be true what I'm saying, I'd be surprised if Nintendo wouldn't do the same on the Switch.

Well the 3DS isn't the Switch so making assumptions based on previous consoles is already a bad idea. But each .NSP file you install into the console gets its own ticket which you can check with the homebrew application Tinfoil.

 

[Absintu]

Piracy hypocrisy. Sad honestly.

This

 

[Khar00f]

As far as I know there was something like a database on the 3DS where the console kept track ob every cia ever installed or something like that. Even when you uninstalled the cia or did a factory restore on the 3DS, this specific database was never flushed.
Maybe someone knows what I'm talking about and can confirm this.

Should this be true what I'm saying, I'd be surprised if Nintendo wouldn't do the same on the Switch.

there is what is called Telemetry data on the console itself, that keeps track of pretty much everything that you do on your switch. if you factory reset that report remains, there are ways to wipe but calls for almost an instant ban as you break the natural sequence if it and it flags nintendo when they check it.

That's why the only way to really be safe is to have a clean NAND and restore before doing online activity. An NAND restore everything from the point of the backup, including the telemetry report.