TC encrypted disk unmountable after signature conflict (Win7x64)

Discussion in 'encryption problems' started by fluro2, Oct 4, 2014.

  1. fluro2

    fluro2 Registered Member

    Joined:
    Oct 4, 2014
    Posts:
    1
    The facts:
    1. drive is a Western Digital Desktop Elements 3 TB
    2. sizes 2'861'586 MiB (explorer device properties) = 732'566'016 sectors * 4'096 byte per sector (Hex Workshop direct disk access)
    3. device class GUID {4d36e967-e325-11ce-bfc1-08002be10318}
    4. base container ID {9919736a-d37f-579a-8bf8-4256d7bc128c}
    5. device instance path USBSTOR\DISK&VEN_WD&PROD_EXT_HDD_1021&REV_2021\574D43344E30393430323933&0
    6. install date 2014-06-14 12:21:40 (UTC)
    7. TrueCrypt 7.1a encrypted under Windows 7 x64

    I'm not so sure:
    1. I'm 90% sure that it's a whole disk encryption - and only 10% sure that it contained one partition. I always needed to manually mount it with TC, as auto-mount has reportedly not been supported for this device.

    What happened:
    1. I mounted several devices, all of them externals via USB, all of them were TC encrypted, almost all of them have one lone partition.
    2. Connecting another older device yelled a Windows warning (event #58, source "partmgr", message "The disk signature of disk 7 is equal to the disk signature of disk 4.") and as a result the disk management was showing the recently connected one as offline, while the troubled device was still working perfectly.
    3. I'm not entirely sure, but I think I just set the "offline" disk to "online" in the disk management - in the end I was able to successfully mount and access it.
    4. Later I dismounted the older disk and unconnected the drive gracefully. I was still able to work on my now troubled disk.
    5. Later I rebooted, which happens rarily (about once a month).
    6. After that I was unable to mount the disk. The disk management displays it with the red arrow down icon, type "unknown", being uninitialized (I never did that, even before encrypting it with TC) and the whole 2'794.52 GiB unassigned.

    What I know/did so far:
    1. Reading many threads I searched at disk offset 0x100000 (1'048'576 = sector 256) and yes: that's where random data is appearing, whereas sector 255 is full of zeroes. However, saving 2 MiB of data from that sector onwards as file and trying to mount it with TC still refuses my password.
    2. The end of the drive (sector 732'566'016) is full of zeroes. Data seems to end with (including) sector 730'827'182, as after that zeroes start. However, I cannot confirm that zeroes go up to the end - that would be 7'122'264'064 byte to check (I wonder that so many space should be left unused). Saving the last 128 KiB of that data before zeroes start and trying to mount it with TC also refuses my password.
    3. Using TestCrypt 0.5.1 with automatic start and end did not find TC volumes - currently I broadened the end part and it's still searching.
    4. Connecting the device to another PC (which at least means different USB ports) changes nothing - the same scenario awaits me.
    5. No, I don't have header backups.
    6. No, I haven't mirrored the entire disk yet (buying drives has become a nightmare in terms of quality and endurance), but of course I'll do that before I start any write action on my own (up until now everything was done in ROMode, of course).
    7. Sectors 0 to (including) 255 are not entirely zeroed: sectors 34 and 37 are full of random data, too. This bugs me - I expected either the whole 1 MiB to be empty or filled, not a mixture.
    8. The controller can't be the issue, as I'm obviously able to connect to the disk. However, as a last resort I can still break the case and connect the drive internally.

    Looks like the signature conflict was the culprit - or my actions afterwards on manually setting a disk to "online" in the disk management. But I'm unsure if Windows AUTOMATICALLY did something when the conflict was happening. Now I'm wiser: one can simply change the IDs to avoid all this nonsense.

    I hope someone still has ideas to throw in. Next step is to programatically check if after sector 730'827'182 everything else is zeroed.

    I'm using TrueCrypt for years now successfully and before that used SafeGuard Easy, which was also quite robust. Back then I even managed to escape a horrible scenario of a system encryption of a BSOD-booting Windows, where even a combination of booting SafeGuard Easy with BartPE did not work - but ultimately succeeded in rescuing all data. After almost 8 years this was supposed to happen sooner or later: so far I've lost 3 TiB of my ~33 TiB overall data.

    Thanks for reading. ;)
     
Loading...