Talk:XCI

From Nintendo Switch Brew
Revision as of 01:13, 7 April 2021 by DarkMatterCore (talk | contribs) (Created page with "== CardInfo UppHash value == I have successfully decrypted the <code>CardInfo</code> area from a personal gamecard dump retrieved through my own application ([https://github....")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

CardInfo UppHash value

I have successfully decrypted the CardInfo area from a personal gamecard dump retrieved through my own application (nxdumptool). The AES-CBC key for this area was manually retrieved from a FS process memory dump at runtime, much like vanilla Lockpick used to work.

The wiki page mentions that the UppHash field represents the SHA-256 checksum from UpdatePartition - the question is, how is this checksum calculated? I have tried to use different start offsets and sizes, and none of the generated SHA-256 checksums holds a matching byte sequence:

  • Hashing the full update partition (starting at the HFS0 magic word, and using the full partition size specified in the root partition).
  • Hashing the update partition without zero padding (starting at the HFS0 magic word, and ending right after the data for the last file entry).
  • Hashing the raw update partition data (starting right after the HFS string table, and using the full partition size *minus* the full HFS header size).
  • Hashing the raw update partition data without zero padding (starting right after the HFS string table, and ending right after the data for the last file entry).

It's worth noting that all offsets and sizes are page-aligned. The start offsets for both the partition header and raw partition data are always page-aligned, and the partition size without zero padding is also page-aligned.

I have no actual use for this information - it's just something I'd like to comprehend and document, if possible. Thanks in advance. DarkMatterCore (talk) 01:13, 7 April 2021 (UTC)