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

Re: [sleuthkit-users] Questions about Sleuthkit

[youcef b. <ybi...@ya...>]

These are my answers given my knowledge of the
product.

> 1) Is there a way to view Autopsy log files from
> within the Autopsy
> interface?  I can load up the log files in the
> browser by going to
> file->open, but is there any way from within the
> actual interface to do it?

No
 
> 2) Are EnCase images supported at all?  I can import
> EnCase images into a
> case, but none of the operations I attempt seem to
> execute correctly.

No. Autopsy (TSK in fact) supports raw image format.
 
> 3) Can a SHA-1 hash be generated when an image is
> imported.  When I import
> an image, I have the option of generating an MD5
> hash, but I don't see
> SHA-1.

You can use sha in TSK but it is no incorporated yet
in Autopsy.
 
> 4) Is there any way to limit searches to files with
> certain extensions, or
> to those in a particular directory?

Not in autopsy. but you have all the tools in TSK to
achieve this. unfortunatrely there is no automated way
to do it.


> 5) Should the regular expresssion:
> 'special[:space:][0-9A-Za-z]*[:space:]access' (I
> don't include the single
> quotes when I enter it in the search box) match the
> string "special test
> access".  I've tried that expression on an image
> that I know contains that
> string, but it doesn't return any matches.  I've
> ensured that the regular
> expression box was checked on the search page, and
> I've tried using
> parenthesis.

your search is vlaid for ASCII text. Make sure that
your text is not in Unicode.
 
> 6) Is it possible to generate reports at a higher
> granularity than files.
> That is, can a report be generated for a host or a
> case that contains
> information about multiple files?  Can notes be
> included in reports?

Autopsy is still weak in the reporting side. it doesnt
generate a decent report, but it does log all the
investigator actions which could be inlcuded in the
report.

 
> 7) Is there any way to dissect and analyze the
> messages/attachments within
> an Outlook (.pst) or a Exchange (.edb) file, or can
> they only be searched
> for text?

TSK and autopsy are file system analysis tool. Here
your are touching on applicaiton analysis layer and
you need to look for other specialsed tools that
achieve it. Open source tools that I know of which can
process pst files are readpst from the debian project.
there is a good article in the forensicfocus which
explains the usage of this tool and other ones related
to email analysis.


Regards

Youcef




	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

[sleuthkit-users] Questions about Sleuthkit

[Ryan P. <rpe...@mi...>]

Greetings,

I have been using Sleuthkit for the last few months, and I have a few
questions that I could not find the answers to in the manual, or in the
mailing list archive.  I aplogize in advance if these issues have already
been addressed in previous posts, but the search function on the sourceforge
archive page does not seem to be functioning.

1) Is there a way to view Autopsy log files from within the Autopsy
interface?  I can load up the log files in the browser by going to
file->open, but is there any way from within the actual interface to do it?

2) Are EnCase images supported at all?  I can import EnCase images into a
case, but none of the operations I attempt seem to execute correctly.

3) Can a SHA-1 hash be generated when an image is imported.  When I import
an image, I have the option of generating an MD5 hash, but I don't see
SHA-1.

4) Is there any way to limit searches to files with certain extensions, or
to those in a particular directory?

5) Should the regular expresssion:
'special[:space:][0-9A-Za-z]*[:space:]access' (I don't include the single
quotes when I enter it in the search box) match the string "special test
access".  I've tried that expression on an image that I know contains that
string, but it doesn't return any matches.  I've ensured that the regular
expression box was checked on the search page, and I've tried using
parenthesis.

6) Is it possible to generate reports at a higher granularity than files.
That is, can a report be generated for a host or a case that contains
information about multiple files?  Can notes be included in reports?

7) Is there any way to dissect and analyze the messages/attachments within
an Outlook (.pst) or a Exchange (.edb) file, or can they only be searched
for text?

Thank you for any answers you can provide,
-Ryan

--
Ryan Persaud
rpe...@mi...
703-983-1275
The MITRE Corporation

Re: [sleuthkit-users] Linux and "unrecognized" sectors

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

Thanks everyone!

Paul

farmer dude wrote:

>Hi Paul,
>
>Linux doesn't access the last odd sector when
>initializing file systems and so the article you read
>probably indicated using Linux to acquire may leave
>the last sector if the count is odd or similar.  
>
>This is true for the 2.4 Linux kernel because the
>block layer uses 1024 and a sector is 512, so it
>cannot be accessed when going through the block layer
>(such as 'dd' does when dumping a device).  The block
>layer was rewritten in the 2.6 kernel so a 2.6 can
>access this last odd sector for those Windows file
>system types that use it.  
>
>A side note, you can happily acquire that sector using
>the 2.4 Linux kernel, too.  Just avoid the block layer
>and use the raw device.  I do this when I need to and
>teach about it in my training classes.  You don't need
>a 2.6 kernel to get the last odd sector.  You only
>need to know what the problem is and how to work
>around it in the 2.4 series kernels.
>
>
>regards,
>
>farmerdude
>
>http://www.farmerdude.com/
>
>
>
>--- Paul Stillwell <pa...@vn...> wrote:
>
>  
>
>>Hello all,
>>
>>    I'm reading some articles and one that I have
>>come across (was 
>>handed to me unfortunately no link) and it says that
>>Linux will not 
>>recognize the last sector of a disk if it has an odd
>>number of sectors.  
>>I had never heard this before and it has prompted a
>>couple of questions.
>>
>>1)  will this affect an image acquired using dd?
>>
>>2)  will it affect Sleuthkit's handling of an image
>>of this drive?
>>
>>Thanks!
>>
>>Paul
>>
>>
>>
>>    
>>
>-------------------------------------------------------
>  
>
>>This SF.net email is sponsored by: Splunk Inc. Do
>>you grep through log files
>>for problems?  Stop!  Download the new AJAX search
>>engine that makes
>>searching your log files as easy as surfing the 
>>web.  DOWNLOAD SPLUNK!
>>
>>    
>>
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
>  
>
>>_______________________________________________
>>sleuthkit-users mailing list
>>
>>    
>>
>https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>  
>
>>http://www.sleuthkit.org
>>
>>    
>>
>
>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam?  Yahoo! Mail has the best spam protection around 
>http://mail.yahoo.com 
>
>  
>

