sleuthkit-users — List to discuss Autopsy and The Sleuth Kit.

Re: [sleuthkit-users] Athlon64 exam machine Q????

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

TSK 1.73 fixed the 64-bit Linux compatibility issues, so you should be 
all set.

The odd sector Linux issue was fixed in 2.6.

brian



On Jan 18, 2005, at 10:51 AM, Rich Thompson wrote:

> Howdy folks,
>
> Quick question.  Would there be any issues, or
> drawbacks to imaging and examning a WinXP drive on an
> Athlon64 examination machine???  Just built a new
> machine, and was thinking about playing with the
> Sluethkit and Autopsy on it.
>
> The OS is Suse 9.2.
>
> Any odd settings regarding the odd sector issue, or
> was that fixed with the 2.6 kernel???

Re: [sleuthkit-users] filesystem recovery using sleuthkit

[Jim C. <jc...@di...>]

Rich Thompson wrote:

>You may have already tried, but I'll say it anyway -
>Did you try booting with an XP boot disk and doing an
>fdisk mbr???  That should return the mbr for windows
>allowing you to boot....
>
>Rich
>
>  
>
the XP recovery disk that shipped with the Dell
did not include fdisk IIRC, so I used what it did have;
fixmbr & fixboot.

These 2 tools each fixed something; they changed the error
message, but at the end of the boot attempt, it found
an empty FAT12 fs where the partition table told it to look.

At any rate, I re-installed XP, and have a 60 GB image
to play around with, and see if I can slice off that FAT12 slice,
or find an NTFS superblock later on the disk and copy it
onto the FAT12 sector.

If you know of any free (as beer) NTFS repair tools,
Im all ears.

thanks
jimc

>--- Jim Cromie <jc...@di...> wrote:
>
>  
>
>>Im trying to recover contents of a 60GB Windows XP
>>installation
>>after a grub accident.
>>
>>A short 'how I got here' follows, then the
>>Questions.
>>
>>I recently screwed up (technical jargon) my dads
>>winXP box
>>while trying to put grub on a usb-drive.
>>(grub went onto /dev/hda, but linux was on /dev/sda,
>>so it wouldnt boot anything)
>>
>>I recovered using the recovery disk, tried the
>>repair option:
>>fixmbr - to restore the MBR, and fixboot (I think)
>>
>>These tools apparently trashed the root of C:\,
>>they showed me a mostly empty root-dir, with 4
>>(empty)
>>files with names that were evidently unreadable by
>>the OS
>>(they were represnted by ?, all 4 of them)
>>
>>with a knoppix disk and a 3 line perl prog,
>>I took 1GB at a time off it, and NFS'd it to my
>>laptop,
>>then onto the USB drive  (knoppix dd wouldnt handle
>>    
>>
>>>2GB files)
>>>      
>>>
>>(knoppix 3.6 wouldnt mount the usb directly - some
>>versioning
>>prob w the usb-* modules)
>>
>>I catted all the 1gb chunks together, and have
>>started autopsy-2.03
>>and sleuthkit-1.73 on it.
>>
>>Evidence Locker: /mnt/u2/forensics
>>Start Time: Sun Jan  9 09:32:31 2005
>>Remote Host: localhost
>>Local Port: 9999
>>
>>Open an HTML browser on the remote host and paste
>>this URL in it:
>>
>>    http://localhost:9999/autopsy
>>
>>Keep this process running and use <ctrl-c> to exit
>>..//bin/fsstat: $Data not found while loading the
>>MFT
>>..//bin/fsstat: Invalid FAT32 image (numroot != 0)
>>..//bin/fsstat: Invalid FAT32 image (numroot != 0)
>>..//bin/fsstat: $Data not found while loading the
>>MFT
>>..//bin/fsstat: Invalid FAT32 image (numroot != 0)
>>..//bin/fsstat: getFAT: return FAT16 cluster too
>>large
>>
>>
>>fsstat seems to be having trouble with this
>>partition, and its unclear
>>to me what kind of filesystem is *really* there.
>>
>>fdisk told me it was NTFS/HPFS
>>mount told me it was vfat
>>autopsy thinks its FAT16, would *not* accept choice
>>of NTFS or FAT32
>>
>>it appears that this is due to the root directory,
>>which appears to
>>have been overwritten by the MS tools.  Ive
>>inspected other
>>parts of the 60 GB, they appear to have the original
>>content.
>>
>>Qs:
>>
>>is it common on MS OSs that partition type and fs
>>type are different ?
>>
>>is the choice of filesystem completely dictated by
>>the root-directory ?
>>is the choice overridable ?
>>is there a reason its not automatic - since it seems
>>to reject the 
>>'wrong' choices ?
>>
>>is it possible to not care ?
>>in my case, I hope to find that the vast majority of
>>directories
>>look to be uncorrupted - ie the directory entries
>>are legal,
>>and point to files that match whatever metadata is
>>stored in the 
>>directory entry itself,
>>and link to each other properly.
>>IOW, if 59.9 GB of data look consistent with each
>>other,
>>then clearly the root folder is hosed, and is only
>>thing to fix.
>>
>>
>>wrt:
>>Calculating MD5 of images/whole.img (this could take
>>a while)
>>
>>    
>>
>+----+----+----+----+----+----+----+----+----+----+----+----+----+----+-
>  
>
>>it would be nice to have some estimate of ' a
>>while',
>>ie how big the ticks are,
>>
>>
>>
>>my other attempts to extract some of the original
>>filesystem
>>have also run afoul on this FAT16 choice:
>>
>>..//bin/ils: getFAT: return FAT16 cluster too large
>>..//bin/dls: getFAT: return FAT16 cluster too large
>>
>>
>>Im gonna continue poking, 1st thru autopsy, then the
>>sleuthkit tools,
>>but Im also contemplating trying to remove/zero out
>>the root directory
>>so that something else in the partition has a chance
>>to influence the mount.
>>Please advise me on this course of action b4 I do
>>something (else) stupid
>>
>>tia
>>jimc
>>
>>
>>
>>
>>    
>>
>
>  
>

Re: [sleuthkit-users] filesystem recovery using sleuthkit

[Rich T. <te...@ap...>]

You may have already tried, but I'll say it anyway -
Did you try booting with an XP boot disk and doing an
fdisk mbr???  That should return the mbr for windows
allowing you to boot....

Rich

--- Jim Cromie <jc...@di...> wrote:

