RBVR files extracting from wrong offset
PikminGuts92 opened this issue · 3 comments
Unfortunately, main_pc_1.ark is 60 bytes larger on-disk than internally stated from the HDR file. Therefore, files inside main_pc_2.ark and above are being extracted from the wrong offset.
I'm looking into it. It's a lot more complicated than that. RBVR files can be optionally "protected". The last 32 bytes identify the file as a protected file. Offset -36 from the file end has the size of the protection metadata. It's a simple streaming cipher so a simple decryption wrapper stream class similar to HdrCryptStream should do the trick.
Wow. It was a lot simpler than I thought. Will make a commit soon. Some very surprising stuff lives in main_pc_1.ark...
A note for future reference: "Marvel vs. Capcom: Infinite" uses the exact same file protection scheme as RBVR. It's unclear if this is middleware used by both studios or a weird case of ineffective-encryption plagiarism. Here are some strings for SEO:
mcnxyxcmvmcxyxcmskdldkjshagsdhfj
Data File Protection Enabled
addProtectedHandle internal memory reallocation
Handle: %p removed from manager
*! Protected file !* MetaDataSize = %08X
MetaData version is higher than the version in the base executable
We read the EOF %d vs %d
*! Reading from a protected file %d bytes!* metaData: %p
Decrypt Key: %08X
GetFileInformationByHandleEx_Hook: hFile: %p FileInformationClass: %d lpFileInformation: %p dwBufferSize: %08X
GetFileInformationByHandleEx_Hook: Removed MetaData size of FileInfo request
Hook_GetOverlappedResult: hFile: %p lpOverlapped: %p lpNumberOfBytesTransferred: %p bWait: %d
!* Asynchronous read finished on protected file *!
!* Fatal Error: Couldnt find async data *!
Async Read from non null offset, recalculating key
Fatal Error: Async read error
recalculated key: %02X
Hook_CreateFileW: File Open %s result: %08X
Error protected files cannot be opened in write mode
!* Asynchronous read on protected file detected, deferring decryption *!
getAsyncData: Hook_ReadFile