Re: [sleuthkit-users] Linux and "unrecognized" sectors

[farmer d. <far...@ya...>]

Hi Paul,

Linux doesn't access the last odd sector when
initializing file systems and so the article you read
probably indicated using Linux to acquire may leave
the last sector if the count is odd or similar.  

This is true for the 2.4 Linux kernel because the
block layer uses 1024 and a sector is 512, so it
cannot be accessed when going through the block layer
(such as 'dd' does when dumping a device).  The block
layer was rewritten in the 2.6 kernel so a 2.6 can
access this last odd sector for those Windows file
system types that use it.  

A side note, you can happily acquire that sector using
the 2.4 Linux kernel, too.  Just avoid the block layer
and use the raw device.  I do this when I need to and
teach about it in my training classes.  You don't need
a 2.6 kernel to get the last odd sector.  You only
need to know what the problem is and how to work
around it in the 2.4 series kernels.


regards,

farmerdude

http://www.farmerdude.com/



--- Paul Stillwell <pa...@vn...> wrote:

> Hello all,
> 
>     I'm reading some articles and one that I have
> come across (was 
> handed to me unfortunately no link) and it says that
> Linux will not 
> recognize the last sector of a disk if it has an odd
> number of sectors.  
> I had never heard this before and it has prompted a
> couple of questions.
> 
> 1)  will this affect an image acquired using dd?
> 
> 2)  will it affect Sleuthkit's handling of an image
> of this drive?
> 
> Thanks!
> 
> Paul
> 
> 
>
-------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do
> you grep through log files
> for problems?  Stop!  Download the new AJAX search
> engine that makes
> searching your log files as easy as surfing the 
> web.  DOWNLOAD SPLUNK!
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> sleuthkit-users mailing list
>
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [sleuthkit-users] Linux and "unrecognized" sectors

[Eagle I. S. Inc. <in...@ea...>]

Paul,

This is a well discussed, and well solved issue. Look in the archives, or
on linuxforensics yahoo group.

The simplest answer is to use the 2.6 kernel or use a patch for the 2.4
kernel to get around this.

Google is your friend.

And, Sleuthkit won't be affected per se, since it will analyze whatever
you hand to it and quite successfully too.

Niall.





Paul Stillwell wrote:
> Hello all,
>
>     I'm reading some articles and one that I have come across (was
> handed to me unfortunately no link) and it says that Linux will not
> recognize the last sector of a disk if it has an odd number of sectors.
> I had never heard this before and it has prompted a couple of questions.
>
> 1)  will this affect an image acquired using dd?
>
> 2)  will it affect Sleuthkit's handling of an image of this drive?
>
> Thanks!
>
> Paul
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>

[sleuthkit-users] Linux and "unrecognized" sectors

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

Hello all,

    I'm reading some articles and one that I have come across (was 
handed to me unfortunately no link) and it says that Linux will not 
recognize the last sector of a disk if it has an odd number of sectors.  
I had never heard this before and it has prompted a couple of questions.

1)  will this affect an image acquired using dd?

2)  will it affect Sleuthkit's handling of an image of this drive?

Thanks!

Paul

RE: [sleuthkit-users] mp4.raw

[Eagle I. S. I. <in...@ea...>]

Alex, 
 
This following might help: 
 
http://www.mainconcept.com/mpeg_encoder.shtml
 
http://www.canopus.com/products/ProCoderExpress/index.php
 
Niall. 
 
 


  _____  

From: sle...@li...
[mailto:sle...@li...] On Behalf Of Aleksander
Lavrih
Sent: Sunday, January 15, 2006 4:01 PM
To: sle...@li...
Subject: [sleuthkit-users] mp4.raw


Using Autopsy I've got .mp3.raw and mp4.raw files which I can't listen or
see. How can I convert them in usual mp* format? dd?
 
 
Regards,  Alex
 

[sleuthkit-users] mp4.raw

[Aleksander L. <ale...@si...>]

Using Autopsy I've got .mp3.raw and mp4.raw files which I can't listen or
see. How can I convert them in usual mp* format? dd?


Regards,  Alex

Re: [sleuthkit-users] CD Forensics

[farmer d. <far...@ya...>]

Matt,

The early bird gets the bush ...

;)

CDFS is pretty cool at times.  I cover its use in my
training class and include it on my boot CD because of
its usefulness.  It's come in handy a few times.

Happy 2006!

farmerdude


--- mm...@ta... wrote:

> Farmer, you beat me to it, CDFS is covered in our
> Agile Risk Management
> Article on CDR Forensics.
> 
> Good Luck Nico.
> 
> M Shannon
> 
> ----- Original Message -----
> From: farmer dude <far...@ya...>
> Date: Thursday, January 12, 2006 5:22 pm
> Subject: Re: [sleuthkit-users] CD Forensics
> 
> > Hi Nico,
> > 
> > Try mounting as type "cdfs" (you'll most likely
> need
> > to get that driver and compile against your kernel
> or
> > use a Linux forensic boot CD that already has it)
> and
> > then viewing the file "/proc/cdfs".  This will
> show
> > you every session and allow you to mount each as
> ISO.
> > 
> > regards,
> > 
> > farmerdude
> > 
> > http://www.farmerdude.com/
> > 
> > 
> > 
> > --- Nico Kalteis <nka...@gm...> wrote:
> > 
> > > UPDATE!
> > > 
> > > OK, so I was playing around a bit more.  Here is
> > > what I did with an
> > > experimental CD-R:
> > > 
> > > 1) Wrote two files to the CD using standard
> WinXP
> > > method (right-click and
> > > Send To D:)
> > > 2) Wrote one more file using same method
> > > 3) Wrote one more file using same method
> > > 
> > > At this point Windows showed four files on my
> CD-R.
> > > 
> > > I take the CD and put it into my Linux box.
> > > 
> > > 1) I run readcd dev=/dev/cdrom -fulltoc
> > > 
> > > As expected, I get output saying that there are
> > > three sessions on that CD-R:
> > > 
> > > Read  speed:  5645 kB/s (CD  32x, DVD  4x).
> > > Write speed:  1411 kB/s (CD   8x, DVD  1x).
> > > TOC len: 180. First Session: 1 Last Session: 3.
> > > 01 14 00 A0 00 00 00 00 01 20 00
> > > 01 14 00 A1 00 00 00 00 01 00 00
> > > 01 14 00 A2 00 00 00 00 00 06 03
> > > 01 14 00 01 00 00 00 00 00 02 00
> > > 01 54 00 B0 02 24 03 02 4F 3B 4A
> > > 01 54 00 C0 A0 00 40 00 61 11 06
> > > 02 14 00 A0 00 00 00 00 02 20 00
> > > 02 14 00 A1 00 00 00 00 02 00 00
> > > 02 14 00 A2 00 00 00 00 02 2A 06
> > > 02 14 00 02 00 00 00 00 02 26 03
> > > 02 54 00 B0 04 0C 06 01 4F 3B 4A
> > > 03 14 00 A0 00 00 00 00 03 20 00
> > > 03 14 00 A1 00 00 00 00 03 00 00
> > > 03 14 00 A2 00 00 00 00 04 12 09
> > > 03 14 00 03 00 00 00 00 04 0E 06
> > > 03 54 00 B0 05 30 09 01 4F 3B 4A
> > > Lead out 1: 303
> > > Lead out 2: 12006
> > > Lead out 3: 19209
> > > 
> > > 2) I do a 'hexdump -C /dev/cdrom | less'
> > > 
> > > Everything goes fine for a while.  I see the two
> > > files I wrote first and the
> > > TOC.  Then I see a 'hexdump: /dev/hdc:
> Input/output
> > > error'.
> > > 
> > > 3) OK, so I try dcfldd (later I tried
> unsuccessfully
> > > using readcd.  It
> > > produced tons of I/O errors until it finally
> froze
> > > up.  After rebooting I
> > > look at the image file written by dcfldd (using
> > > hexdump) and it ends right
> > > where the original hexdump od /dev/cdrom ended.
> > > 
> > > So, eventually I realized that the place the
> > > hexdumps stopped and dcfldd
> > > froze up was at blocksize (2048) * 303 (Lead Out
> 1
> > > from readcd output
> > > earlier).  That tells me that everything is fine
> > > while looking at the first
> > > session only.  But for some reason hexdump and
> > > dcfldd won't show me the
> > > other two sessions.  Any ideas?
> > > 
> > > For what it's worth, mounting the CD using -t
> > > iso9660 and doing an ls -l
> > > shows all four files.
> > > 
> > > Again, thanks and enjoy the brain teaser!
> > > 
> > > Nico
> > > 
> > > 
> > > 
> > > On 1/12/06, Nico Kalteis <nka...@gm...>
> wrote:
> > > >
> > > > I would like to thank everyone very much for
> their
> > > input.  It has opened
> > > > up some interesting additional avenues for
> > > exploration, which I will do
> > > > right away.
> > > >
> > > > To answer a couple of questions, I began to dd
> > > (dcfldd, actually) the
> > > > whole thing but started to run into heavy I/O
> > > errors after about 55MB or
> > > > so.  Obtaining the image slowed to a crawl
> where I
> > > would get about 1MB every
> > > > minute, which ended up becoming unfeasible for
> > > this particular situation.  I
> > > > would have loved to get the whole thing,
> but...oh
> > > well.  So, I did all of my
> > > > analysis on the 50MB chunk.  I did run it
> through
> > > foremost and all it found
> > > > was just the one file.  I was able to verify
> that
> > > finding fairly easily
> > > > using hexdump since it abbreviates the data
> with a
> > > simple asterisk if the
> > > > preceeding line occurs more than once.  That
> made
> > > the 50+MB fairly easy to
> > > > skim through manually.
> > > >
> > > > The link to http://www.agilerm.net/linux1.html
> is
> > > excellent!
> > > >
> > > > Thanks again for your time!
> > > >
> > > > Nico
> > > >
> > > 
> > 
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam
> protection around 
> > http://mail.yahoo.com 
> > 
> > 
> >
>
-------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do
> you grep through 
> > log files
> > for problems?  Stop!  Download the new AJAX search
> engine that makes
> > searching your log files as easy as surfing the 
> web.  DOWNLOAD 
> >
>
SPLUNK!http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> > _______________________________________________
> > sleuthkit-users mailing list
> >
>
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> > http://www.sleuthkit.org
> > 
> 
> 
>
-------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do
> you grep through log files
> for problems?  Stop!  Download the new AJAX search
> engine that makes
> searching your log files as easy as surfing the 
> web.  DOWNLOAD SPLUNK!
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [sleuthkit-users] CD Forensics

[Nico K. <nka...@gm...>]

Thanks to both of you!  I'll try that first thing.  I should mention that I
did see that in the article.  However, the article said that mounting the C=
D
normally (which defaults to iso9660) only showed one session's worth of dat=
a
while mounting it CDFS showed all session which could be individually
mounted.  When I mounted the CD using iso9660 (I don't have the CDFS driver=
s
yet) I saw all four files, i.e. all sessions' data.  Based on the article I
only expected to see the one file written in the most recent section.

<Time passes as I installed the CDFS driver>

OK, so I couldn't resist and installed the CDFS driver before finishing thi=
s
email.  It worked! I mounted it with CDFS and can do a hexdump on the
individual ISOs.  Very cool.

Thanks again everyone for your help.  This was a most invaluable experience=
.

Cheers!

Nico


On 1/12/06, mm...@ta... <mm...@ta...> wrote:
>
> Farmer, you beat me to it, CDFS is covered in our Agile Risk Management
> Article on CDR Forensics.
>
> Good Luck Nico.
>
> M Shannon
>
> ----- Original Message -----
> From: farmer dude <far...@ya...>
> Date: Thursday, January 12, 2006 5:22 pm
> Subject: Re: [sleuthkit-users] CD Forensics
>
> > Hi Nico,
> >
> > Try mounting as type "cdfs" (you'll most likely need
> > to get that driver and compile against your kernel or
> > use a Linux forensic boot CD that already has it) and
> > then viewing the file "/proc/cdfs".  This will show
> > you every session and allow you to mount each as ISO.
> >
> > regards,
> >
> > farmerdude
> >
> > http://www.farmerdude.com/
> >
> >
> >
> > --- Nico Kalteis <nka...@gm...> wrote:
> >
> > > UPDATE!
> > >
> > > OK, so I was playing around a bit more.  Here is
> > > what I did with an
> > > experimental CD-R:
> > >
> > > 1) Wrote two files to the CD using standard WinXP
> > > method (right-click and
> > > Send To D:)
> > > 2) Wrote one more file using same method
> > > 3) Wrote one more file using same method
> > >
> > > At this point Windows showed four files on my CD-R.
> > >
> > > I take the CD and put it into my Linux box.
> > >
> > > 1) I run readcd dev=3D/dev/cdrom -fulltoc
> > >
> > > As expected, I get output saying that there are
> > > three sessions on that CD-R:
> > >
> > > Read  speed:  5645 kB/s (CD  32x, DVD  4x).
> > > Write speed:  1411 kB/s (CD   8x, DVD  1x).
> > > TOC len: 180. First Session: 1 Last Session: 3.
> > > 01 14 00 A0 00 00 00 00 01 20 00
> > > 01 14 00 A1 00 00 00 00 01 00 00
> > > 01 14 00 A2 00 00 00 00 00 06 03
> > > 01 14 00 01 00 00 00 00 00 02 00
> > > 01 54 00 B0 02 24 03 02 4F 3B 4A
> > > 01 54 00 C0 A0 00 40 00 61 11 06
> > > 02 14 00 A0 00 00 00 00 02 20 00
> > > 02 14 00 A1 00 00 00 00 02 00 00
> > > 02 14 00 A2 00 00 00 00 02 2A 06
> > > 02 14 00 02 00 00 00 00 02 26 03
> > > 02 54 00 B0 04 0C 06 01 4F 3B 4A
> > > 03 14 00 A0 00 00 00 00 03 20 00
> > > 03 14 00 A1 00 00 00 00 03 00 00
> > > 03 14 00 A2 00 00 00 00 04 12 09
> > > 03 14 00 03 00 00 00 00 04 0E 06
> > > 03 54 00 B0 05 30 09 01 4F 3B 4A
> > > Lead out 1: 303
> > > Lead out 2: 12006
> > > Lead out 3: 19209
> > >
> > > 2) I do a 'hexdump -C /dev/cdrom | less'
> > >
> > > Everything goes fine for a while.  I see the two
> > > files I wrote first and the
> > > TOC.  Then I see a 'hexdump: /dev/hdc: Input/output
> > > error'.
> > >
> > > 3) OK, so I try dcfldd (later I tried unsuccessfully
> > > using readcd.  It
> > > produced tons of I/O errors until it finally froze
> > > up.  After rebooting I
> > > look at the image file written by dcfldd (using
> > > hexdump) and it ends right
> > > where the original hexdump od /dev/cdrom ended.
> > >
> > > So, eventually I realized that the place the
> > > hexdumps stopped and dcfldd
> > > froze up was at blocksize (2048) * 303 (Lead Out 1
> > > from readcd output
> > > earlier).  That tells me that everything is fine
> > > while looking at the first
> > > session only.  But for some reason hexdump and
> > > dcfldd won't show me the
> > > other two sessions.  Any ideas?
> > >
> > > For what it's worth, mounting the CD using -t
> > > iso9660 and doing an ls -l
> > > shows all four files.
> > >
> > > Again, thanks and enjoy the brain teaser!
> > >
> > > Nico
> > >
> > >
> > >
> > > On 1/12/06, Nico Kalteis <nka...@gm...> wrote:
> > > >
> > > > I would like to thank everyone very much for their
> > > input.  It has opened
> > > > up some interesting additional avenues for
> > > exploration, which I will do
> > > > right away.
> > > >
> > > > To answer a couple of questions, I began to dd
> > > (dcfldd, actually) the
> > > > whole thing but started to run into heavy I/O
> > > errors after about 55MB or
> > > > so.  Obtaining the image slowed to a crawl where I
> > > would get about 1MB every
> > > > minute, which ended up becoming unfeasible for
> > > this particular situation.  I
> > > > would have loved to get the whole thing, but...oh
> > > well.  So, I did all of my
> > > > analysis on the 50MB chunk.  I did run it through
> > > foremost and all it found
> > > > was just the one file.  I was able to verify that
> > > finding fairly easily
> > > > using hexdump since it abbreviates the data with a
> > > simple asterisk if the
> > > > preceeding line occurs more than once.  That made
> > > the 50+MB fairly easy to
> > > > skim through manually.
> > > >
> > > > The link to http://www.agilerm.net/linux1.html is
> > > excellent!
> > > >
> > > > Thanks again for your time!
> > > >
> > > > Nico
> > > >
> > >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through
> > log files
> > for problems?  Stop!  Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the  web.  DOWNLOAD
> > SPLUNK!http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> > _______________________________________________
> > sleuthkit-users mailing list
> > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> > http://www.sleuthkit.org
> >
>

Re: [sleuthkit-users] CD Forensics

[<mm...@ta...>]

Farmer, you beat me to it, CDFS is covered in our Agile Risk Management
Article on CDR Forensics.

Good Luck Nico.

M Shannon

----- Original Message -----
From: farmer dude <far...@ya...>
Date: Thursday, January 12, 2006 5:22 pm
Subject: Re: [sleuthkit-users] CD Forensics

> Hi Nico,
> 
> Try mounting as type "cdfs" (you'll most likely need
> to get that driver and compile against your kernel or
> use a Linux forensic boot CD that already has it) and
> then viewing the file "/proc/cdfs".  This will show
> you every session and allow you to mount each as ISO.
> 
> regards,
> 
> farmerdude
> 
> http://www.farmerdude.com/
> 
> 
> 
> --- Nico Kalteis <nka...@gm...> wrote:
> 
> > UPDATE!
> > 
> > OK, so I was playing around a bit more.  Here is
> > what I did with an
> > experimental CD-R:
> > 
> > 1) Wrote two files to the CD using standard WinXP
> > method (right-click and
> > Send To D:)
> > 2) Wrote one more file using same method
> > 3) Wrote one more file using same method
> > 
> > At this point Windows showed four files on my CD-R.
> > 
> > I take the CD and put it into my Linux box.
> > 
> > 1) I run readcd dev=/dev/cdrom -fulltoc
> > 
> > As expected, I get output saying that there are
> > three sessions on that CD-R:
> > 
> > Read  speed:  5645 kB/s (CD  32x, DVD  4x).
> > Write speed:  1411 kB/s (CD   8x, DVD  1x).
> > TOC len: 180. First Session: 1 Last Session: 3.
> > 01 14 00 A0 00 00 00 00 01 20 00
> > 01 14 00 A1 00 00 00 00 01 00 00
> > 01 14 00 A2 00 00 00 00 00 06 03
> > 01 14 00 01 00 00 00 00 00 02 00
> > 01 54 00 B0 02 24 03 02 4F 3B 4A
> > 01 54 00 C0 A0 00 40 00 61 11 06
> > 02 14 00 A0 00 00 00 00 02 20 00
> > 02 14 00 A1 00 00 00 00 02 00 00
> > 02 14 00 A2 00 00 00 00 02 2A 06
> > 02 14 00 02 00 00 00 00 02 26 03
> > 02 54 00 B0 04 0C 06 01 4F 3B 4A
> > 03 14 00 A0 00 00 00 00 03 20 00
> > 03 14 00 A1 00 00 00 00 03 00 00
> > 03 14 00 A2 00 00 00 00 04 12 09
> > 03 14 00 03 00 00 00 00 04 0E 06
> > 03 54 00 B0 05 30 09 01 4F 3B 4A
> > Lead out 1: 303
> > Lead out 2: 12006
> > Lead out 3: 19209
> > 
> > 2) I do a 'hexdump -C /dev/cdrom | less'
> > 
> > Everything goes fine for a while.  I see the two
> > files I wrote first and the
> > TOC.  Then I see a 'hexdump: /dev/hdc: Input/output
> > error'.
> > 
> > 3) OK, so I try dcfldd (later I tried unsuccessfully
> > using readcd.  It
> > produced tons of I/O errors until it finally froze
> > up.  After rebooting I
> > look at the image file written by dcfldd (using
> > hexdump) and it ends right
> > where the original hexdump od /dev/cdrom ended.
> > 
> > So, eventually I realized that the place the
> > hexdumps stopped and dcfldd
> > froze up was at blocksize (2048) * 303 (Lead Out 1
> > from readcd output
> > earlier).  That tells me that everything is fine
> > while looking at the first
> > session only.  But for some reason hexdump and
> > dcfldd won't show me the
> > other two sessions.  Any ideas?
> > 
> > For what it's worth, mounting the CD using -t
> > iso9660 and doing an ls -l
> > shows all four files.
> > 
> > Again, thanks and enjoy the brain teaser!
> > 
> > Nico
> > 
> > 
> > 
> > On 1/12/06, Nico Kalteis <nka...@gm...> wrote:
> > >
> > > I would like to thank everyone very much for their
> > input.  It has opened
> > > up some interesting additional avenues for
> > exploration, which I will do
> > > right away.
> > >
> > > To answer a couple of questions, I began to dd
> > (dcfldd, actually) the
> > > whole thing but started to run into heavy I/O
> > errors after about 55MB or
> > > so.  Obtaining the image slowed to a crawl where I
> > would get about 1MB every
> > > minute, which ended up becoming unfeasible for
> > this particular situation.  I
> > > would have loved to get the whole thing, but...oh
> > well.  So, I did all of my
> > > analysis on the 50MB chunk.  I did run it through
> > foremost and all it found
> > > was just the one file.  I was able to verify that
> > finding fairly easily
> > > using hexdump since it abbreviates the data with a
> > simple asterisk if the
> > > preceeding line occurs more than once.  That made
> > the 50+MB fairly easy to
> > > skim through manually.
> > >
> > > The link to http://www.agilerm.net/linux1.html is
> > excellent!
> > >
> > > Thanks again for your time!
> > >
> > > Nico
> > >
> > 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through 
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD 
> SPLUNK!http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
> 

Re: [sleuthkit-users] CD Forensics

[farmer d. <far...@ya...>]

Hi Nico,

Try mounting as type "cdfs" (you'll most likely need
to get that driver and compile against your kernel or
use a Linux forensic boot CD that already has it) and
then viewing the file "/proc/cdfs".  This will show
you every session and allow you to mount each as ISO.

regards,

farmerdude

http://www.farmerdude.com/



--- Nico Kalteis <nka...@gm...> wrote:

> UPDATE!
> 
> OK, so I was playing around a bit more.  Here is
> what I did with an
> experimental CD-R:
> 
> 1) Wrote two files to the CD using standard WinXP
> method (right-click and
> Send To D:)
> 2) Wrote one more file using same method
> 3) Wrote one more file using same method
> 
> At this point Windows showed four files on my CD-R.
> 
> I take the CD and put it into my Linux box.
> 
> 1) I run readcd dev=/dev/cdrom -fulltoc
> 
> As expected, I get output saying that there are
> three sessions on that CD-R:
> 
> Read  speed:  5645 kB/s (CD  32x, DVD  4x).
> Write speed:  1411 kB/s (CD   8x, DVD  1x).
> TOC len: 180. First Session: 1 Last Session: 3.
> 01 14 00 A0 00 00 00 00 01 20 00
> 01 14 00 A1 00 00 00 00 01 00 00
> 01 14 00 A2 00 00 00 00 00 06 03
> 01 14 00 01 00 00 00 00 00 02 00
> 01 54 00 B0 02 24 03 02 4F 3B 4A
> 01 54 00 C0 A0 00 40 00 61 11 06
> 02 14 00 A0 00 00 00 00 02 20 00
> 02 14 00 A1 00 00 00 00 02 00 00
> 02 14 00 A2 00 00 00 00 02 2A 06
> 02 14 00 02 00 00 00 00 02 26 03
> 02 54 00 B0 04 0C 06 01 4F 3B 4A
> 03 14 00 A0 00 00 00 00 03 20 00
> 03 14 00 A1 00 00 00 00 03 00 00
> 03 14 00 A2 00 00 00 00 04 12 09
> 03 14 00 03 00 00 00 00 04 0E 06
> 03 54 00 B0 05 30 09 01 4F 3B 4A
> Lead out 1: 303
> Lead out 2: 12006
> Lead out 3: 19209
> 
> 2) I do a 'hexdump -C /dev/cdrom | less'
> 
> Everything goes fine for a while.  I see the two
> files I wrote first and the
> TOC.  Then I see a 'hexdump: /dev/hdc: Input/output
> error'.
> 
> 3) OK, so I try dcfldd (later I tried unsuccessfully
> using readcd.  It
> produced tons of I/O errors until it finally froze
> up.  After rebooting I
> look at the image file written by dcfldd (using
> hexdump) and it ends right
> where the original hexdump od /dev/cdrom ended.
> 
> So, eventually I realized that the place the
> hexdumps stopped and dcfldd
> froze up was at blocksize (2048) * 303 (Lead Out 1
> from readcd output
> earlier).  That tells me that everything is fine
> while looking at the first
> session only.  But for some reason hexdump and
> dcfldd won't show me the
> other two sessions.  Any ideas?
> 
> For what it's worth, mounting the CD using -t
> iso9660 and doing an ls -l
> shows all four files.
> 
> Again, thanks and enjoy the brain teaser!
> 
> Nico
> 
> 
> 
> On 1/12/06, Nico Kalteis <nka...@gm...> wrote:
> >
> > I would like to thank everyone very much for their
> input.  It has opened
> > up some interesting additional avenues for
> exploration, which I will do
> > right away.
> >
> > To answer a couple of questions, I began to dd
> (dcfldd, actually) the
> > whole thing but started to run into heavy I/O
> errors after about 55MB or
> > so.  Obtaining the image slowed to a crawl where I
> would get about 1MB every
> > minute, which ended up becoming unfeasible for
> this particular situation.  I
> > would have loved to get the whole thing, but...oh
> well.  So, I did all of my
> > analysis on the 50MB chunk.  I did run it through
> foremost and all it found
> > was just the one file.  I was able to verify that
> finding fairly easily
> > using hexdump since it abbreviates the data with a
> simple asterisk if the
> > preceeding line occurs more than once.  That made
> the 50+MB fairly easy to
> > skim through manually.
> >
> > The link to http://www.agilerm.net/linux1.html is
> excellent!
> >
> > Thanks again for your time!
> >
> > Nico
> >
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [sleuthkit-users] CD Forensics

[Nico K. <nka...@gm...>]

UPDATE!

OK, so I was playing around a bit more.  Here is what I did with an
experimental CD-R:

1) Wrote two files to the CD using standard WinXP method (right-click and
Send To D:)
2) Wrote one more file using same method
3) Wrote one more file using same method