> 
> Im trying to recover contents of a 60GB Windows XP
> installation
> after a grub accident.
> 
> A short 'how I got here' follows, then the
> Questions.
> 
> I recently screwed up (technical jargon) my dads
> winXP box
> while trying to put grub on a usb-drive.
> (grub went onto /dev/hda, but linux was on /dev/sda,
> so it wouldnt boot anything)
> 
> I recovered using the recovery disk, tried the
> repair option:
> fixmbr - to restore the MBR, and fixboot (I think)
> 
> These tools apparently trashed the root of C:\,
> they showed me a mostly empty root-dir, with 4
> (empty)
> files with names that were evidently unreadable by
> the OS
> (they were represnted by ?, all 4 of them)
> 
> with a knoppix disk and a 3 line perl prog,
> I took 1GB at a time off it, and NFS'd it to my
> laptop,
> then onto the USB drive  (knoppix dd wouldnt handle
> > 2GB files)
> (knoppix 3.6 wouldnt mount the usb directly - some
> versioning
> prob w the usb-* modules)
> 
> I catted all the 1gb chunks together, and have
> started autopsy-2.03
> and sleuthkit-1.73 on it.
> 
> Evidence Locker: /mnt/u2/forensics
> Start Time: Sun Jan  9 09:32:31 2005
> Remote Host: localhost
> Local Port: 9999
> 
> Open an HTML browser on the remote host and paste
> this URL in it:
> 
>     http://localhost:9999/autopsy
> 
> Keep this process running and use <ctrl-c> to exit
> ..//bin/fsstat: $Data not found while loading the
> MFT
> ..//bin/fsstat: Invalid FAT32 image (numroot != 0)
> ..//bin/fsstat: Invalid FAT32 image (numroot != 0)
> ..//bin/fsstat: $Data not found while loading the
> MFT
> ..//bin/fsstat: Invalid FAT32 image (numroot != 0)
> ..//bin/fsstat: getFAT: return FAT16 cluster too
> large
> 
> 
> fsstat seems to be having trouble with this
> partition, and its unclear
> to me what kind of filesystem is *really* there.
> 
> fdisk told me it was NTFS/HPFS
> mount told me it was vfat
> autopsy thinks its FAT16, would *not* accept choice
> of NTFS or FAT32
> 
> it appears that this is due to the root directory,
> which appears to
> have been overwritten by the MS tools.  Ive
> inspected other
> parts of the 60 GB, they appear to have the original
> content.
> 
> Qs:
> 
> is it common on MS OSs that partition type and fs
> type are different ?
> 
> is the choice of filesystem completely dictated by
> the root-directory ?
> is the choice overridable ?
> is there a reason its not automatic - since it seems
> to reject the 
> 'wrong' choices ?
> 
> is it possible to not care ?
> in my case, I hope to find that the vast majority of
> directories
> look to be uncorrupted - ie the directory entries
> are legal,
> and point to files that match whatever metadata is
> stored in the 
> directory entry itself,
> and link to each other properly.
> IOW, if 59.9 GB of data look consistent with each
> other,
> then clearly the root folder is hosed, and is only
> thing to fix.
> 
> 
> wrt:
> Calculating MD5 of images/whole.img (this could take
> a while)
>
+----+----+----+----+----+----+----+----+----+----+----+----+----+----+-
> 
> it would be nice to have some estimate of ' a
> while',
> ie how big the ticks are,
> 
> 
> 
> my other attempts to extract some of the original
> filesystem
> have also run afoul on this FAT16 choice:
> 
> ..//bin/ils: getFAT: return FAT16 cluster too large
> ..//bin/dls: getFAT: return FAT16 cluster too large
> 
> 
> Im gonna continue poking, 1st thru autopsy, then the
> sleuthkit tools,
> but Im also contemplating trying to remove/zero out
> the root directory
> so that something else in the partition has a chance
> to influence the mount.
> Please advise me on this course of action b4 I do
> something (else) stupid
> 
> tia
> jimc
> 
> 
> 
>
-------------------------------------------------------
> The SF.Net email is sponsored by: Beat the
> post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt
> from ThinkGeek.
> It's fun and FREE -- well,
> almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> sleuthkit-users mailing list
>
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
> 

Re: [sleuthkit-users] Mac OS Extended (HSF+)

[Rich T. <te...@ap...>]

You could try EnCase from Guidance Software, but at
$2,500 a pop, and having to use it on an Win PC- could
be prohibitive...

Rich


--- sle...@dn...,
UNEXPECTED_DATA_AFTER_ADDRESS@.SYNTAX-ERROR. wrote:

> 
> Yes, it looks like "Mac OS Extended" (HSF+ I think).
> 
> Can you recommend any other programs that will read
> deleted files off that type of file system?
> 
> The only thing I've been able to find so far is:
> VirtualLab Data Recovery 3.7.9
> http://www.macupdate.com/info.php/id/10031
> which looks to be $99 per 1GB recovered--to much for
> me.
> 
> Thanks, 
> Paul
> 
> 
> 
> -----Original Message-----
> From: Brian
> Sent: Sunday, January 09, 2005 11:06 AM
> Cc: sle...@li...
> Subject: Re: [sleuthkit-users] sleuthkit1.73 install
> prob MAC OS X
> 10.3.6
> 
> 
> 
> On Jan 7, 2005, at 5:38 PM, sle...@dn...
> wrote:
> 
> >
> > First off, I'm using Sleuthkit/Autopsy browser to
> try to determine if 
> > someone deleted files off a iMac with Mac OS
> 8.5/8.6 installed--is 
> > this possible?
> 
> TSK/Autopsy does not support the HFS+ file system,
> so they will 
> probably not do what you need.
> 
> > Installed on the Sleuthkit/Autopsy working hard
> drive is:
> > Mac OS X 10.3.6 (upgraded from 10.3.2)
> >
> > I tried installing XCode Tools 1.1, but after
> install it said there 
> > were errors and to try re-installing, so I
> installed the 
> > gcc2.95.2.pkg, gcc3.1.pkg packages separately,
> successfully.  
> > gcc3.3.pkg says, "gcc3.3 cannot be installed on
> this computer."
> 
> I think you should try to get XCode working if you
> want to compile it.  
> I have never installed gcc directly, but according
> to Seth it may not 
> include the header files that you need. So, I would
> try to get XCode 
> working, but it may not even be what you need if you
> need to analyze 
> HFS.
> 
> brian
> 
> 
> 
>
-------------------------------------------------------
> The SF.Net email is sponsored by: Beat the
> post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt
> from ThinkGeek.
> It's fun and FREE -- well,
> almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> sleuthkit-users mailing list
>
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
> 

Re: [sleuthkit-users] Autopsy Case Management Gripes

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

On Jan 18, 2005, at 6:53 AM, John Edwards wrote:

> Even as a completely new user to Autopsy I found the
> case management side simple enough to understand and
> use.
>
> What I found a little tricky was the actual imaging
> process itself.  What would have been useful would
> have been a utility that provided a 'suggested' dd
> command line for imaging a disk.  In other words, take
> the simple but very common situation of an
> investigator just hanging a copy of the drive to be
> investigated onto his system - in Autopsy you could
> browse or pick the physical drive or partition and
> Autopsy would  suggest a suitable command line for
> making an image of it and provide a suitable mount
> command line for it.

