Support XVDs with ResiliencyEnabled flag

[emoose]

Seems this flag is a recent-ish addition, wasn't seen in some older XVD utils/drivers at least.

Most hash block related functions check for this flag, and if set multiply their return value by 2 (XiComputeHashBackingBlockNumber, XiNumberHashPagesForLevel, XiNumberHashPages...), so it seems Resiliency probably allows for a second set of hash tables to be included in the XVD (reminiscent of the second set of hash blocks inside 360's STFS)

Unsure what makes this secondary hash-table get used instead of the primary, IIRC STFS had a field which would choose the tables to use (with that field being one of the last things to be written to the file), doesn't seem XVD has any field like that though, so maybe it depends on the top level hash instead?

xvdtool doesn't support files with this flag at all yet, adding support for reading them should be pretty straight-forward, but I'm uncertain about rehashing... will need to look into it some more.

[emoose]

Looks like hash blocks have a SequenceNumber at 0xFF0, seems xvdd compares this number to the next hash blocks SequenceNumber (0x1FF0), with the highest one being treated as the actual hash block? (seen in XiUpdateIntermediateHashPage)

AFAIK the SequenceNumber field in the XVD header is used as the next SequenceNumber in the hash blocks (see xrefs to XiUpdateIntermediateHashPage)

There's also some resilient-related fields at the end of the XVD header (0xFF4) which only seem populated in images with ResiliencyEnabled. XiRestartXvd seems to make heavy use of these fields, will have to look into it further (there's also XiPhysicalGetCheckpointOffset which returns a constant 0x1000, some ResiliencyEnabled files seem to have 0x10 bytes stored there, a hash?)
(those resilient-fields are also duplicated at 0x1FF4?)

Also XiVerifyResilientHashChain sounds interesting, gonna have to look into reversing that...

[tuxuser]

HashBlock counter sounds like it could relate to the way datatUnitNumber for HashEntries is calculate ?!

[emoose]

Hmm maybe, I think that 0xFF0 number only gets set for resiliency-flagged images though, but then again IIRC I did see some 0xFF0 / 0x1FF0 offsets being checked during crypto (before I knew what those offsets were for), probably worth checking out.