At this point Windows showed four files on my CD-R.

I take the CD and put it into my Linux box.

1) I run readcd dev=3D/dev/cdrom -fulltoc

As expected, I get output saying that there are three sessions on that CD-R=
:

Read  speed:  5645 kB/s (CD  32x, DVD  4x).
Write speed:  1411 kB/s (CD   8x, DVD  1x).
TOC len: 180. First Session: 1 Last Session: 3.
01 14 00 A0 00 00 00 00 01 20 00
01 14 00 A1 00 00 00 00 01 00 00
01 14 00 A2 00 00 00 00 00 06 03
01 14 00 01 00 00 00 00 00 02 00
01 54 00 B0 02 24 03 02 4F 3B 4A
01 54 00 C0 A0 00 40 00 61 11 06
02 14 00 A0 00 00 00 00 02 20 00
02 14 00 A1 00 00 00 00 02 00 00
02 14 00 A2 00 00 00 00 02 2A 06
02 14 00 02 00 00 00 00 02 26 03
02 54 00 B0 04 0C 06 01 4F 3B 4A
03 14 00 A0 00 00 00 00 03 20 00
03 14 00 A1 00 00 00 00 03 00 00
03 14 00 A2 00 00 00 00 04 12 09
03 14 00 03 00 00 00 00 04 0E 06
03 54 00 B0 05 30 09 01 4F 3B 4A
Lead out 1: 303
Lead out 2: 12006
Lead out 3: 19209