Fortunately, there are starting to be more interfaces to 'dd' to make 
the process easier.  There are AIR and GRAB:

AIR:
http://air-imager.sourceforge.net/

GRAB:
http://www.e-fense.com/helix/index.html

I haven't actually used either, but I know of people that have.

> One other suggestion (not to do with case management)
> that would have saved me loads of time recently is
> having an extra button on the key word search results
> screen in Autopsy.  The extra button would begin a
> batch process that would look up the filename (and
> extension) of every hit and put the filename next to
> each hit.  This would save loads of time because if
> you are most interested in say Word Docs you could in
> the first instance only look at those hits that are
> word documents.

That is actually a fairly easy update.  I can add that to the todo list.

> One other thing, a facility whereby you could do a
> second (and perhaps a third, fourth ..) keyword search
> but only just the results of an initial keyword search
> would be useful.  It would get round those situations
> where you want to find files that have word1 AND word2
> And possibly word3 in them (which I don't know whether
> it is possible to set up as a regular expression).

That can't be easily done until logical file searching is added.

> PS, I am not griping :), I think it is a great
> programme.

no problem.  I like knowing what people want.  I'm not really an 
interface programmer, so I need all of the help that I can get.

brian
  

[sleuthkit-users] Athlon64 exam machine Q????

[Rich T. <te...@ap...>]

Howdy folks,

Quick question.  Would there be any issues, or
drawbacks to imaging and examning a WinXP drive on an
Athlon64 examination machine???  Just built a new
machine, and was thinking about playing with the
Sluethkit and Autopsy on it.

The OS is Suse 9.2.

Any odd settings regarding the odd sector issue, or
was that fixed with the 2.6 kernel???

Thanks in advance,
Rich Thompson, EnCE
Applied Forensics, LLC
www.apfor.com

Re: [sleuthkit-users] Autopsy Case Management Gripes

[John E. <es...@ya...>]

Even as a completely new user to Autopsy I found the
case management side simple enough to understand and
use.

What I found a little tricky was the actual imaging
process itself.  What would have been useful would
have been a utility that provided a 'suggested' dd
command line for imaging a disk.  In other words, take
the simple but very common situation of an
investigator just hanging a copy of the drive to be
investigated onto his system - in Autopsy you could
browse or pick the physical drive or partition and
Autopsy would  suggest a suitable command line for
making an image of it and provide a suitable mount
command line for it.

I know there are quite a few imaging tools out there
but for someone completely new to this area this 
facility would help to get things moving. This stage
of course is really one step before case management as
 defined in Autopsy at the moment, but data gleaned at
 this stage eg paths to image files, image filenames,
mount commands etc could obviously be automatically 
incorporated into the case management side of Autopsy.

On the issue of whether to have a database at the
backend of the case management I think it would depend
on what database you had in mind.  Ideally you would 
want a db that was transparent to the user,  ie no
maintenance or setup.  Something like mysql might add
quite a hit to the installation / maintenance overhead
 for the user and of course it is something else that
could potentially go wrong.

One other suggestion (not to do with case management) 
that would have saved me loads of time recently is 
having an extra button on the key word search results 
screen in Autopsy.  The extra button would begin a 
batch process that would look up the filename (and
extension) of every hit and put the filename next to
each hit.  This would save loads of time because if
you are most interested in say Word Docs you could in
the first instance only look at those hits that are
word documents.  Taking it a stage further the results
could be displayed in a navigable tree form with each
branch representing a different file type.  At the
moment you have to visit every hit and manually
'click' the MFT link to get the filename and type.  I
know there would be a time overhead in a batch process
like this but at least it would all be done non
interactively (ie you  can go for some lunch while
it's all happening). 

One other thing, a facility whereby you could do a
second (and perhaps a third, fourth ..) keyword search
but only just the results of an initial keyword search
would be useful.  It would get round those situations
where you want to find files that have word1 AND word2
And possibly word3 in them (which I don't know whether
it is possible to set up as a regular expression).

PS, I am not griping :), I think it is a great
programme.

Cheers,
Paul.










 --- Brian Carrier <ca...@sl...> wrote: 
> I'm looking for input and suggestions.   TSK v2 now
> supports disk 
> images, split images, and will soon support other
> formats.  It also 
> autodetects the file system and partition types (I
> really should have 
> done that a long time ago).  Now I need to redo the
> case management 
> part of autopsy to work these features in.  While I
> am at it, I want to 
> know what people hate about the case management or
> any suggestions that 
> people have to make it better.
> 
> The new basic design will be that you give the path
> to the 
> disk/partition image and Autopsy will identify the
> image type and what 
> file systems are in a disk image.  You can change
> the settings and add 
> a known MD5 and then the image will be imported.  
> You will also be 
> able to manually define the locations of partitions.
> 
> I am planning on having a "recent" list on the front
> page that allows 
> you to bypass the Case and Host opening.
> 
> Any ideas, suggestions, or opinions?
> 
> brian
> 
> 
> 
>
-------------------------------------------------------
> The SF.Net email is sponsored by: Beat the
> post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt
> from ThinkGeek.
> It's fun and FREE -- well,
> almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> sleuthkit-users mailing list
>
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>  


	
	
		
___________________________________________________________ 
ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

Re: [sleuthkit-users] Autopsy Case Management Gripes

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

Autopsy is browser-based because I only recently started to learn how 
to develop "real" GUIs.  HTML was quick and dirty.  The original one 
was Apache-based, but that was a pain for installation.  I agree that a 
backend database would be useful and potentially faster, but there are 
again many installation issues and complications. From what I 
understand, this is what pyFlag is doing.

As it stands now, you can have multiple investigators working on the 
same system.  There is no data sharing though.  I.e. the notes from one 
investigator are not shared with another.  This could be changed so 
that all notes go to a common location and the note identifies which 
person created it.  This is an easy change.

brian




On Jan 12, 2005, at 6:22 PM, Paul Stillwell wrote:

