[250] in The Cryptographic File System users list
Recovering deleted CFS files
daemon@ATHENA.MIT.EDU (Stefan Hudson)
Tue Nov 6 17:45:18 2001
From owner-cfs-users@crypto.com Tue Nov 06 22:45:18 2001
Return-Path: <owner-cfs-users@crypto.com>
Delivered-To: cfs-mtg@CHARON.mit.edu
Received: (qmail 19027 invoked from network); 6 Nov 2001 22:45:17 -0000
Received: from mx.crypto.com (207.140.168.138)
by charon.mit.edu with SMTP; 6 Nov 2001 22:45:17 -0000
Received: (from majordomo@localhost)
by MultiHostMXServer (8.9.3/8.9.x4) id RAA27098
for cfs-users-list; Tue, 6 Nov 2001 17:27:38 -0500 (EST)
X-Authentication-Warning: mx.crypto.com: majordomo set sender to owner-cfs-users@crypto.com using -f
Received: from nsa.research.att.com (H-135-207-24-155.research.att.com [135.207.24.155])
by MultiHostMXServer (8.9.3/8.9.x4) with ESMTP id RAA04134
for <cfs-users@crypto.com>; Tue, 6 Nov 2001 17:27:36 -0500 (EST)
Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by nsa.research.att.com (8.7.3/8.7.3) with ESMTP id RAA16102 for <cfs-users@nsa.research.att.com>; Tue, 6 Nov 2001 17:27:33 -0500 (EST)
Received: by mail-green.research.att.com (Postfix)
id 514521E046; Tue, 6 Nov 2001 17:27:35 -0500 (EST)
Delivered-To: cfs-users@research.att.com
Received: from otter.mbay.net (otter.mbay.net [206.40.79.2])
by mail-green.research.att.com (Postfix) with ESMTP id 854C91E07E
for <cfs-users@research.att.com>; Tue, 6 Nov 2001 17:27:34 -0500 (EST)
Received: (from hudson@localhost)
by otter.mbay.net (8.11.4/8.11.4) id fA6MRXC13989
for cfs-users@research.att.com; Tue, 6 Nov 2001 14:27:33 -0800
Date: Tue, 6 Nov 2001 14:27:33 -0800
From: Stefan Hudson <hudson@mbay.net>
To: cfs-users@research.att.com
Subject: Recovering deleted CFS files
Message-ID: <20011106142733.C28241@mbay.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.6i
Sender: owner-cfs-users@crypto.com
Precedence: bulk
Well, folks, I feel really stupid about having to post this.
I was cleaning up my system the other day, and came across what
I thought was a junk directory of some old test files. A quick
"rm -rf" to fix it, and went to hit the head. When I came back,
it was STILL deleting. I started to get that sinking feeling...
It was no junk directory, it was my CFS encrypted directory.
I'd remounted it a while back and forgot where I'd put it. "Doh!"
I killed the rm before it had completely finished, but I lost
about 90% of the files in the directory. None of it backed up,
of course.
I was able to recover the ..[cks] files using debugfs and some
educated guessing, so I can access the few files that didn't get
deleted. Of course, Murphy's Law states that those files are the
least important ones I had stored.
I have managed to recover all of the ecrypted data files, without
the original (encrypted) filename - they are just named by inode
number right now. However, almost all ".pvect_" files could not
be recovered, for reasons I don't completely understand. In any
case, matching the .pvect file to the appropriate data file would
be very difficult because names are lost.
I tried creating an empty file on the "front" side of CFS, which
created and empty file and .pvect link on the back side, then
replacing the empty data file with one of the recovered files.
That didn't work... when I tried to read the file from the "front"
side of CFS, it was scrambled.
What was interesting is that the data did *not* appear to be
completely random data, which is what I would have expected if it
was using the wrong key. Instead, it seemed to be from a limited
set of characters. For example, a test file containing
"test test test\n" became something like "@E^XZ^VDUA@^W^VSAD:" if
I deleted the .pvect file and re-attached the cfs directory.
Certainly not readable, but not complete random garbage either.
My questions are these... is there anything I can do to recover
this data from here? Exactly what do the ".pvect_" files do? Is
there any way to get cfs to decrypt a file without the .pvect file
that was associated with the the original filename?
Thanks for any advice,
Stefan