2) I do a 'hexdump -C /dev/cdrom | less'

Everything goes fine for a while.  I see the two files I wrote first and th=
e
TOC.  Then I see a 'hexdump: /dev/hdc: Input/output error'.

3) OK, so I try dcfldd (later I tried unsuccessfully using readcd.  It
produced tons of I/O errors until it finally froze up.  After rebooting I
look at the image file written by dcfldd (using hexdump) and it ends right
where the original hexdump od /dev/cdrom ended.

So, eventually I realized that the place the hexdumps stopped and dcfldd
froze up was at blocksize (2048) * 303 (Lead Out 1 from readcd output
earlier).  That tells me that everything is fine while looking at the first
session only.  But for some reason hexdump and dcfldd won't show me the
other two sessions.  Any ideas?

For what it's worth, mounting the CD using -t iso9660 and doing an ls -l
shows all four files.

Again, thanks and enjoy the brain teaser!

Nico



On 1/12/06, Nico Kalteis <nka...@gm...> wrote:
>
> I would like to thank everyone very much for their input.  It has opened
> up some interesting additional avenues for exploration, which I will do
> right away.
>
> To answer a couple of questions, I began to dd (dcfldd, actually) the
> whole thing but started to run into heavy I/O errors after about 55MB or
> so.  Obtaining the image slowed to a crawl where I would get about 1MB ev=
ery
> minute, which ended up becoming unfeasible for this particular situation.=
  I
> would have loved to get the whole thing, but...oh well.  So, I did all of=
 my
> analysis on the 50MB chunk.  I did run it through foremost and all it fou=
nd
> was just the one file.  I was able to verify that finding fairly easily
> using hexdump since it abbreviates the data with a simple asterisk if the
> preceeding line occurs more than once.  That made the 50+MB fairly easy t=
o
> skim through manually.
>
> The link to http://www.agilerm.net/linux1.html is excellent!
>
> Thanks again for your time!
>
> Nico
>

Re: [sleuthkit-users] CD Forensics

[Nico K. <nka...@gm...>]

I would like to thank everyone very much for their input.  It has opened up
some interesting additional avenues for exploration, which I will do right
away.

To answer a couple of questions, I began to dd (dcfldd, actually) the whole
thing but started to run into heavy I/O errors after about 55MB or so.
Obtaining the image slowed to a crawl where I would get about 1MB every
minute, which ended up becoming unfeasible for this particular situation.  =
I
would have loved to get the whole thing, but...oh well.  So, I did all of m=
y
analysis on the 50MB chunk.  I did run it through foremost and all it found
was just the one file.  I was able to verify that finding fairly easily
using hexdump since it abbreviates the data with a simple asterisk if the
preceeding line occurs more than once.  That made the 50+MB fairly easy to
skim through manually.

The link to http://www.agilerm.net/linux1.html is excellent!

Thanks again for your time!

Nico

Re: [sleuthkit-users] CD Forensics

[Barry J. G. <bg...@im...>]

On Thu, 2006-01-12 at 10:12 -0500, Nico Kalteis wrote:
> I was recently tasked with looking at a CD-R.  

In general, this has some pointers you might find interesting.  FWIW,
this whole series of articles is good stuff.

http://www.agilerm.net/linux1.html

-- 
/***************************************
Special Agent Barry J. Grundy
NASA Office of Inspector General
Computer Crimes Division 
Goddard Space Flight Center
Code 190
Greenbelt Rd.
Greenbelt, MD 20771
(301)286-3358
**************************************/

RE: [sleuthkit-users] CD Forensics

[Kalisiak A. C. <Ale...@ni...>]

You might want to look up ISO9660 standards. You could probably use that to
figure exactly where the file table should be for any given CD media. . .

 

From what I remember though, 

 

Single session / closed disc: File table first, then files

Multi-session: (old data) files, then file table

 

It sounds like the user saved a bit of data on there, saved it as an open
session, then created another session (or more) after that.

 

Have you DD'ed the whole thing, and maybe ran foremost or anything yet?

 

- Alex Kalisiak

DMS/Exchange Administrator

Niagara Falls IAP-ARS

Comm: 716.236.3310

DSN: 238.3310

ale...@ni...

 

  _____  

From: sle...@li...
[mailto:sle...@li...] On Behalf Of Nico
Kalteis
Sent: Thursday, January 12, 2006 10:12 AM
To: sle...@li...
Subject: [sleuthkit-users] CD Forensics

 

Good morning!

This doesn't pertain directly to TSK, but I thought some of you might be
able to offer me some insight into this issue.

I was recently tasked with looking at a CD-R.  There was only a single file
of about 55KB.  However, when checking the properties under Windows it
showed that the used space was somewhere in the vicinity of ~580MB, which
equalled the capacity of the CD-R.  We suspected that there was more data
than just that one file. 

We proceeded to get a bit-level image using dcfldd with various
(conv=noerror,sync) and got to about 50MB when we started getting errors
that simply slowed the read process down dramatically.  The CD was heavily
scratched, which might have caused the issue.  However, when looking at the
CD image we did get using hexedit and hexdump, we did only see that one file
followed eventually by the file table.  It appears that the CD format was
UDF and that only that one file was on the disk. 

I tried to replicate the scenario by writing a single file of similar size
to a new CD-R using various methods native to XP as well as using Nero.  But
in each case the amount of used space according to the Windows properties
sheet was in the KB range, which I expected based on file size + file table.
But nowhere near the full capacity of the CD. 

Has anybody run into this or does anybody have any insight?  Do you think
there might be more data?  Since it's a CD-R I really doubt that anybody
would write files to the CD and be able to mess with the file table.
Particularly the person in question. 

Also, does anybody have anymore info on the location of the file table?  On
some CD-Rs and CD-RWs I see the file table at the very beginning of the CD
before the files themselves, and on others I see the files first followed
eventually by the file table. 

Thank you VERY much for your time and interest.

Cheers!

Nico

Re: [sleuthkit-users] CD Forensics

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

Could it be that the session was not closed????  What would the files of a opened session CD-R look like in the forensics environment?

Interesting- never ran into that before.

Cool problem (academically, of course)

Nico Kalteis <nka...@gm...> wrote: Good morning!

This doesn't pertain directly to TSK, but I thought some of you might be able to offer me some insight into this issue.

I was recently tasked with looking at a CD-R.  There was only a single file of about 55KB.  However, when checking the properties under Windows it showed that the used space was somewhere in the vicinity of ~580MB, which equalled the capacity of the CD-R.  We suspected that there was more data than just that one file. 

We proceeded to get a bit-level image using dcfldd with various (conv=noerror,sync) and got to about 50MB when we started getting errors that simply slowed the read process down dramatically.  The CD was heavily scratched, which might have caused the issue.  However, when looking at the CD image we did get using hexedit and hexdump, we did only see that one file followed eventually by the file table.  It appears that the CD format was UDF and that only that one file was on the disk. 

I tried to replicate the scenario by writing a single file of similar size to a new CD-R using various methods native to XP as well as using Nero.  But in each case the amount of used space according to the Windows properties sheet was in the KB range, which I expected based on file size + file table.  But nowhere near the full capacity of the CD. 

Has anybody run into this or does anybody have any insight?  Do you think there might be more data?  Since it's a CD-R I really doubt that anybody would write files to the CD and be able to mess with the file table.  Particularly the person in question. 

Also, does anybody have anymore info on the location of the file table?  On some CD-Rs and CD-RWs I see the file table at the very beginning of the CD before the files themselves, and on others I see the files first followed eventually by the file table. 

Thank you VERY much for your time and interest.

Cheers!

Nico
 

[sleuthkit-users] CD Forensics

[Nico K. <nka...@gm...>]

Good morning!

This doesn't pertain directly to TSK, but I thought some of you might be
able to offer me some insight into this issue.

I was recently tasked with looking at a CD-R.  There was only a single file
of about 55KB.  However, when checking the properties under Windows it
showed that the used space was somewhere in the vicinity of ~580MB, which
equalled the capacity of the CD-R.  We suspected that there was more data
than just that one file.

We proceeded to get a bit-level image using dcfldd with various
(conv=3Dnoerror,sync) and got to about 50MB when we started getting errors
that simply slowed the read process down dramatically.  The CD was heavily
scratched, which might have caused the issue.  However, when looking at the
CD image we did get using hexedit and hexdump, we did only see that one fil=
e
followed eventually by the file table.  It appears that the CD format was
UDF and that only that one file was on the disk.

I tried to replicate the scenario by writing a single file of similar size
to a new CD-R using various methods native to XP as well as using Nero.  Bu=
t
in each case the amount of used space according to the Windows properties
sheet was in the KB range, which I expected based on file size + file
table.  But nowhere near the full capacity of the CD.

Has anybody run into this or does anybody have any insight?  Do you think
there might be more data?  Since it's a CD-R I really doubt that anybody
would write files to the CD and be able to mess with the file table.
Particularly the person in question.

Also, does anybody have anymore info on the location of the file table?  On
some CD-Rs and CD-RWs I see the file table at the very beginning of the CD
before the files themselves, and on others I see the files first followed
eventually by the file table.

Thank you VERY much for your time and interest.

Cheers!

Nico

Re: [sleuthkit-users] invalid arguement : fsstat, img_stat

[J B <je...@ad...>]

> 
> That is very strange. Do all of the other tools work?  Have you tried  
> to recompile?  I can't say that I have tried Fedora on a PPC, but I  
> don't see why some tools would work and others wouldn't.  .   They  
> all share the same image opening routines.  Nothing at all is printed  
> to stderr with '-v'?
> 
> brian

nope, nothing but the invalid... and then correct usage readout

I appreciate your help.

-jessop

Re: [sleuthkit-users] invalid arguement : fsstat, img_stat

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

On Jan 11, 2006, at 8:00 PM, J B wrote:
>
> Thank you.. at your suggestion, I tried that.  I tried offsets 61,  
> 62, 63, 64 and didn't get anywhere.
>
> I changed the filename to just "old".
>
> #mmls old  //still reports a primary table, unallocated, dos fat16  
> (starting at 63)
>
> interestingly enough,
>
> #fls -r -o 63 -f fat /evidence/old   //works fine, I can even grep  
> JPG as long as I remember unix is case sensitive ;)
>
> There's probably something obvious I'm overlooking with fsstat