> Hi Brian,
>
> Thanks for asking!  Although my suggestion may not seem directly 
> related to
> workflow, when you think about a team of investigators, their 
> collaboration
> and the ability to audit the actions of each investigator, it could be
> useful.  Therefore, I toss it into the ring for discussion.  It is one 
> of the
> things that has always made me wonder, "why wasn't it done this way?"  
> and
> their could be some good reasons for it :-)
>
> 	Autopsy uses a browser based UI.  However, it is designed to be 
> primarily a
> single user application.  Why not add multi-user support in order to
> facilitate the sharing of high-performance hardware?  It could have a 
> huge
> impact on the productivity of a group of investigators if Autopsy ran 
> more as
> a server application.  This may require some drastic re-design of the
> application itself perhaps rewriting it for Apache & PHP which would 
> also
> facilitate (necessitate?) the addition of MySQL (maybe something 
> lighter?)
> for database functionality.  I could see this being a benefit 
> particularly
> for searching timelines & strings, and storing a user's favorite 
> queries etc.
>
> 	Would it be faster?  I don't know.  But it allows a more distributed
> architecture.  Sometimes the use of databases and extra layers of 
> stuff can
> add more delay, complexity and administrivia than the perceived 
> benefits that
> make them worthwhile.
>
> 	This suggestion may not be as easy to implement as it is to type in an
> email ;-)  It would most certainly make things more challenging to get 
> the
> application up and running.  One of the things I like the most about
> TSK/Autopsy is the ease with which installation is performed.
>
> Paul
>
> On Wednesday 12 January 2005 14:36, Brian Carrier wrote:
>> I'm looking for input and suggestions.   TSK v2 now supports disk
>> images, split images, and will soon support other formats.  It also
>> autodetects the file system and partition types (I really should have
>> done that a long time ago).  Now I need to redo the case management
>> part of autopsy to work these features in.  While I am at it, I want 
>> to
>> know what people hate about the case management or any suggestions 
>> that
>> people have to make it better.
>>
>> The new basic design will be that you give the path to the
>> disk/partition image and Autopsy will identify the image type and what
>> file systems are in a disk image.  You can change the settings and add
>> a known MD5 and then the image will be imported.   You will also be
>> able to manually define the locations of partitions.
>>
>> I am planning on having a "recent" list on the front page that allows
>> you to bypass the Case and Host opening.
>>
>> Any ideas, suggestions, or opinions?
>>
>> brian
>>
>>
>>
>> -------------------------------------------------------
>> The SF.Net email is sponsored by: Beat the post-holiday blues
>> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
>> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
>> _______________________________________________
>> sleuthkit-users mailing list
>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>> http://www.sleuthkit.org

Re: [sleuthkit-users] Autopsy Case Management Gripes

[Paul S. <pa...@vn...>]

Hi Brian,

Thanks for asking!  Although my suggestion may not seem directly related to=
=20
workflow, when you think about a team of investigators, their collaboration=
=20
and the ability to audit the actions of each investigator, it could be=20
useful.  Therefore, I toss it into the ring for discussion.  It is one of t=
he=20
things that has always made me wonder, "why wasn't it done this way?"  and=
=20
their could be some good reasons for it :-)

	Autopsy uses a browser based UI.  However, it is designed to be primarily =
a=20
single user application.  Why not add multi-user support in order to=20
facilitate the sharing of high-performance hardware?  It could have a huge=
=20
impact on the productivity of a group of investigators if Autopsy ran more =
as=20
a server application.  This may require some drastic re-design of the=20
application itself perhaps rewriting it for Apache & PHP which would also=20
facilitate (necessitate?) the addition of MySQL (maybe something lighter?)=
=20
for database functionality.  I could see this being a benefit particularly=
=20
for searching timelines & strings, and storing a user's favorite queries et=
c.=20

	Would it be faster?  I don't know.  But it allows a more distributed=20
architecture.  Sometimes the use of databases and extra layers of stuff can=
=20
add more delay, complexity and administrivia than the perceived benefits th=
at=20
make them worthwhile.

	This suggestion may not be as easy to implement as it is to type in an=20
email ;-)  It would most certainly make things more challenging to get the=
=20
application up and running.  One of the things I like the most about=20
TSK/Autopsy is the ease with which installation is performed.

Paul

On Wednesday 12 January 2005 14:36, Brian Carrier wrote:
> I'm looking for input and suggestions.   TSK v2 now supports disk
> images, split images, and will soon support other formats.  It also
> autodetects the file system and partition types (I really should have
> done that a long time ago).  Now I need to redo the case management
> part of autopsy to work these features in.  While I am at it, I want to
> know what people hate about the case management or any suggestions that
> people have to make it better.
>
> The new basic design will be that you give the path to the
> disk/partition image and Autopsy will identify the image type and what
> file systems are in a disk image.  You can change the settings and add
> a known MD5 and then the image will be imported.   You will also be
> able to manually define the locations of partitions.
>
> I am planning on having a "recent" list on the front page that allows
> you to bypass the Case and Host opening.
>
> Any ideas, suggestions, or opinions?
>
> brian
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

[sleuthkit-users] Autopsy Case Management Gripes

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

I'm looking for input and suggestions.   TSK v2 now supports disk 
images, split images, and will soon support other formats.  It also 
autodetects the file system and partition types (I really should have 
done that a long time ago).  Now I need to redo the case management 
part of autopsy to work these features in.  While I am at it, I want to 
know what people hate about the case management or any suggestions that 
people have to make it better.

The new basic design will be that you give the path to the 
disk/partition image and Autopsy will identify the image type and what 
file systems are in a disk image.  You can change the settings and add 
a known MD5 and then the image will be imported.   You will also be 
able to manually define the locations of partitions.

I am planning on having a "recent" list on the front page that allows 
you to bypass the Case and Host opening.

Any ideas, suggestions, or opinions?

brian

[sleuthkit-users] Mac OS Extended (HSF+)

[<sle...@dn...>]

Yes, it looks like "Mac OS Extended" (HSF+ I think).

Can you recommend any other programs that will read deleted files off that type of file system?

The only thing I've been able to find so far is:
VirtualLab Data Recovery 3.7.9
http://www.macupdate.com/info.php/id/10031
which looks to be $99 per 1GB recovered--to much for me.

Thanks, 
Paul



-----Original Message-----
From: Brian
Sent: Sunday, January 09, 2005 11:06 AM
Cc: sle...@li...
Subject: Re: [sleuthkit-users] sleuthkit1.73 install prob MAC OS X
10.3.6



On Jan 7, 2005, at 5:38 PM, sle...@dn... wrote:

>
> First off, I'm using Sleuthkit/Autopsy browser to try to determine if 
> someone deleted files off a iMac with Mac OS 8.5/8.6 installed--is 
> this possible?

TSK/Autopsy does not support the HFS+ file system, so they will 
probably not do what you need.

> Installed on the Sleuthkit/Autopsy working hard drive is:
> Mac OS X 10.3.6 (upgraded from 10.3.2)
>
> I tried installing XCode Tools 1.1, but after install it said there 
> were errors and to try re-installing, so I installed the 
> gcc2.95.2.pkg, gcc3.1.pkg packages separately, successfully.  
> gcc3.3.pkg says, "gcc3.3 cannot be installed on this computer."

