Hello Tim, hello everybody
thanks for making a number of additional, good points. I will try and answer them while at the same time improve my previous explanations.
In summary, if you rm a file that is being held open by a running process, you only lose it's "reference by name", because the directory entry is being removed. The computer prefers to know files by inode number, so the OS is still fine and the process can still read from or write to the file. The icat tool from TCT/TSK is designed to read such a file by just specifying the inode number and the file system's device file, but of course only for supported file systems. In terms of "evil software", I have not checked myself so the following is a guess: The attacker may possess low-level tools to do either 1) or 2) of what Tim has listed, but most likely he does 3) e.g. after a signal was sent to the sniffer software it could copy the data into another file... Another interesting thing in this context is that on HP-UX you cannot rm the executable of a running process. In other UNIXes you can, thus attackers sometimes do this to "hide" their malware process from disk scans by file integrity checking software like tripwire.
Tim, if you now want to destroy the data, that is quite a different story. Even if you rm a file which no process has currently open, the data is often not destroyed, contrary to what you wrote in decribing you 2nd scenario. This of course depends on the file system, but what I've seen so far with FFS/UFS/HFS for Sun/HP/*BSD, ext2/3 and JFS for Linux, (and in some sense in FAT and NTFS too) is the following:
When a file gets rm'ed, first its filename is being removed from the directory where it resided in. For multiple reasons, already this step is often times not a true erasure, but the directory entry is just marked invisible. For this reason, the fls tool of TSK is able to list names of deleted files and sometimes even the inode numbers of those deleted files. HP-UX's HFS is the exception here, it zeroizes both the name string and the inode number. (in the past, a poor man's version of fls was to just run 'strings' on a directory, but nowadays, many UNIXes disallow this).
The second step in file deletion deals with the inode. There the refcount is set to zero and the inode is marked as free in the inode allocation table. Then the disk block pointers are examined and the disk blocks are marked as free *in the disk block allocation table*, i.e. the disk blocks themselves are not zeroized, so your data remains on disk and may very well "survive" for years to come, depending on the usage pattern of the disk. HP-UX's HFS, Solaris and *BSD UFS do then zeroize the disk block pointers, which makes it harder to "undelete" the file, because you don't know which "free" disk block belonged to which former file. But the data is still there and Linux even keeps the block pointers, so there "icat" can be used to easily undelete a rm'ed file, assuming that its disk blocks are not already in use by another file. For the other UNIXes TCT offers the lazarus tool, which tries to classify disk blocks which are "officially" free, and because UFS/FFS/FFS try to allocate files contiguously on disk, success rates at least for small file sizes are not too bad.
So for really "destroying' a file in UNIX you have to overwrite it with e.g. all zeros (or multiple overwrites with alternating bit pattern, depending on you level of paranoia :-) before actually deleting it. There are "secure deletion" utilities available which perform this task, although off my head I don't know a product name for HP-UX. Such a tool may either choose to ignore file system specifics and open the file in write mode, or it may query the system via an ioctl for the actual sectors in use by the file and directly deal with those. While the first approach is easy to implement, there is the risk that the file system decides to reallocate the file to another set of disk blocks when it "sees" the write requests intended to overwrite the existing file.
Tim, your problem with this is that these tools - as far as I know - only work with files that still exist (although it should not be too hard for the implementor of such a tool to accept an inode number instead of a file name...). So in your case you would again have to re-attach using fsdb.
Clay, on a second thought, do you really think re-attaching would be that "dangerous". I mean, barring typos while using fsdb technically I think all you would have to do is create another directory entry that points to the inode number in question. Regarding updating the refcount, in HP-UX's HFS that would not even be necessary, because that is still kept at 1 even though the file has been "officially" deleted (don't know about vxfs of course).
Josh, sorry but no HP-UX/vxfs specific news from my side. I'm also not aware of a commercial offering for HP-UX. About a year ago I saw an ad for an undelete tool for AIX' JFS and JFS2. I myself did an extension of TCT/TSK to JFS for Linux, mostly to learn/study journaling file systems. This was considerably easier than vxfs/onlinejfs because the file system has been "donated" to Linux by IBM and excellent documentation about the layout of data and meta-data is available. Thus the internals in that case were known and it was not too difficult to implement, as you were stating in your post. Probably a week of coding and two weeks of testing/verification. (My JFS for Linux modul for TSK is not yet published, I'm waiting for TSK 2.0 plus I have to tie up a few loose ends here and there...)
I know I've left out some details but regretfully I'm running out of time...
Best regards,
Knut
PS: We may ask the forum admin to award some extra points for what probably is the longest running thread ever (or at least the thread with the longest intermittent breaks :-)