That is very strange. Do all of the other tools work?  Have you tried  
to recompile?  I can't say that I have tried Fedora on a PPC, but I  
don't see why some tools would work and others wouldn't.  .   They  
all share the same image opening routines.  Nothing at all is printed  
to stderr with '-v'?

brian

Re: [sleuthkit-users] invalid arguement : fsstat, img_stat

[J B <je...@ad...>]

>> mmls /evidence/old.dd
>> *reports first sector (0) Primary Table, 1 > 62 unallocated, 63 >
>> 1031121 DOS FAT16
> <snip>
>> fsstat old.dd
>> invalid arguemnt: old.dd
>
> In addition to the fstype, as farmerdude pointed out, you will probably
> want to point to the offset to the file system.  Your mmls output
> reports that the fs is at sector 63, not the front of the image.
>
> fsstat -f fat -o 63 old.dd  (assuming it's formatted FAT).
>
>

Thank you.. at your suggestion, I tried that.  I tried offsets 61, 62, 63, 
64 and didn't get anywhere.

I changed the filename to just "old".

#mmls old  //still reports a primary table, unallocated, dos fat16 (starting 
at 63)

interestingly enough,

#fls -r -o 63 -f fat /evidence/old   //works fine, I can even grep JPG as 
long as I remember unix is case sensitive ;)

