RE: [sleuthkit-users] Splitting keywords across cluster boundaries?

[Brent D. <bre...@te...>]

I don't know how much of an issue it really is. My solution to it was to
build a more-redundant keyword list.

In my example to search for "Forensics Investigator" I built a keyword list
of "Forensic" and "Investigat" - it's a game of more false positives versus
catching something you would have otherwise missed. In my case I didn't
catch anything new.

Going through the image and doing an icat (I assume icat follows the inodes
to get the whole file?) would work. The best solution would be to store the
results in one big file that you could parse through. Exactly like what is
done currently but having the inode be the key instead of the offset. Then
having autopsy accept that format file to use in keyword searches.

My first thought was to mount the image read only, recursing through every
directory and doing a strings on each file. To cover deleted files use unrm
and strings each of those files. You can't cover slack and free space
obviously. By doing this I would have missed out on some cool functionality
of autopsy though.

Is this a feature/method worth implementing or is it really an issue? I
think being able to do keyword searches and have the results be keyed to
files instead of offsets would be nice - but that functionality is there
with ifind already. The current method would still have to be done for free
and slack space, while the deleted files could be recovered and run through
strings.

Good discussion!

-- Brent

-----Original Message-----
From: Brian Carrier [mailto:bca...@at...]
Sent: Tuesday, July 23, 2002 5:59 PM
To: Brent Deterding
Cc: List - Sleuthkit
Subject: Re: [sleuthkit-users] Splitting keywords across cluster
boundaries?


That is a good point.  I guess I could easily build in an option to do
an 'icat' on every allocated inode and do a grep on the output.  I'm
sure it would be much slower though.  It would be fairly easy though.

brian


On Tue, Jul 23, 2002 at 05:55:18PM -0500, Brent Deterding wrote:
> Thanks for the quick response! Perhaps this is my ignorance or perhaps I
> didn't say what I meant to say.
>
> I understand the image is the image independent of any boundaries. If I'm
> searching an image for the keyword "Forensics Investigator" that string
> could be found in a file that is fragmented across the disk. "Forensics"
may
> be at the beginning of the image and "Investigator" may be at the end of
the
> image. Hence, searching the image for "Forensics Investigator" would not
> work, correct?
>
> In which case should I care? Especially if it's a large image with a lot
of
> free space (indicating a lower probability of fragmentation and indicating
a
> larger cluster size which would mean a lower probability that my string
just
> happens to fall across a boundary).
>
> Brent Deterding
> GSEC, GCFW, GCIA, GCIH, RHCE
> Security Engineer
> TechGuard Security
> E-Mail: bre...@te...
> Phone: (636) 519-4848
>
> "NOTE: EMAIL IS NOT NECESSARILY SECURE"
>
> NOTICE:  This communication may contain privileged or other confidential
> information.  If you are not the intended recipient or believe that you
may
> have received this communication in error, please reply to the sender
> indicating that fact and delete the copy you have received.  In addition,
> you should not print, copy, retransmit, disseminate or otherwise use the
> information."
>
>
> -----Original Message-----
> From: Brian Carrier [mailto:bca...@at...]
> Sent: Tuesday, July 23, 2002 5:29 PM
> To: Brent Deterding
> Cc: List - Sleuthkit
> Subject: Re: [sleuthkit-users] Splitting keywords across cluster
> boundaries?
>
>
> You'll find the string.  The strings file knows nothing about sectors,
> clusters, fragments etc.  So, when your string is found, it will know
> the byte offset within the full image.  It uses that value to calculate
> the first cluster / sector it is in and then uses the 'ifind' tool to
> identify which dentry / inode / MFT has allocated it (if any).
>
> The way that Autopsy does searches is likely not the most efficient
> time-wise, but it is the most accurate because it doesn't care about
> boundaries.
>
> brian
>
> NOTE: The tools use the sector number with FAT and not cluster number.
> Refer to the docs file for more details.
>
> HINT: To find the size of a fragment or cluster use either dcat -s or
> fsstat.
>
>
>
>
>
> On Tue, Jul 23, 2002 at 04:41:30PM -0500, Brent Deterding wrote:
> > Hello, (primarily Brian since no one else is signed up yet probably)
> > 	I'm thinking about the fundamental way I'm going about doing a keyword
> > search. I'm using autopsy/task to do the searches (well - the same
> > commands).
> >
> > 	I'm getting the strings output of the entire image with decimal offsets
> > (strings -a -t d <image>). This is on a large image with most of the
image
> > being free space. It's fat. I'm using the resulting strings file to do
> > searches against for keywords. My question being: What if a keyword fell
> > across a cluster boundary?
> >
> > 	Example: I'm searching for "Forensics Investigator" and it just so
> happens
> > that "Forensics" is on a different cluster than "Investigator" - the
> current
> > method would not catch this.
> >
> > 	First - should I even worry about this?
> > 	Second - I could make my search strings redundant (Have a "Forensics
> > Investigator" and a "Investigator" or "Investigat" or something).
> > 	Third - the surefire method - mount the image read-only, recurse
through,
> > and strings each file - recover deleted files and strings each of them
as
> > well.
> >
> > 	Thoughts?
> >
> > Brent Deterding
> > GSEC, GCFW, GCIA, GCIH, RHCE
> > Security Engineer
> > TechGuard Security
> > E-Mail: bre...@te...
> > Phone: (636) 519-4848
> >
> > "NOTE: EMAIL IS NOT NECESSARILY SECURE"
> >
> > NOTICE:  This communication may contain privileged or other confidential
> > information.  If you are not the intended recipient or believe that you
> may
> > have received this communication in error, please reply to the sender
> > indicating that fact and delete the copy you have received.  In
addition,
> > you should not print, copy, retransmit, disseminate or otherwise use the
> > information."
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > sleuthkit-users mailing list
> > sle...@li...
> > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> sleuthkit-users mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users