I think you should try to get XCode working if you want to compile it.  
I have never installed gcc directly, but according to Seth it may not 
include the header files that you need. So, I would try to get XCode 
working, but it may not even be what you need if you need to analyze 
HFS.

brian

Re: [sleuthkit-users] filesystem recovery using sleuthkit

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

On Jan 10, 2005, at 11:24 AM, Jim Cromie wrote:

> Brian Carrier wrote:
>
>>
>> On Jan 9, 2005, at 12:50 PM, Jim Cromie wrote:
>>
>>> Qs:
>>
>
>>> is the choice of filesystem completely dictated by the 
>>> root-directory ?
>>
>>
>> The other way around.  Each file system has its own way of storing 
>> the  contents of a directory and FAT and NTFS are MUCH different.
>>
> poorly stated question.  In your tool, which will work on an image 
> file, there is no
> partition type.  So Im assuming that the code looks for magic bytes in 
> 1st few sectors
> of the image.  Id expect that magic would be part of the root 
> directory.

Nope.  Magic / sigs are all in the boot sector / superblock in the 
first few sectors.  The root directory has the same structure as a 
normal directory.

> So rephrasing;  does your tool have any mechanizm to look for a backup 
> superblock ?
> (they exist in ext2 anyway)

The current version does not.  I am currently adding it to v2.

brian

Re: [sleuthkit-users] filesystem recovery using sleuthkit

[Jim C. <jc...@di...>]

Brian Carrier wrote:

>
> On Jan 9, 2005, at 12:50 PM, Jim Cromie wrote:
>
>> Qs:
>

>> is the choice of filesystem completely dictated by the root-directory ?
>
>
> The other way around.  Each file system has its own way of storing 
> the  contents of a directory and FAT and NTFS are MUCH different.
>
poorly stated question.  In your tool, which will work on an image file, 
there is no
partition type.  So Im assuming that the code looks for magic bytes in 
1st few sectors
of the image.  Id expect that magic would be part of the root directory.

So rephrasing;  does your tool have any mechanizm to look for a backup 
superblock ?
(they exist in ext2 anyway)


>> is the choice overridable ?
>> is there a reason its not automatic - since it seems to reject the  
>> 'wrong' choices ?
>
>
> Autopsy does some sanity checks when you import the image so that you  
> can more quickly determine when you select the wrong one (I am  
> currently working on autodetect for the next version).   

Ill check for the sourceforge CVS

