Data Sectors for Symwave

Per contribution guidelines, submitting reference data files for Symwave-based drives. These are binary images of the key sector from my personal drive, along with the first two leading sectors. Two variants of each are included in the zip file attached:

keyblk-straight.img is the raw key sector, as extracted directly from the drive.
keyblk-reversed.img is a "corrected" version of the key sector. See below.
header-encrypted.img contains the drive's first two sectors, as read directly from the drive.
header-decrypted.img contains the decrypted form of the same two sectors.

I was fortunate enough to be able to get a decrypted version of the MBR and several of the following sectors while the bridge was still at least somewhat functional. This should, I hope, prove useful for comparison. I also noted that the raw key sector, extracted directly from my drive, did NOT quite match the form of the version recently published. Specifically, whereas the published sector begins with the letters, 'SYMW', I found them in reverse order in mine: 'WMYS'. Suspecting a big/little-endian issue, I played a hunch, and came up with a version that flips around each set of four characters. Rather than force you to do the same (simple as that might be), I went ahead and saved a "corrected" version of the key sector, along with the original.

I believe this reversal is a correct operation, based on results obtained in my own tests. In the paper recently published, the Symwave analysis discusses the presence of two data encryption keys (DEKs), the second of which 'unwraps' to a string of zero bytes. I believe this is by design, perhaps a form of error check. Testing against my own corrected key sector obtained the same result: the second DEK unwrapped to a string of nulls. That this should come by chance seems to me highly unlikely, enough to suggest that the process I've employed is almost certainly correct.

That said, I believe there must be at least one more stage in the decryption process. While I have not yet attempted to decrypt or encrypt either leading sectors in their entirety, I HAVE tested the first DEK against a 16-byte block of nulls. You may note the presence of several such blocks in both forms of my leading sectors, in fact, this is why I included the sector immediately following the MBR. Its raw form on disk is completely zeroed, which the bridge "decrypts" into a block of apparent gibberish, albeit patterned gibberish. Likewise, several blocks of zeroes are found in the decrypted MBR, which may be readily mapped to similar patterns in the encrypted form. What I've found, however, is that neither of these patterns correspond to either an encryption or decryption of a block of zeroes using my unwrapped DEK. I'm certain there has to be another step involved to obtain the correct key.

With that in mind, I would like to call your attention to another part of the key sector. Following the wrapped keys, the sector is almost entirely zeroes, however, there is one more strip of data near the end. It starts around byte 448 (0x1c0), if you go with the reversed sector. It's not very long, but I suspect the data there indicates some sort of additional processing required to obtain the final key. Maybe you'll see something in the firmware. Here's hoping, at least.

[symwave.zip](https://github.com/andlabs/reallymine/files/85250/symwave.zip)