forensic excavation
Jun. 18th, 2002 10:02 amSo, in the interests of (a) learning something new and (b) helping out a cow orker, I was investigating forensic disk tools last night. These are tools which are designed to get data out of a trashed disk - either a deliberately trashed disk (destruction of evidence) or an accidental disk crash victim. J's disk is in the latter category; as best I can tell, the OS managed to scribble all over the superblock and root directory, which is sort of like tearing out the first 50 pages of a chose-your-own-adventure book - you can pick up several trails on page 51 and onwards, but trying to back-link them to the missing pages can be, uh, entertaining. The superblock is a sort of master guide to the disk structure, and as such is deemed important enough to copy to several places on the disk, so that's recoverable. The rest, though, is a bit of a loss.
So.
Dan Farmer, of SATAN fame, and Weitse Venema (did I spell that correctly?) of, among other things, TCP wrappers and fighting-with-Dan-Bernstein fame have a thing called The Coroner's Toolkit, a collection of vaguely cross-platform excavation tools for your trashed disk. Not particularly friendly to use, so I looked at what they linked to (Google Measure Of Quality - find someone smart, then look at what they point at) and found a complementary pair of tools called TASK and Autopsy - the latter is a HTML-based (spit) frontend for the former. So I grabbed & built these and tried them out.
I am not in the slightest bit impressed with a supposed forensic tool that requires the disk to be intact before it will do any digging. That kinda misses the point. Thus, Autopsy was consigned to the junk pile and, well, TASK is about as friendly as an angry porcupine if you don't use Autopsy. And I'm lazy, dammit.
So I looked at the e2fs tools provided as part of e2fsprogs, and decided to play with debugfs. Well, I had to hack the source slightly, first, because evidently it's not been tested with -b or -s parameters in a long time, but anyway. After an initial period of manual reading and pokery, I put together a 10-line perl script that drove debugfs and extracted the first 32k inodes + chains on the disk (there are about 700k of them. I'm experimenting). Now, this seems like a far smarter way of doing forensic extraction on a trashed disk, because it can usefully recreate directory structures without the disk having to be intact - once you've got a superblock /somewhere/, you're sorted.
I've since scribbled out a plan of action using bits of debugfs to restore what I can from the disk; I'll talk to cow orker and find out how badly he needs data from the disk, and then start digging. I think I could probably write my own forensic tool based on this experience.
So.
Dan Farmer, of SATAN fame, and Weitse Venema (did I spell that correctly?) of, among other things, TCP wrappers and fighting-with-Dan-Bernstein fame have a thing called The Coroner's Toolkit, a collection of vaguely cross-platform excavation tools for your trashed disk. Not particularly friendly to use, so I looked at what they linked to (Google Measure Of Quality - find someone smart, then look at what they point at) and found a complementary pair of tools called TASK and Autopsy - the latter is a HTML-based (spit) frontend for the former. So I grabbed & built these and tried them out.
I am not in the slightest bit impressed with a supposed forensic tool that requires the disk to be intact before it will do any digging. That kinda misses the point. Thus, Autopsy was consigned to the junk pile and, well, TASK is about as friendly as an angry porcupine if you don't use Autopsy. And I'm lazy, dammit.
So I looked at the e2fs tools provided as part of e2fsprogs, and decided to play with debugfs. Well, I had to hack the source slightly, first, because evidently it's not been tested with -b or -s parameters in a long time, but anyway. After an initial period of manual reading and pokery, I put together a 10-line perl script that drove debugfs and extracted the first 32k inodes + chains on the disk (there are about 700k of them. I'm experimenting). Now, this seems like a far smarter way of doing forensic extraction on a trashed disk, because it can usefully recreate directory structures without the disk having to be intact - once you've got a superblock /somewhere/, you're sorted.
I've since scribbled out a plan of action using bits of debugfs to restore what I can from the disk; I'll talk to cow orker and find out how badly he needs data from the disk, and then start digging. I think I could probably write my own forensic tool based on this experience.