> FAT and NTFS  (and partition tables) are difficult because they all 
> use the same  signature value in the last two bytes of the first 
> sector.  FYI -  choosing just fat will autodetect which type of FAT.
>
>> is it possible to not care ?
>> in my case, I hope to find that the vast majority of directories
>> look to be uncorrupted - ie the directory entries are legal,
>> and point to files that match whatever metadata is stored in the  
>> directory entry itself,
>> and link to each other properly.
>
>
> I have no clue what happened during the Windows recovery stuff.  TSK 
> /  Autopsy does not fix damaged file systems.  It only shows what is  
> there.  I think you need to look into some FAT/NTFS fixing tools.
>
:-(  my opensource options appear quite limited.
anybody know of anything that *might* help ?

> Just to confirm, you did import the partition image and not the disk  
> image right?  The current version supports only partition images.  
> The  '$Data not found while loading the MFT' is sometimes found when 
> you try  to process a disk image as NTFS (because they share the same 
> magic  value).
>
>
yes - I double checked that when I saw the NTFS 'superblock' in there.
the script was definitely using /dev/hda2

for my $chunk (0..60) {
    print "dd bs=1K if=/dev/hda2 of=part.$chunk skip=${chunk}M count=1M\n";
    print `dd bs=1K if=/dev/hda2 of=part.$chunk skip=${chunk}M count=1M`;
    print `ls`;
}

At this point, I think Im gonna try slicing off that FAT12 chunk,
much like Id do if the big image were the whole of /hda.

If it works, I will *certainly* report back.

>
> brian
>
thanks
Jim Cromie

Re: [sleuthkit-users] filesystem recovery using sleuthkit

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

On Jan 9, 2005, at 12:50 PM, Jim Cromie wrote:
> Qs:
>
> is it common on MS OSs that partition type and fs type are different ?

No.  Windows uses the partition type to determine if it will mount the  
partition and how to mount it.

> is the choice of filesystem completely dictated by the root-directory ?

The other way around.  Each file system has its own way of storing the  
contents of a directory and FAT and NTFS are MUCH different.

> is the choice overridable ?
> is there a reason its not automatic - since it seems to reject the  
> 'wrong' choices ?

Autopsy does some sanity checks when you import the image so that you  
can more quickly determine when you select the wrong one (I am  
currently working on autodetect for the next version).   FAT and NTFS  
(and partition tables) are difficult because they all use the same  
signature value in the last two bytes of the first sector.  FYI -  
choosing just fat will autodetect which type of FAT.

> is it possible to not care ?
> in my case, I hope to find that the vast majority of directories
> look to be uncorrupted - ie the directory entries are legal,
> and point to files that match whatever metadata is stored in the  
> directory entry itself,
> and link to each other properly.

I have no clue what happened during the Windows recovery stuff.  TSK /  
Autopsy does not fix damaged file systems.  It only shows what is  
there.  I think you need to look into some FAT/NTFS fixing tools.

Just to confirm, you did import the partition image and not the disk  
image right?  The current version supports only partition images.  The  
'$Data not found while loading the MFT' is sometimes found when you try  
to process a disk image as NTFS (because they share the same magic  
value).


> wrt:
> Calculating MD5 of images/whole.img (this could take a while)
> +----+----+----+----+----+----+----+----+----+----+----+----+----+---- 
> +-
>
> it would be nice to have some estimate of ' a while',
> ie how big the ticks are,

The ticks are every few seconds, not a percentage.  Percentage would be  
nice, but difficult given the current design.

brian

[sleuthkit-users] filesystem recovery using sleuthkit

[Jim C. <jc...@di...>]

Im trying to recover contents of a 60GB Windows XP installation
after a grub accident.

A short 'how I got here' follows, then the Questions.

I recently screwed up (technical jargon) my dads winXP box
while trying to put grub on a usb-drive.
(grub went onto /dev/hda, but linux was on /dev/sda,
so it wouldnt boot anything)

I recovered using the recovery disk, tried the repair option:
fixmbr - to restore the MBR, and fixboot (I think)

These tools apparently trashed the root of C:\,
they showed me a mostly empty root-dir, with 4 (empty)
files with names that were evidently unreadable by the OS
(they were represnted by ?, all 4 of them)

with a knoppix disk and a 3 line perl prog,
I took 1GB at a time off it, and NFS'd it to my laptop,
then onto the USB drive  (knoppix dd wouldnt handle > 2GB files)
(knoppix 3.6 wouldnt mount the usb directly - some versioning
prob w the usb-* modules)

I catted all the 1gb chunks together, and have started autopsy-2.03
and sleuthkit-1.73 on it.

Evidence Locker: /mnt/u2/forensics
Start Time: Sun Jan  9 09:32:31 2005
Remote Host: localhost
Local Port: 9999

Open an HTML browser on the remote host and paste this URL in it:

    http://localhost:9999/autopsy

Keep this process running and use <ctrl-c> to exit
..//bin/fsstat: $Data not found while loading the MFT
..//bin/fsstat: Invalid FAT32 image (numroot != 0)
..//bin/fsstat: Invalid FAT32 image (numroot != 0)
..//bin/fsstat: $Data not found while loading the MFT
..//bin/fsstat: Invalid FAT32 image (numroot != 0)
..//bin/fsstat: getFAT: return FAT16 cluster too large


fsstat seems to be having trouble with this partition, and its unclear
to me what kind of filesystem is *really* there.

fdisk told me it was NTFS/HPFS
mount told me it was vfat
autopsy thinks its FAT16, would *not* accept choice of NTFS or FAT32

it appears that this is due to the root directory, which appears to
have been overwritten by the MS tools.  Ive inspected other
parts of the 60 GB, they appear to have the original content.

Qs:

is it common on MS OSs that partition type and fs type are different ?

is the choice of filesystem completely dictated by the root-directory ?
is the choice overridable ?
is there a reason its not automatic - since it seems to reject the 
'wrong' choices ?

is it possible to not care ?
in my case, I hope to find that the vast majority of directories
look to be uncorrupted - ie the directory entries are legal,
and point to files that match whatever metadata is stored in the 
directory entry itself,
and link to each other properly.
IOW, if 59.9 GB of data look consistent with each other,
then clearly the root folder is hosed, and is only thing to fix.


wrt:
Calculating MD5 of images/whole.img (this could take a while)
+----+----+----+----+----+----+----+----+----+----+----+----+----+----+-

it would be nice to have some estimate of ' a while',
ie how big the ticks are,



my other attempts to extract some of the original filesystem
have also run afoul on this FAT16 choice:

..//bin/ils: getFAT: return FAT16 cluster too large
..//bin/dls: getFAT: return FAT16 cluster too large


Im gonna continue poking, 1st thru autopsy, then the sleuthkit tools,
but Im also contemplating trying to remove/zero out the root directory
so that something else in the partition has a chance to influence the mount.
Please advise me on this course of action b4 I do something (else) stupid

tia
jimc

Re: [sleuthkit-users] sleuthkit1.73 install prob MAC OS X 10.3.6

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

On Jan 7, 2005, at 5:38 PM, sle...@dn... wrote:

>
> First off, I'm using Sleuthkit/Autopsy browser to try to determine if 
> someone deleted files off a iMac with Mac OS 8.5/8.6 installed--is 
> this possible?

TSK/Autopsy does not support the HFS+ file system, so they will 
probably not do what you need.

> Installed on the Sleuthkit/Autopsy working hard drive is:
> Mac OS X 10.3.6 (upgraded from 10.3.2)
>
> I tried installing XCode Tools 1.1, but after install it said there 
> were errors and to try re-installing, so I installed the 
> gcc2.95.2.pkg, gcc3.1.pkg packages separately, successfully.  
> gcc3.3.pkg says, "gcc3.3 cannot be installed on this computer."

I think you should try to get XCode working if you want to compile it.  
I have never installed gcc directly, but according to Seth it may not 
include the header files that you need. So, I would try to get XCode 
working, but it may not even be what you need if you need to analyze 
HFS.

brian

Re: [sleuthkit-users] fls simply reports usage information?

[Seth A. <sa...@im...>]

Brian, thanks for the fantastic program. Autopsy made Sleuthkit very
easy to use, and Sleuthkit did a great job reading files off my
brother's formatted CF card. Very cool. Thanks.

Re: [sleuthkit-users] sleuthkit1.73 install prob MAC OS X 10.3.6

[Seth A. <sa...@im...>]

On Fri, Jan 07, 2005 at 10:38:04PM -0000, sle...@dn... wrote:
> dnmacs-Computer:/Volumes/misc/sleuthkit-1.73 dnmac$ make CC=3Dgcc2
> cd src/misc; make "CC=3Dgcc2" MAKELEVEL=3D
> gcc2 -DDARWIN -DVER=3D\"1.73\" -O -Wall -g   -c -o mymalloc.o mymalloc.c
> mymalloc.c:49: header file 'stdlib.h' not found
> mymalloc.c:50: header file 'unistd.h' not found
> mymalloc.c:51: header file 'string.h' not found
> cpp-precomp: warning: errors during smart preprocessing, retrying in basi=
c mode
> make: *** [mymalloc.o] Error 1
> make: *** [defs] Error 2
> make: *** [no-perl] Error 2
> dnmacs-Computer:/Volumes/misc/sleuthkit-1.73 dnmac$=20
>=20
> And when I run "make CC=3Dgcc3" I get:
> ( & make CC=3D/Volumes/osx/usr/bin/gcc2 )
>=20
> dnmacs-Computer:/Volumes/misc/sleuthkit-1.73 dnmac$ make CC=3Dgcc3
> cd src/misc; make "CC=3Dgcc3" MAKELEVEL=3D
> gcc3 -DDARWIN -DVER=3D\"1.73\" -O -Wall -g   -c -o mymalloc.o mymalloc.c
> mymalloc.c:49: header file 'stdlib.h' not found
> mymalloc.c:50: header file 'unistd.h' not found
> mymalloc.c:51: header file 'string.h' not found
> cpp-precomp: warning: errors during smart preprocessing, retrying in basi=
c mode
> make: *** [mymalloc.o] Error 1
> make: *** [defs] Error 2
> make: *** [no-perl] Error 2
> dnmacs-Computer:/Volumes/misc/sleuthkit-1.73 dnmac$=20

It appears that your GCC can't find standard system headers. Try to find
the stdlib.h, unistd.h, and string.h headers. (The finder has a find
command you can use; or you can run this command in the terminal:
find / -name stdlib.h -print
)

If you don't have these files, then you'll need to get them, probably
=66rom Apple. They aren't a part of GCC proper, so I doubt that they would
be included in the gcc2 or gcc3 packages.

If you do have these files, then GCC hasn't found them. In the source
code, these files are specified like this:
  #include <stdlib.h>
  #include <unistd.h>
  #include <string.h>
The compiler has a "search path" to try to find these files -- you can
modify the search path with -I/path/to/add/to/the/search/path. So, if
your header files are located in /usr/include/macos/, then you might
try running:
make "CC=3Dgcc -I/usr/include/macos/"

I hope this helps.

[sleuthkit-users] sleuthkit1.73 install prob MAC OS X 10.3.6

[<sle...@dn...>]

First off, I'm using Sleuthkit/Autopsy browser to try to determine if someone deleted files off a iMac with Mac OS 8.5/8.6 installed--is this possible?

Installed on the Sleuthkit/Autopsy working hard drive is:
Mac OS X 10.3.6 (upgraded from 10.3.2)

I tried installing XCode Tools 1.1, but after install it said there were errors and to try re-installing, so I installed the gcc2.95.2.pkg, gcc3.1.pkg packages separately, successfully.  gcc3.3.pkg says, "gcc3.3 cannot be installed on this computer."

1 drive, 3 partitions:

/dev/disk0s11 on /Volumes/os8-9 (local) [ has 8.6, 9.2.2 installed ]
/dev/disk0s13 on /Volumes/osx (local, journaled)  [ has OS X 10.3.6 installed ]
/dev/disk0s15 on /Volumes/misc (local, journaled)

It looks like gcc, gcc2, and gcc3 are in "/Volumes/osx/usr/bin/"

Sleuthkit-1.73 is installed on:
	/Volumes/misc/sleuthkit-1.73

When I run "make" under "/Volumes/misc/sleuthkit-1.73" I get:

dnmacs-Computer:/Volumes/misc/sleuthkit-1.73 dnmac$ make
cd src/misc; make "CC=gcc" MAKELEVEL=
gcc -DDARWIN -DVER=\"1.73\" -O -Wall -g   -c -o mymalloc.o mymalloc.c
make: gcc: Command not found
make: *** [mymalloc.o] Error 127
make: *** [defs] Error 2
make: *** [no-perl] Error 2
dnmacs-Computer:/Volumes/misc/sleuthkit-1.73 dnmac$ 

When I run "make CC=cc" I get:  same, except "make: cc: Command not found"

When I run "make CC=gcc" I get: same, except "make: gcc: Command not found"

When I run "make CC=gcc2" I get:
( & make CC=/Volumes/osx/usr/bin/gcc2 )

dnmacs-Computer:/Volumes/misc/sleuthkit-1.73 dnmac$ make CC=gcc2
cd src/misc; make "CC=gcc2" MAKELEVEL=
gcc2 -DDARWIN -DVER=\"1.73\" -O -Wall -g   -c -o mymalloc.o mymalloc.c
mymalloc.c:49: header file 'stdlib.h' not found
mymalloc.c:50: header file 'unistd.h' not found
mymalloc.c:51: header file 'string.h' not found
cpp-precomp: warning: errors during smart preprocessing, retrying in basic mode
make: *** [mymalloc.o] Error 1
make: *** [defs] Error 2
make: *** [no-perl] Error 2
dnmacs-Computer:/Volumes/misc/sleuthkit-1.73 dnmac$ 

And when I run "make CC=gcc3" I get:
( & make CC=/Volumes/osx/usr/bin/gcc2 )

dnmacs-Computer:/Volumes/misc/sleuthkit-1.73 dnmac$ make CC=gcc3
cd src/misc; make "CC=gcc3" MAKELEVEL=
gcc3 -DDARWIN -DVER=\"1.73\" -O -Wall -g   -c -o mymalloc.o mymalloc.c
mymalloc.c:49: header file 'stdlib.h' not found
mymalloc.c:50: header file 'unistd.h' not found
mymalloc.c:51: header file 'string.h' not found
cpp-precomp: warning: errors during smart preprocessing, retrying in basic mode
make: *** [mymalloc.o] Error 1
make: *** [defs] Error 2
make: *** [no-perl] Error 2
dnmacs-Computer:/Volumes/misc/sleuthkit-1.73 dnmac$ 

I did start the Autopsy 2.03 install after this, but Autopsy install said:
Enter the directory where you installed it:
/Volumes/misc/sleuthkit-1.73      
The Sleuth Kit was not found (try again):

So I guess Sleuthkit didn't get installed.

Can anyone tell me what's going wrong?

After "make" works successfully, is there anything else I need to do in Sleuthkit, or can I go ahead and install Autopsy?

Thanks for your help,

Paul

Re: [sleuthkit-users] fls simply reports usage information?

[Seth A. <sa...@im...>]

On Fri, Jan 07, 2005 at 02:27:52AM -0500, Brian Carrier wrote:
> Interesting.  I have actually spent the last day cleaning up all of the=
=20
> variables (version 2 is on its way - I am finishing up support for disk=
=20
> images!) and I fixed those instances.  I hadn't heard of them causing=20
> problems before.  It must be a change in libc.

Oooh, I like the sound of upcoming version 2. :)