There's probably something obvious I'm overlooking with fsstat

thanks, JB 

Re: [sleuthkit-users] invalid arguement : fsstat, img_stat

[Barry J. G. <bg...@im...>]

On Tue, 2006-01-10 at 22:30 -0500, J B wrote:

> mmls /evidence/old.dd 
> *reports first sector (0) Primary Table, 1 > 62 unallocated, 63 >
> 1031121 DOS FAT16
<snip>
> fsstat old.dd
> invalid arguemnt: old.dd

In addition to the fstype, as farmerdude pointed out, you will probably
want to point to the offset to the file system.  Your mmls output
reports that the fs is at sector 63, not the front of the image.

fsstat -f fat -o 63 old.dd  (assuming it's formatted FAT).


-- 
/***************************************
Special Agent Barry J. Grundy
NASA Office of Inspector General
Computer Crimes Division 
Goddard Space Flight Center
Code 190
Greenbelt Rd.
Greenbelt, MD 20771
(301)286-3358
**************************************/

Re: [sleuthkit-users] invalid arguement : fsstat, img_stat

[farmer d. <far...@ya...>]

JB,

What happens when you pass one or more arguments to
"fsstat"?  Perhaps;

fsstat -t old.dd

-OR-

fsstat -f FSTYPE_HERE old.dd

-OR-

fsstat -vt old.dd


Does your mileage improve by passing arguments before
the file name?


regards,

farmerdude

http://www.farmerdude.com/farmercd.html



--- J B <je...@ad...> wrote:

> I installed tsk on my ibook running ppc fedora. 
> Some things work, others don't
> 
> I have a file called old.dd which is an image of an
> old 512mb hd.
> 
> mmls /evidence/old.dd 
> *reports first sector (0) Primary Table, 1 > 62
> unallocated, 63 > 1031121 DOS FAT16
> 
> however,
> 
> fsstat old.dd
> invalid arguemnt: old.dd
> 
> fsstat "old.dd" = invalid argument: old.dd
> fsstat 'old.dd', ...
> fsstat "\evidence\old.dd" = invalid argument:
> \evidence\old.dd
> 
> verbose doesn't even report anything.
> 
> Any suggestions?
> 
> -JB


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[sleuthkit-users] invalid arguement : fsstat, img_stat

[J B <je...@ad...>]

I installed tsk on my ibook running ppc fedora.  Some things work, =
others don't

I have a file called old.dd which is an image of an old 512mb hd.

mmls /evidence/old.dd=20
*reports first sector (0) Primary Table, 1 > 62 unallocated, 63 > =
1031121 DOS FAT16

however,

fsstat old.dd
invalid arguemnt: old.dd

fsstat "old.dd" =3D invalid argument: old.dd
fsstat 'old.dd', ...
fsstat "\evidence\old.dd" =3D invalid argument: \evidence\old.dd

verbose doesn't even report anything.

Any suggestions?

-JB

Re: [sleuthkit-users] Recovering files from damaged disk

[farmer d. <far...@ya...>]

Hi Colby,

You might improve your mileage by acquiring the drive
in reverse (reverse sector cloning).  'ddrescue' can
do this on the Linux side of the house.  There is
another *nix utility but I've brain farted and cannot
remember it at this point.  Look into it and see if
that doesn't help you.

regards,

farmerdude

http://www.farmerdude.com/farmercd.html




		
__________________________________________ 
Yahoo! DSL – Something to write home about. 
Just $16.99/mo. or less. 
dsl.yahoo.com