Re: [sleuthkit-users] Splitting keywords across cluster boundaries?
Brought to you by:
carrier
From: Brian C. <bca...@at...> - 2002-07-23 23:03:49
|
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 |