[sleuthkit-users] (no subject)

[Lehr, J. <jl...@sl...>]

 
Hi All, 

I've been working on a faster way to map unallocated blocks extracted
with blkls to disk blocks in the partition.  The TSK tool blkcalc can do
this, but it is quite slow as the man page denotes.  I figured with some
simple math and a little metadata, I could do it faster manually.

Here's what I did:

1) extracted unallocated ascii and unicode strings with blkls with
something like: 
$ blkls partition.dd | (tee >/dev/null >(strings -td) >(strings -td
-el))> partition.strings

2) grepped partition strings for "search term" and found it at byte
offset #####.  Decided I needed to look at original block.

3) created a list of unallocated blocks with:
$ blkls -l partition.dd > unalloc.block.list

4) determined the block offset of my "search term" by dividing the byte
offset by the file system block size determined through fsstat.
$ echo $((#####/4096)))
##

5) determined the block address of unallocated block in the partition by
reading line ## of unallocated.block.list (the tail command removes the
three lines of header from the blkls -l output)
$ tail -n +4 unallocated.block.list | cat -n | grep -m1 ^##
#####|f

where "#####" is the block id of the unallocated block in the partition
(almost, see below). With exception to making the strings file and the
block list, this process takes only a minute or so to complete on a
250gb partition with 137gb of unallocated space.  And, it can be
scripted, of course.

That said, what I have found is that the block address retrieved from
step 5 is short by 1 block.  Easy to compensate for, but I could use
some help understanding why.  Anybody have an explanation?

Thanks,
John
______________________________
 
John Lehr
 
Evidence Technician
San Luis Obispo Police Department
______________________________