I wish I knew why it causes problems on my ppc linux but not on x86
linux or ppc mac os x. If you find out, please let me know. :) (I'm
honestly a bit surprised it worked fine on x86 linux, but I've seen
odder..)

> Yea, the indenting (especially of the switches) has gotten out of hand.=
=20
>  I have changed editors a couple of times and that has made it worse. =20
> I applied indent to the v2 tree.

Cool. :) Changing editors can do that.

Thanks again.

Re: [sleuthkit-users] fls simply reports usage information?

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

On Jan 6, 2005, at 11:57 PM, Seth Arnold wrote:

> On Thu, Jan 06, 2005 at 09:41:57AM -0500, Brian Carrier wrote:
>> I just fixed that so that all 'usage' statements have an error.  There
>
> Brian, thank you for your quick fix. It made it easy to find the bug. 
> :)
>
> The problem is that getopt() will return a character in the normal case
> and a negative integer in the failure case.

Interesting.  I have actually spent the last day cleaning up all of the 
variables (version 2 is on its way - I am finishing up support for disk 
images!) and I fixed those instances.  I hadn't heard of them causing 
problems before.  It must be a change in libc.

> Thanks also for showing consistent discipline in your programs -- it
> was very easy to track down a few more programs that exhibit this 
> error.
> Attached is a patch that will correct these errors. (Please forgive me 
> my
> indulgence of re-indenting a handful of lines in the switch statement. 
> I
> found the original a little difficult to read. If you'd rather keep the
> indenting the way it was, it should be easy to undo my changes by 
> hand. :)

Thanks.

Yea, the indenting (especially of the switches) has gotten out of hand. 
  I have changed editors a couple of times and that has made it worse.  
I applied indent to the v2 tree.

brian

Re: [sleuthkit-users] fls simply reports usage information?

[Seth A. <sa...@im...>]

On Thu, Jan 06, 2005 at 09:41:57AM -0500, Brian Carrier wrote:
> I just fixed that so that all 'usage' statements have an error.  There 

Brian, thank you for your quick fix. It made it easy to find the bug. :)

