, even with the latest keys and the required v20.0.1 firmware. Oddly, the title key still gets written to title.keys_autogenerated but only an empty log file is created.
However, one can simply use
Working with NSPs and their contents requires the appropriate tool but that has become harder to aquire these days.
The original hactool fails to handle newer titles because it has not been maintained for years and was practically
that "just work" and offers some nice extra features.
Update NSPs contain the universal certificate, a (forged) ticket with the title key, and one each of multiple NCA types. There are also delta fragments but those are not used by the available public tools, which is likely why SUXXORS has not included any after their v2.0.2 patch.
Here is an example for Scarlet v4.0.0:
Code:
50cea82f20b8745b60d270d141b08c90.cnmt.nca Meta
356eb446eaa0c8a00e4589ed7ead4e6b Control
ca150f6feadd055989f0d69f68e84338 LegalInformation
e54425dad4121e196ea8263c5ee5ece4 HtmlDocument
7e5b9bbfe2e72e23a63d42bcba9a2e3b Program
with information such as the title ID, the internal version (786432), the required firmware, and what the other NCAs are used for.
Control includes one icon for each supported language to be shown on the home menu as well as an
file that stores the game title, version string (v4.0.0), age ratings and whether video capture is allowed, among other things.
LegalInformation has the third-party software license information and support links shown when selecting the game and pressing + or -.
HtmlDocument is just a
Program is the largest one by far and contains the actual game data in its ExeFS and patch RomFS.
The first three can be extracted without issue as usual but none of the tools listed above are able to extract HtmlDocument. Hactool quits because of an invalid
layout, hac2l warns about failing to open raw NCA section 0 then quietly exits instead of printing the section data, hactoolnet throws a ResultFsInvalidArgument error, while nstool just crashes. This problem seems to be
and the latest build of nxdumptool successfully decrypts HtmlDocument from the installed update on hardware.
Since this NCA does not hold important data and NSP files (PFS0) are just a very simple file container, the former can be omitted by repacking the latter with a custom script. Unfortunately, the resulting file leads to the same emulator crash as above because the Program NCA is also affected. Removing that too would make the NSP not only useless but also cause the installation to fail with the log file warning about NSP corruption because the two removed NCAs are still listed in the CNMT.
Alternatively, one can manually install the update by extracting it and moving the NCAs to the
# requirements
# Pokemon_Scarlet_Update_v4.0.0_NSW-SUXXORS
# https://www.7-zip.org/download.html
# https://github.com/SciresM/hactool
# extract scene release
7z e -so Pokemon_Scarlet_Update_v4.0.0_NSW-SUXXORS/sxs-pokemon_scarlet_v786432.rar > u.nsp
# dump NSP
hactool -t pfs0 --outdir tmp u.nsp &> /dev/null
rm u.nsp
# set emulator path for Linux AppImage
nand=~/.local/share/yuzu/nand/user/Contents/registered
# install NCAs
# NCAID = lower-case SHA-256(NCA)
# XX = upper-case first byte of SHA-256(NCAID)
mkdir $nand/000000{76,0C,A7,55,90}
mv tmp/50cea82f20b8745b60d270d141b08c90.cnmt.nca $nand/00000076/50cea82f20b8745b60d270d141b08c90.nca
mv tmp/356eb446eaa0c8a00e4589ed7ead4e6b.nca $nand/0000000C/
mv tmp/ca150f6feadd055989f0d69f68e84338.nca $nand/000000A7/
mv tmp/e54425dad4121e196ea8263c5ee5ece4.nca $nand/00000055/
mv tmp/7e5b9bbfe2e72e23a63d42bcba9a2e3b.nca $nand/00000090/
rm -r tmp
Doing this with all five then deleting the cache directory to trigger a rebuild shows v4.0.0 in the game list. But this is only cosmetic and launching the game simply loads v1.0.0 from the cartridge because unlike the metadata NCAs the problematic two use title key encryption. Writing the rights ID and title key to title.keys_autogenerated, or just re-using the previously generated one, causes the same crash as above, though the log file does get created this time because the assert implementation takes too long. The emulator
but this check fails due to the recent BKTR changes. Removing the HtmlDocument NCA leads to termination without log file exactly as before, which confirms that all along the Program NCA was the main issue for reasons that will become apparent shortly.
Before giving up and finally doing the only proper fix by porting
. Only Program needs to be extracted since the metadata NCAs work fine and HtmlDocument was already processed earlier.
All programs are able to handle the ExeFS except for hactool because its old version
and complains that it has an invalid layout as above. This happens again for the RomFS, which hac2l also cannot extract as it fails to open the first section of the NCA. Both hactoolnet and nstool work fine, though the former warns about an incorrect master hash for section 1 despite that passing the validity check. It is also odd that any of the PC tools are able to process the RomFS in the first place because none of them were updated yet to account for the recent BKTR changes.
But who cares about any of that since all extracted files match those decrypted on hardware with nxdumptool.
Just to make sure, the Program NCA of the previous Scarlet v3.0.1 update is parsed with hactoolnet as a sanity check, which finds something interesting: This time there is no warning but the master hash itself is the same as in the latest version. Comparing both updates leads to the most important revelation: The ExeFS and RomFS files of v3.0.1 and v4.0.0 are identical!
Relevant IDs extracted from the scene releases for all twelve versions of
The following updates have been made when playing the game on Nintendo Switch 2:
General
- Visuals: Optimized for the Nintendo Switch 2 display and high-resolution TVs for improved image quality.
- Frame rate: Improved for smoother movement on Nintendo Switch 2.
are the same.
Of course the scene group simply could have failed to dump the patches correctly, but the included NCAs matching their SHA-256 hashes listed in the signed CNMT disproves this theory.
Taking a look at other NSW2-related releases shows that there are two types of updates.
The first one also makes changes to the game data used on NSW. For example, Splatoon 3 v10.0.0 includes multiple new files with Crank in their name, which is
. Extracting and converting UI/Icon/StageBanner/Vss_Crank.bntx.zs shows the expected stage banner.
In contrast, the second one does not touch the shared(?) game data itself and only adds NSW2 code and assets, though these are probably split to separate NCAs listed in a different CNMT to prevent leaking their contents. This means that NSW users must re-download the exact same update without any benefit to them, just to have version string parity with NSW2 required for online play, as is the case with these Pokémon games and actually many more.
Although only enhanced titles are listed
. The majority of all these patches have identical ExeFS and RomFS contents compared to their previous versions, which makes them a complete waste of time and bandwidth on NSW.
All games obviously run on a console with the required system firmware and quickly updated CFW installed, but proper emulator support lags far behind.
Eden's developers fixed the installation crashes on
.
In the three months since those had been released, the best workaround the developers could come up with was to entirely disable NCA verification by default to get only some of the titles to boot, since the main issue had shifted from a container format change to games using functions added in newer firmwares. This was merged
was not tested because it crashed repeatedly in-game even with the previous update and that emulator also has some annoying quirks due to questionable design choices.
To conclude: For Pokémon in particular, just stay on v3.0.1 since it works fine in yuzu/Eden and has identical files. It does not make sense to jump through hoops to use v4.0.0 for a purely cosmetic version string that is not even displayed in-game.
On a related note, you may have noticed in the paste linked above that both Scarlet and Violet have the same RomFS hash for each version. That is because they always use identical data files, causing twice the download size for what is essentially the same game.
PCDOX updates are distributed as delta patches that are applied to the installed game files to bring them up to date, but NSW updates are handled very differently. A patch is created from the base title's RomFS to a new one made from the latest game files, which gets combined with the full ExeFS to a Program NCA. That is then distributed and saved to the SD card
and gets temporarily applied transparently on game launch. This is the reason why properly accessing an update's data files with something like hactool always requires the base RomFS while the ExeFS can be extracted without it.
On PC multiple small changes to a game would be released as a few delta patches (official or self-made) that drastically reduce the total download size but depend on the previous version. In contrast to that, NSP files are cumulative, meaning that only the latest one need to be installed, because they always contain the full difference to the original RomFS. If the publisher cheaps out on the cartridge and moves the majority of game files to a patch, that is multiple times the size of the base, the total data volume can get rather ridiculous.
This would be less of a problem if public tools used the officially provided DeltaFragment NCAs instead of simply ignoring them. Some are just dupes of the other metadata NCAs but the large ones contain NDV0 files that are basically delta patches.
For example, instead of including the full 2.9 GiB Program NCA in the v2.0.2 update for Scarlet again, the one from v2.0.1 could just be patched directly with the 64 MiB delta fragment which would obviously save a massive amount of space and bandwidth, doubly so because the same is true for Violet, as explained above: