Hacking Misc Getting the MIG Switch to load an XCI dump without its original Initial Data

[cavv]

Hello guys, this is my first post here! I just got a MIG Switch card out of curiosity and I was tinkering with it.
For those who don't know, it's used by placing XCI dumps as well as other game specific bin files in the sd card of the MIG Switch, and are obtained from the original cartridge by using an app like nxdumptool.
Two of these bin files are mandatory to get the game to boot: Initial Data.bin and Certificate.bin. They stay the same for every cartridge of a specific game.
Now, if you want to use an XCI dump from a shady website it's impossible to get it to work without those files. By using the Certificate.bin from another game it has no problem, but this does not count for the Initial Data.bin. So I looked for a way to obtain this Initial Data from an XCI file and read a bit of the XCI file documentation from switchbrew dot org.

Here's what I understood so far:
The Switch checks if the cartridge is valid by doing a challenge–response authentication on the Initial Data.

The Package ID is contained both on the XCI and the Initial Data, on positions 0x110 and 0x0 respectively.

The Initial Data hash is on the XCI at position 0x160. It is calculated by doing a SHA-256 hash on the full Initial Data content.

So I was wondering, is there a way to to construct a functional Initial Data file starting from an XCI dump?
I also tried a reverse approach by editing the Package ID in the Initial Data from another game, generating the Initial Data hash and putting it in the XCI file but is not enough to get the Switch believe it's a real game.

Sorry if this may seem stupid but let me know what you think.

 

[pharrowking]

i spent alot of time. about 3-4 days testing what you're asking with a partner, and it does not work. the data from initial data thats found within the xci is signed.

according to this structure the signature of signed data is stored in 0x0 to 0x100 of the xci cardheader,
the signed data is everything after: 0x100 to 0x200

CardHeader​

Offset	Size	Description
0x0	0x100	RSA-2048 PKCS #1 signature over the header (data from 0x100 to 0x200)
0x100	0x4	Magic ("HEAD")
0x104	0x4	RomAreaStartPageAddress (in Gamecard page units, which are 0x200 bytes)
0x108	0x4	BackupAreaStartPageAddress (always 0xFFFFFFFF)
0x10C	0x1	TitleKeyDecIndex (high nibble) and KekIndex (low nibble)
0x10D	0x1	#RomSize
0x10E	0x1	CardHeaderVersion
0x10F	0x1	#Flags
0x110	0x8	PackageId (used for challenge–response authentication)
0x118	0x4	ValidDataEndAddress (in Gamecard page units, which are 0x200 bytes)
0x11C	0x4	Reserved
0x120	0x10	Iv (reversed)
0x130	0x8	PartitionFsHeaderAddress
0x138	0x8	PartitionFsHeaderSize
0x140	0x20	PartitionFsHeaderHash (SHA-256 hash of the #PartitionFsHeader)
0x160	0x20	InitialDataHash (SHA-256 hash of the #InitialData)
0x180	0x4	#SelSec
0x184	0x4	SelT1Key (always 2)
0x188	0x4	SelKey (always 0)
0x18C	0x4	LimArea (in Gamecard page units, which are 0x200 bytes)
0x190	0x70	#CardHeaderEncryptedData

changing the data at any point will result in the switch unable to read gamecard.

including using a loaner xci and cloning its entire header to a different xci dump. without the signing keys that was used to sign the cardheader, your out of luck. unless those keys can be found on the switch....im not sure.