File Share Encryption

Hi,

I am using PGP Desktop 10.1.2 on a Windows 7 x64 SP1 system and am having the problem described here. This happened suddenly and with no warning.

https://www-secure.symantec.com/connect/forums/encrypted-disk-not-recognized-windows

I can authenticate to my WDE disk but PGP's driver presents encrypted data to windows, resulting in a message from windows about "need to format the disk in drive..." after enterinng the passphrase. I have viewed the raw volume data in winhex and can see that the data presnted to windows is clearly not decrypted despite successful authentication.

Please can someone from PGP advise how me to decrypt the drive? I dont want to run recover or decrypt commands as this will leave me with a drive full of encrypted data just like the original poster! I have bronze support, is it possible to log a formal support case?

useful output:

pgpwde --status --disk 2
Disk 2 is instrumented by bootguard.
Current key is valid.
Whole disk encrypted
Total sectors: 1953520064 highwatermark: 1953520062 reserved start sectors: 2
Request sent to Disk status was successful

You may need to attempt decryption by either attaching the disk to another computer with PGP installed, or by use of the PGP WDE Recovery CD. 

My understanding is that Bronze support does not include the formal support case.

Hi Tom,

Thanks for the quick reply - at a weekend too! I am aware of the recovery cd and decrypt commands but am concerned that because PGP doesnt realise its decrypted data being presented to windows is incorrect it will just trash the disk during decrypt, this is seemingly what happened to the original poster. It is strange that PGP accepts the passphrase fine and authenticates ok but seems unable to decrypt the disk.

I am quite technical - are there any commands I can run that may help further diagnose the state of the disk? I also have access to sector viewers/editors  for inspecting on disk data structures . I 'd prefer to understand what is wrong before I start an operation (e.g. with the recovery cd) that can't be interrupted or stopped and may trash the disk!

Regards,

Achelon

I'm not aware of them, but if they do exist, someone else may be able to help you with them.

Hi Tom,

In case it helps PGP... after significant technical analysis I think I have determined what has occured.

I have 2 WDE external drives exhibiting the same symptoms, Drive A and Drive B. Both external USB drives.

There's some kind of bug and PGP has synchronised the BGFS records for Drive A to Drive B and the records from Drive B to Drive A!  I do not always keep my drives connected 100% of the time and I imagine some hapless piece of code has lost track of which drive was which.

This leaves both drives in a trashed state. Authentication works fine but the decrypted session key is from the wrong disk, so PGP cannot decrypt the disk. This is consistent with observed symptoms where PGP authenticates but cannot decrypt anything. I think recovery is possible here as I have found the location of the original BGFS records using search of all sectors on the drive for the string "BGFS". I should just need to alter the stage 2 start sector pointer in sector 0. When I have more technical information I will update this post in case it helps anyone else who suffers this unfortunate mishap.

Achelon

Very interesting.  Hope you are able to resolve this - posting your work and results would be appreciated.

Hi Tom,

After an effort I have recovered both my drives and have started decrypting them through the UI. In case it helps anyone here are the technical details of what I did.

Firstly I searched the entire drive for the text "BGFS" and used sector viewer tools to understand the drive state and where the records are stored. I had a copy of the source code and reviewed that to determine how PGP stores it's BGFS records. I was able to determine what drive the records were supposed to be for by examining the usrrec and usrrec1 parts of the stage 2 data block which contain the drive name e.g.  "WD 5000AAV External USB Device". The drives in their trashed state looked like this:

Drive A

MBR (Drive B)

BGFS Backup (Drive B)

- Pointed to by address at offset 0x41 in the MBR

BGFS Primary (Drive B)

- Pointed to by address at offset 0x42 in the MBR

BGFS Primary (Drive A) 

- Not pointed to by anything anymore

Drive B

MBR (Drive A)

BGFS Backup (Drive A)

- Pointed to by address at offset 0x41 in the MBR

BGFS Primary (Drive A)

- Pointed to by address at offset 0x42 in the MBR

BGFS Primary (Drive B) 

- Not pointed to by anything anymore

At this point I decided to fix Drive A by copying the first ~10kb of Drive B to Drive A, this gives Drive A the correct MBR and replacing the incorrect BGFS backup records with ones appropriate for Drive A.  Drive A now looked at this:

Drive A

MBR (Drive A)

BGFS Backup (Drive A)

- Pointed to by address at offset 0x41 in the MBR

BGFS Primary (Drive B)

- Not pointed to by anything anymore

BGFS Primary (Drive A) 

- Not pointed to by anything anymore

Unfortunately this didnt fix it. In fact, PGP went into a strange state where it would prompt for authentication and seemingly accept any passphrase - but the 'decrypted' data was all completely random and clearly not decrypted. At this point I'm not sure why the backup records werent working, I think I should also have copied across the lvbitmap data and not just the usrrec file in stage 2 but because I had located the original BGFS records (which had not been overwritten because both drives had their records at different points) I decided to force PGP to use these instead.

I wrote 0x00 to offset 0x41 in the MBR of Drive A to cause PGP to think its BGFS backup records were destroyed. I then altered the stage 2 start sector pointer at offset 0x42 in Drive A's MBR to point to the start of the original Stage 2 [BGFS Primary (Drive A)  ]. A careful read of stage1.h and stage1.S in PGP source code gives clear info on the structure of the MBR and the location/format of the stage 2 start sector pointer.

After altering the pointer Drive A looked like this:

Drive A

MBR (Drive A)

BGFS Backup (Drive A)

- Not pointed to by anything anymore (because of overwriting the pointer in the MBR with 0x00)

BGFS Primary (Drive B)

- Not pointed to by anything anymore

BGFS Primary (Drive A) 

- Pointed to by address at offset 0x42 in the MBR

Happily PGP could authenticate and a similar process worked for recovering Drive B. After spending hours deep in source code and hex from the disk sector viewer/editor, I had pretty much had as much fun as I could stand!

Hope it helps, to try reproducing this, hook up 2 PGP WDE encrypted drives to usb and try unplugging and plugging in each one whilst the other is connected. I think I possibly didn't do the safe removal and just unplugged one without safe eject so maybe that is what screwed PGP up and confused it into writing the wrong records to both drives.

Achelon

[edited to fix typos]

Impressive work!  I sent this on to Technical Support in case it may be helpful to them.

Hi Tom,

Thanks. I hope PGP is able to fix that bug as PGP WDE is a nice product really. Btw, I saved the first raw 10kb of both drives in their initial messed up state to 2 bin files, if PGP want to see them let me know and i'm happy to share if it will help them understand this further.

Regards,

Achelon