The problem is that getopt() will return a character in the normal case
and a negative integer in the failure case. Because 'ch' was declared
as a char, it does not have sufficient range to accept all character
values _and_ the error return value -1. (This was made pretty clear when
I modified your default: case to print the character: ÿ. I've learned
to fear this character over the years.. it is 0xFF, 255, or (unsigned
char) -1.)

Thanks also for showing consistent discipline in your programs -- it
was very easy to track down a few more programs that exhibit this error.
Attached is a patch that will correct these errors. (Please forgive me my
indulgence of re-indenting a handful of lines in the switch statement. I
found the original a little difficult to read. If you'd rather keep the
indenting the way it was, it should be easy to undo my changes by hand. :)

Thanks for taking the time to help find the problem. Much appreciated.

[sleuthkit-users] fls simply reports usage information

[Seth A. <sa...@im...>]

On Thu, Jan 06, 2005 at 05:43:22AM -0500, SecMan wrote:
> Did you dump the image as a drive letter (partition) or as a raw device?

/dev/sda1 on Linux systems is a partition image. I haven't seen any
documentation that suggests that that TSK would handle disk images
better than just the filesystem images. Did I do the wrong thing?

Thanks

Re: [sleuthkit-users] fls simply reports usage information?

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

On Jan 6, 2005, at 12:54 AM, Seth Arnold wrote:
>
>> Are you sure you have a partition image and not a disk image?  What is
>> the error message before the usage information is displayed. There
>> should be one line that explains why it gave an error.
>
> Sadly, there isn't even the one-liner error message. :( I've appended
> output near the end.

I just fixed that so that all 'usage' statements have an error.  There 
were a couple that do not.  I've updated the src/fstools/fls.c file 
with more error messages (based on if there are too few or too many 
arguments).  Try it and see if it gives more details.  The command you 
are using is standard, so I do not know why it is giving problems.

> I'm positive I have a partition image; I still have that shell open,
> and it's history command shows that I copied /dev/sda1 -- the first
> partition on the first scsi disk. (Linux supports Sandisk by emulating
> a SCSI drive.)

Ok.

> (While I don't know filesystem internals well enough to tell from the
> contents of what I've got, maybe you do. So I've appended that near the
> end as well. :)

It looks legit.

>
>> Hmm.  I do not know of anyone that has used them under Debian on an
>> iBook.  There could be an endian ordering issue with the package.  You
>> may want to try directly from the source.
>
> "Try directly from the source" -- do you mean try running autopsy and
> TSK on my brother's OS X machine? Or compiling TSK from source? I
> tried compiling TSK from Debian's source on machine with identical
> results. (This shouldn't surprise me. I did it with intentions of being
> able to try suggestions that include source modifications. :) I haven't
> tried running TSK on my brother's OS X machine simply because I've 
> never
> compiled anything on it and didn't want to bother late at night.. :)

I meant to download the tarball from sleuthkit.org and compile it.  Do 
any of the other tools work? It seems that 'fsstat' worked because you 
were able to import the image.  Try to run 'istat -f fat 
/home/sarnold/sandisk.dd 2'.  Also let me know how using the fls.c file 
worked.  When compiling from the source, it will not install itself in 
'/usr/bin/', so make sure you are running the new binaries and not the 
original ones :)

brian

[sleuthkit-users] RE: sleuthkit-users digest, Vol 1 #231 - 1 msg

[SecMan <se...@ta...>]

Did you dump the image as a drive letter (partition) or as a raw device?

-----Original Message-----
From: sle...@li...
[mailto:sle...@li...]On Behalf Of
sle...@li...
Sent: Wednesday, January 05, 2005 11:23 PM
To: sle...@li...
Subject: sleuthkit-users digest, Vol 1 #231 - 1 msg


Send sleuthkit-users mailing list submissions to
	sle...@li...

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
or, via email, send a message with subject or body 'help' to
	sle...@li...

You can reach the person managing the list at
	sle...@li...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of sleuthkit-users digest..."


Today's Topics:

   1. fls simply reports usage information? (Seth Arnold)

--__--__--

Message: 1
Date: Wed, 5 Jan 2005 15:04:55 -0800
From: Seth Arnold <sa...@im...>
To: sle...@li...
Subject: [sleuthkit-users] fls simply reports usage information?


--626OCQS0lFJXe+9/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hello,

I've been trying to use autopsy's interface to the sleuthkit tools to
try to recover information from my brother's sandisk CF card. (_Very_
impressive-looking tools! Job well done on the interface.)

However, I'm stopped very early on by a failing 'fls' command. Autopsy's
file/directory listing interface is clearly not prepared to handle the
usage() output from fls. I used 'strace' to find the arguments to the
fls command, which (as I recall from memory..) looked like this:

  fls -f fat -la -s 0 /path/to/dd/image 2

I tried running fls by hand innumerable times with various permuations
of the arguments like this:

  fls -f fat -la -s 0 /path/to/dd/image 2
  fls -f fat -l -a -s 0 /path/to/dd/image 2
  fls -f fat -la -s0 /path/to/dd/image 2
  fls -f fat -l -a -s0 /path/to/dd/image 2

  fls -f fat -la -s 0 /path/to/dd/image 1
  fls -f fat -l -a -s 0 /path/to/dd/image 1
  fls -f fat -la -s0 /path/to/dd/image 1
  fls -f fat -l -a -s0 /path/to/dd/image 1

  fls -f fat -la -s 0 /path/to/dd/image
  fls -f fat -l -a -s 0 /path/to/dd/image
  fls -f fat -la -s0 /path/to/dd/image
  fls -f fat -l -a -s0 /path/to/dd/image

  fls -f fat -s 0 /path/to/dd/image 2
  fls -f fat -s0 /path/to/dd/image 2

  fls -f fat -s 0 /path/to/dd/image
  fls -f fat -s0 /path/to/dd/image

  fls -f fat /path/to/dd/image 2

  fls -f fat /path/to/dd/image

  fls -f fat -la -s 0 /path/to/dd/image 2 2

Every single attempt _always_ reported the usage statement. :(

I glanced at the fls.c source code, but didn't spot anything obviously
wrong in the main() function.

I'm using the version of sleuthkit as packaged in Debian Unstable on my
G3 iBook. Debian reports the version is 1.73-4. There are no related
bugs filed at bugs.debian.org.

Does anyone have suggestions what to do next? :)

Thanks!

--626OCQS0lFJXe+9/
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB3HKX+9nuM9mwoJkRAsCYAJ4nVmXdRAjimZ2gYo6ENRely4wxNwCeNDvh
Aah13v7j1u/Sje5QjGD2v1Y=
=4LfY
-----END PGP SIGNATURE-----

--626OCQS0lFJXe+9/--



--__--__--

_______________________________________________
sleuthkit-users mailing list
sle...@li...
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users


End of sleuthkit-users Digest