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

[Brian C. <bca...@at...>]

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