RE: [sleuthkit-users] dls rawfs_block_walk errors
Brought to you by:
carrier
|
From: Mark K. M. <mar...@la...> - 2006-05-25 14:21:07
|
Oh, well wait ... I just noticed that the block reported in the error = (58605129) is the last block of my raw disk image. So I'm no longer = concerned it's missing information in the string extraction. ;) -----Original Message----- From: Brian Carrier [mailto:ca...@sl...] Sent: Thu 5/25/2006 7:46 AM To: Mark K. Murdock Cc: sle...@li... Subject: Re: [sleuthkit-users] dls rawfs_block_walk errors =20 What is the size (in bytes) of the file you are reading? I guess =20 this error could occur if your file is not a multiple of 512-bytes. =20 Did you import the file image as a rawfs? brian On May 25, 2006, at 12:08 AM, Mark K. Murdock wrote: > Hi all, > > I'm using Sleuthkit 2.03 and Autopsy 2.06 on Debian Linux (Sarge). =20 > While extracting Unicode strings from an image, dls threw the =20 > following error: > > /usr/local/sleuthkit/bin/dls: rawfs_block_walk: Error reading block =20 > at 58605129: Success > > It did the same thing during an ASCII string extraction, but I =20 > didn't note the exact error. I checked the source (rawfs.c) and it =20 > looks like that error occurs when (surprise) there's a problem =20 > reading a block while iterating the blocks of the image. I'm not =20 > sure exactly what the problem was, because I didn't rerun the dls =20 > command with the verbose option specified (I'm planning to, but =20 > it's time consuming and I haven't gotten to that yet). > > My questions are: When it comes to extracting strings, is it =20 > important that a block read error be a fatal error? Currently it =20 > stops the string extraction (because dls quits). I was thinking of =20 > making a small change to the source to keep iterating the blocks =20 > past a read error based on a command argument (an "ignore read =20 > errors" type switch). Am I just getting myself into trouble here, =20 > or does doing something like this make sense? > > Thanks, > Mark > |