why would this not verify, is it something to be worried about maybe, could it be because it was a xci converted to an nsp. 3 different nsp from same source (safe source as far as I can tell) report like this
4nxci and RenXpack files aren't verifiable\restorable, this is because they change signatures, which is something that was added so acid patches weren't needed. Right now hekate can patch it which was the only cfw payload\booter that didn't enable it, and kosmos recommended patches include that patch, so no need to keep modfying that onfile.
Currently it redoes the signature2 public and private pair. The issue here is you need to redo the internal hashes so the header changes and signature1 won't be able to match with the header.
Signature1 is really important because unlike signature2 that has the public rsa pair you use to verify it stored in the npdm section (which allow to create a new public key) has the ublic key on the switch itself. Also only program ncas has signature2.
Ok so all nca have the signature1. This is a rsa signature which is made with a public and private key pair. The public key is in the console and in NSCB code, this allow to verify the signature. The signature is made using the private key to sign the header, the private key is only known by Nintendo and since is a rsa key you'll need many years or compute power to figure it out.
This means it will tell you if the content is legit since only Nintendo can sign it and any modification will made the signature not to match.
Now how NSCB matches it against it's modifications? Basically i restore the header, i can figure out keygeneration changes, isgamecard changes, titlerights removval, and rsv changes because they're small changes so i can make some iterations to figure out the original state.
That's why it tells you titlerights were removed, keygeneration was changed from A to B, etc... So basically is a way to know your content is fully secure and a way to know is restorable. The restoration mode uses the same concept and restore back the ncas to it's original state.
It will happen the same with unlockers and hacpack ncas since they're files made by the community.
Now it does't mean those files are bricks, just that they can't be verified. If you make them yourself you don't have to worry, same as if you trust who made them but only the first test level will work with them.
--------------------- MERGED ---------------------------
For splitting I just set FAT32\EXFAT options (9) to FAT32 for SX OS (2), then I built a split XCI using MULTI-PACK mode (2).
My source XCI was Luigi's M3 including the UPD, verified good, built with NSCB.
Ok, i'll test and see what can be the issue. Truth be told multimode is the trickiest for this since it takes several inputs and goes nca by nca, is kinda the function that has more complex code.
My guess is the file wasn't properly written at the split point which something that happened before with that function in particular but was supposedly fixed some versions ago. I thought you were splitting already made cxci with the mode 1.