sleuthkit-users

[sleuthkit-users] how to map a bad block back to a file?

[Gary F. <ga...@in...>]

 From time to time, we process a hard drive that has
a series of unrecoverable errors.  We'd like a fairly
quick check that we can run while imaging the drive
that tells us if the bad blocks likely fall in
allocated space (inclusive of metadata), and if so,
which files (and/or metadata) might be affected.
It would also be nice to know if the bad blocks
are part of a deleted file as well, if applicable.

 Given that ntfs volumes are prevalent these
days, our primary interest is ntfs volumes, but
hopefully the same principles might apply to
FAT32, ext3 and other file system types as well.

 Can the sleuthkit tools perform this fucntion?
What would be the recommended sequnces of
commands that must be run to accomplish the task?

Re: [sleuthkit-users] how to map a bad block back to a file?

[Simson G. <si...@ac...>]

Sleuthkit can't do this out-of-the-box. Are you really running Sleuth  
Kit on the raw drive?

However, the combination of aimage & sleuthkit and some fancy  
software that I am working can do this pretty easily. What would you  
use it for?


On Nov 20, 2006, at 1:22 PM, Gary Funck wrote:

>
>  From time to time, we process a hard drive that has
> a series of unrecoverable errors.  We'd like a fairly
> quick check that we can run while imaging the drive
> that tells us if the bad blocks likely fall in
> allocated space (inclusive of metadata), and if so,
> which files (and/or metadata) might be affected.
> It would also be nice to know if the bad blocks
> are part of a deleted file as well, if applicable.
>
>  Given that ntfs volumes are prevalent these
> days, our primary interest is ntfs volumes, but
> hopefully the same principles might apply to
> FAT32, ext3 and other file system types as well.
>
>  Can the sleuthkit tools perform this fucntion?
> What would be the recommended sequnces of
> commands that must be run to accomplish the task?
>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>

Re: [sleuthkit-users] how to map a bad block back to a file?

[Gary F. <ga...@in...>]

 

> -----Original Message-----
Simson Garfinkel wrote:
> Sleuthkit can't do this out-of-the-box. Are you really 
> running Sleuth  
> Kit on the raw drive?

No. We plan to run Sleuthkit on the image of the drive.
However, the image has known hardware errors, where the
error sectors have been replaced with zeros.  The dclfdd
output looks something like this:

dcfldd:/dev/hde: Input/output error
6601392+31 records in
6601423+0 records out
dcfldd:/dev/hde: Input/output error
18533840+32 records in
18533872+0 records out
dcfldd:/dev/hde: Input/output error
18533840+33 records in
18533873+0 records out

The original dclfdd command was something like this:

dcfldd if=/dev/hde of=/evidence/Dell8100.img bs=512 \
  hash=md5 conv=error,sync \
  hashlog=/evidence/Dell8100.md5  \
  errlog=/evidence/Dell8100.err_log

There is sufficient information in the error log to
determine which blocks (sectors) had read errors.

> 
> However, the combination of aimage & sleuthkit and some fancy  
> software that I am working can do this pretty easily. What would you  
> use it for?

Please tell us more about that fancy software. <g>

Generally, I planned on simply having the imaging script
identify the file data and/or metadata that had likely
been lost.  What we typically do in the case that the
drive has errors is to copy the image file back onto
a scratch drive, and then run chkdsk or its equivalent
on the scratch drive, and then run our analysis on the
resulting file system(s). We'd take the same steps if
we were simply restoring a failing drive by copying it
to a new drive (first make an image, then copy the
image to the new drive, then run chkdsk).

However, from what I recall, chkdsk doesn't print any
information regarding which files or data might have
been lost during the fix up pass.  As a matter of
completeness, we'd like to have that information,
and we'd like to obtain that information as part
of the drive imaging process, in an automated fashion.

Re: [sleuthkit-users] how to map a bad block back to a file?

[Brian C. <ca...@sl...>]

If you know the address of the bad blocks, then you can use 'ifind' to 
find out if the block is allocated to an inode/MFT Entry.  You can then 
use ils or istat to find out if the inode/MFT Entry is currently 
allocated or not.

brian

Gary Funck wrote:
>  From time to time, we process a hard drive that has
> a series of unrecoverable errors.  We'd like a fairly
> quick check that we can run while imaging the drive
> that tells us if the bad blocks likely fall in
> allocated space (inclusive of metadata), and if so,
> which files (and/or metadata) might be affected.
> It would also be nice to know if the bad blocks
> are part of a deleted file as well, if applicable.
> 
>  Given that ntfs volumes are prevalent these
> days, our primary interest is ntfs volumes, but
> hopefully the same principles might apply to
> FAT32, ext3 and other file system types as well.
> 
>  Can the sleuthkit tools perform this fucntion?
> What would be the recommended sequnces of
> commands that must be run to accomplish the task?

Re: [sleuthkit-users] how to map a bad block back to a file?

[Gary F. <ga...@in...>]

 
Brian Carrier wrote:
> If you know the address of the bad blocks, then you can use 
> 'ifind' to 
> find out if the block is allocated to an inode/MFT Entry.  
> You can then 
> use ils or istat to find out if the inode/MFT Entry is currently 
> allocated or not.

OK. I'll give that a try.  Please note my reply to
Simson for additional background.  I think the challenge
may be automating the steps outlined above.

Re: [sleuthkit-users] how to map a bad block back to a file?

[Al G. <big...@gm...>]

Did you ever do this successfully?

It is EXACTLY what I am trying to do.

Cheers

-Al


Gary Funck wrote:
> 
>  
> Brian Carrier wrote:
>> If you know the address of the bad blocks, then you can use 
>> 'ifind' to 
>> find out if the block is allocated to an inode/MFT Entry.  
>> You can then 
>> use ils or istat to find out if the inode/MFT Entry is currently 
>> allocated or not.
> 
> OK. I'll give that a try.  Please note my reply to
> Simson for additional background.  I think the challenge
> may be automating the steps outlined above.
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
> 
> 

-- 
View this message in context: http://old.nabble.com/how-to-map-a-bad-block-back-to-a-file--tp7449524p26455507.html
Sent from the sleuthkit-users mailing list archive at Nabble.com.