Inability to erase files on an encrypted virtual drive.

S

Sirim

New Member
I am using eraser 6.0.9.2343 (05 November 2011). My operating system is Windows 7 Home Premium (64 bit).

Every time I attempt to erase files on a virtual encrypted drive created and mounted using FreeOTFE, I receive the following error:

Error The file or directory is not a reparse point. (Exception from HRESULT: 0x80071126)

I assume the problem is that it's a virtual drive and that eraser is not able to erase the data within the volume file just by being given a pointer referring to the location within the virtual drive (that the volume is mounted as).

Is there a way of successfully erasing files on a virtual encrypted drive?

Any thoughts much appreciated.
 
TrueCrypt works, though I've not tried FreeOTFE. I will have a go at it later today.
 
Ouch, their drivers aren't signed. I'll need to set up a test virtual machine since my main computer is running Windows 7 64-bit.
 
Thanks for taking a look at it, Joel.

The reason I chose FreeOTFE over TrueCrypt is that I initially thought I may want to create multiple hidden volumes within a single container. I may have to switch over at some point though, as the developer of FreeOTFE seems to have stopped updating it.

I run FreeOTFE just fine on Windows7 64 bit. The method I use is the recommended one (number 3) on this page: http://www.freeotfe.org/docs/Main/impac ... igning.htm .
 
Sirim said:
I run FreeOTFE just fine on Windows7 64 bit. The method I use is the recommended one (number 3) on this page: http://www.freeotfe.org/docs/Main/impac ... igning.htm .
Click to expand...
I know that works (because I did attempt some kernel driver development previously - but gave up) but I'm of the (paranoid) opinion that we shouldn't deliberately disable software safeguards to let software work... so I'd rather leave it all in a nice sandbox.
 
Joel said:
Sirim said:
I run FreeOTFE just fine on Windows7 64 bit. The method I use is the recommended one (number 3) on this page: http://www.freeotfe.org/docs/Main/impac ... igning.htm .
Click to expand...
I know that works (because I did attempt some kernel driver development previously - but gave up) but I'm of the (paranoid) opinion that we shouldn't deliberately disable software safeguards to let software work... so I'd rather leave it all in a nice sandbox.
Click to expand...

Okay. FreeOTFE is completely open source, though.

Just out of interest, would you have allowed the drivers if you'd been using a 32bit version of windows (where enabling testmode is not required, you just need to click 'okay')? As far as I know, there is no increased security risk posed by running unsigned drivers in 64 bit windows as opposed to 32 bit windows. If you would allow the same drivers on a 32 bit system, but not on a 64 bit system (in the name of security), isn't there a consistency issue? If with 32 bit windows you would insist on setting up a vm as opposed to clicking on the allow button, then fair enough.

Ignore the above if you want. Thanks again for looking into the issue.
 
Sirim said:
Okay. FreeOTFE is completely open source, though.
Click to expand...
Haha, I'm perfectly fine with letting FreeOTFE run in my kernel. I'm just having the paranoid fear that lowering my guard increases my risk exposure to malware.

Sirim said:
Just out of interest, would you have allowed the drivers if you'd been using a 32bit version of windows (where enabling testmode is not required, you just need to click 'okay')? As far as I know, there is no increased security risk posed by running unsigned drivers in 64 bit windows as opposed to 32 bit windows. If you would allow the same drivers on a 32 bit system, but not on a 64 bit system (in the name of security), isn't there a consistency issue?
Click to expand...
I wouldn't allow unsigned drivers to run on any production system. Not getting Microsoft to countersign a driver just raises red flags for me.

Sirim said:
If with 32 bit windows you would insist on setting up a vm as opposed to clicking on the allow button, then fair enough.
Click to expand...
I still would :) I'll look into the issue when I've got my test machine set up.
 
The problem does seem to stem from the way FreeOTFE declares drives to the system.

FreeOTFE will create a Windows NT device, but it does not inform the system that it is plugged in as a hard disk. It tells the system that there's a new drive letter F: or G: or whatever, and tells the system to look there, but when Eraser tries to ask Windows for the list of drives available on the system, the FreeOTFE volume does not appear in the system generated list. I've compared this with TrueCrypt, and there's something different about their approaches because a TrueCrypt volume does appear in the list of drives generated.

Unfortunately this would mean that it is not an Eraser bug but a FreeOTFE one; I've double-checked this by running the Windows mountvol command and the FreeOTFE drive does not appear whereas the TrueCrypt one does. Do you know the FreeOTFE developer?
 
Drives mounted using FreeOTFE are listed in a 'fsutil fsinfo drives' at the command line. Their type is given as 'Fixed Drive' from the 'fsutil fsinfo drivetype [drive]' command, just like a genuine local disk. The sdelete utility is able to delete files on it. In some ways, the system believes there is a new fixed drive when FreeOTFE mounts its volume, but I guess not in the way eraser uses to detect it.

I'm afraid I haven't been able to contact the FreeOTFE developer. I have been trying, as there's a bug I'd like to get fixed, but she's pretty hard to track down. Her website was last updated over a year ago on 5th December 2010. I suppose I'd better start planning a switch-over to Truecrypt.
 
Hmm, emails sent to her bounces and SourceForge has indicated she does not want to receive mail... I guess that's a dead end then.
 
Mine also bounced when I tried to e-mail her a few months ago.

Well then, thanks for again for investigating the problem, I appreciate it.
 
You must log in or register to reply here.
Back
Top