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

[sleuthkit-users] missing file executable on Mac OS X, Tiger, 10.4.2

[Priscilla O. <pri...@ya...>]

Hello TSK gurus,

This is my first post, so let me know if I don't
follow protocol.

I'll be using The Sleuth Kit in a forensics class I'll
be teaching at Southern Oregon Univerisity.

Any ideas why the TSK file tool didn't install on Mac
OS X, Tiger, 10.4.2?

I'd like to use the sorter cmd, actually, but it says
this when I try to run it:

Missing Sleuth Kit file executable:
/Applications/sleuthkit/sleuthkit-2.02//bin/file

The check-install also says that file tool is indeed
missing.

I just ran a generic make after downloading version
2.02 of The Sleuth Kit. I didn't watch for any errors,
so don't know what's going on.

Any suggestions for what went wrong, how to
troubleshoot this, or workarounds?

Thank-you.

Priscilla Oppenheimer



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

RE: [sleuthkit-users] Building a Computer Forensics Lab

[Surago J. <su...@sj...>]

Hi Charles,

=20

I too am a master's student focusing on Digital Forensics (Specifically
the use of The SleuthKit, and Autopsy browser as an analysis tool), and
hope to have thesis finished within the next month or so.

=20

One area I can suggest you take into account is the processes, and
procedures utilised by investigators.  Often in a lab environment much
of the background information in regards to the actual acquisition of
compromised material (i.e. PCs, Servers, PDAs etc etc) is overlooked in
favour of focusing on the actual analysis of the media retrieved.

=20

During my studies I have come across various process models for both
incident response, and forensic investigation.  One of which (The
Integrated Digital Investigation Process  Model - IDIP) was proposed by
Brian Carrier and Eugene Spafford, this model takes into account many of
the phases of a full on investigation from preservation of the crime
scene to the presentation of ones findings.  The following reference
should help to locate this paper.

=20

Carrier, B. and E.H. Spafford, Getting Physical with the Digital
Investigation Process. International Journal of Digital Evidence, 2003.
Fall 2003.

=20

Venansius Baryamureeba and Florence Tushabe offer some critisms to the
IDIP model and in turn offer an Enhanced Digital Investigation Process
Model.  Their paper can be found with the following reference.

=20

Baryamureeba, V. and F. Tushabe, The Enhanced Digital Investigation
Process Model. Digital Forensics Research WorkShop, 2004.

=20

In regards to incident response, the CERT Coordination Centre (CERT/CC)
has a substantial amount of information available about processes and
procedures that would be vital background information to many
investigations.

=20

For standard operating procedures (SOPs) the U.S. Department of Justice
published (DOJ) "Electronic Crime Scene Investigation: A Guide for First
Responders", and The Association of Chief Police Officers (ACPO) in the
United Kingdom publishes a guide that builds on the principles that were
developed in collaboration with the International Organisation on
Computer Evidence.

=20

References...

=20

Justice, N.I.o., Electronic Crime Scene Investigation: A Guide for First
Responders. 2001. p. 93,

ACPO, Association of Chief Police Officers. 2005,
(http://www.acpo.police.uk/)

IOCE, International Organisation on Computer Evidence WebSite. 2003,
(http://www.ioce.org/)

ACPO, ACPO Good Practice Guide to Computer Based Evidence. 2003,
(http://www.acpo.police.uk/asp/policies/Data/gpg_computer_based_evidence
_v3.pdf

=20

I believe the information provided here would be valuable background
information that should be passed on to all potential investigators in
the field.  If anyone has any further background information similar to
this can they let me know, as technologies and techniques evolve these
documents are continually updated.

=20

Hope those references help.

=20

Cheers

=20

Surago.

=20

________________________________

From: sle...@li...
[mailto:sle...@li...] On Behalf Of
Charles Nwatu
Sent: Thursday, 8 September 2005 11:44
To: sle...@li...
Subject: [sleuthkit-users] Building a Computer Forensics Lab

=20

Hello Computer Forensics Community,

I am a first year Master's student at Penn State University and my area
of focus is Computer Forensics and Incident Response, I am in the
process of developing a computer forensics lab for the university and
would appreciate any advice and assistance from the community in terms
of recommending commercial software, open-source software, hardware and
infrastructure. The curriculum is brand new and is in the process of
being develop. Once again, any insight or advice would be helpful,
ranging from links, to industry contacts, to slides, to whatever your
imagination thinks is necessary.

The purpose of the lab, as far as I know are the following:=20

1) create an environment in which students can learn computer forensics
and
 incident retrieval. (hands on experience)

2) create a curriculum (which includes slides, bringing guest speakers,
etc)

3) the lab will be used to conduct research projects

4) the lab will be used by local county police for their investigations

5) the lab will be used by school police for their investigations

6) our goal is to have our proposed lab will focus on both active and
passive (proactive) forensics. In particular, we will establish honey
pot and intrusion prevention and detection mechanisms to predict and
detect attacker/hacker behavior.

Thanks

Charles

Re: [sleuthkit-users] Building a Computer Forensics Lab

[Alan <ts...@as...>]

Hi Charles, First, let me just say I think you've hit the right field 
of study. I just graduated from Georgia Tech with a masters in 
infosec. I have been hired by a federal government agency in the 
incident response/analysis field, and last summer my internship with 
the U.S. Senate had an incident response component. I have also 
gotten certified by the SANS Institute in both incident handling and 
computer forensics, so my technical forensics knowledge largely comes 
from those courses.

1.  Its important to have a good technical infraustructure for 
hands-on learning, but its also important to teach policies, 
planning, and procedures, i.e. an incident handling plan and a 
forensics methodology. Forensics findings may potentially be used in 
the legal or a human resources setting and must stand up to scrutiny.

2.  I would suggest starting with open source tools such as TSK. They 
are relatively cheap to set up, and open source so students can 
review source code. Don't close the door to proprietary products, 
such as Guidance Software's Encase suite (very expensive but has a 
large professional user base.)

3.  On the forensics workstations, they should be dual-bootable and 
have large hard drives. Dual-bootable as many forensics tools are 
Linux-only or Windows-only. Large hard drives to store the large disk 
images your students and analysts will be working on.

4.  Consider Vmware or another virtualization tool. It lets you run 
"guest" operating systems from within another operating system. For 
example, I may install Vmware on Windows and make a virtual computer 
with Linux on it. That way I can analyze live forensics images and do 
passive analysis simultaneously. For example, I can run a suspected 
piece of malware on a guest operating system to sandbox it, and then 
use the same computer (host operating system) to sniff its network 
traffic. A virtual heterogeneous network, all simulated on one computer

Alan

At 18:44 9/7/2005, Charles Nwatu wrote:

>Hello Computer Forensics Community,
>
>I am a first year Master's student at Penn State University and my 
>area of focus is Computer Forensics and Incident Response, I am in 
>the process of developing a computer forensics lab for the 
>university and would appreciate any advice and assistance from the 
>community in terms of recommending commercial software, open-source 
>software, hardware and infrastructure. The curriculum is brand new 
>and is in the process of being develop. Once again, any insight or 
>advice would be helpful, ranging from links, to industry contacts, 
>to slides, to whatever your imagination thinks is necessary.
>
>The purpose of the lab, as far as I know are the following:
>
>1) create an environment in which students can learn computer forensics and
>  incident retrieval. (hands on experience)
>
>2) create a curriculum (which includes slides, bringing guest speakers, etc)
>
>3) the lab will be used to conduct research projects
>
>4) the lab will be used by local county police for their investigations
>
>5) the lab will be used by school police for their investigations
>
>6) our goal is to have our proposed lab will focus on both active 
>and passive (proactive) forensics. In particular, we will establish 
>honey pot and intrusion prevention and detection mechanisms to 
>predict and detect attacker/hacker behavior.
>
>Thanks
>
>Charles

[sleuthkit-users] Building a Computer Forensics Lab

[Charles N. <cha...@gm...>]

Hello Computer Forensics Community,

I am a first year Master's student at Penn State University and my area of=
=20
focus is Computer Forensics and Incident Response, I am in the process of=
=20
developing a computer forensics lab for the university and would appreciate=
=20
any advice and assistance from the community in terms of recommending=20
commercial software, open-source software, hardware and infrastructure. The=
=20
curriculum is brand new and is in the process of being develop. Once again,=
=20
any insight or advice would be helpful, ranging from links, to industry=20
contacts, to slides, to whatever your imagination thinks is necessary.

The purpose of the lab, as far as I know are the following:=20

1) create an environment in which students can learn computer forensics and
 incident retrieval. (hands on experience)

 2) create a curriculum (which includes slides, bringing guest speakers,=20
etc)

 3) the lab will be used to conduct research projects

 4) the lab will be used by local county police for their investigations

 5) the lab will be used by school police for their investigations

 6) our goal is to have our proposed lab will focus on both active and pass=
ive=20
(proactive) forensics. In particular, we will establish honey pot and=20
intrusion prevention and detection mechanisms to predict and detect
attacker/hacker
behavior.

Thanks

Charles

Re: [sleuthkit-users] Honeynet Forensic Challege TimeStamping

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

Timezones were harder to deal with when the challenge came out many =20
years ago. Most tools did not allow you to set the timezone for the =20
image and therefore to get accurate times you had to change the =20
timezone on the actual analysis system.  I think most tools have now =20
changed that.

brian


On Sep 6, 2005, at 12:46 PM, Surago Jones wrote:

> Just a quick query for anyone that may have attempted the Forensic =20
> Challenge available from the Honeynet Project (http://=20
> www.honeynet.org/challenge/index.html)
>
>
>
> I have just created a timeline within Autopsy v2.05 and upon =20
> comparing my times to the times in the answers provided by The =20
> Honeynet Projects analysis (http://www.honeynet.org/challenge/=20
> results/dittrich/evidence.txt) an import event (The first =20
> modification made) I note that my results differ by two hours.
>
>
>
> Their first detail looks like this..
>
>
>
> Nov 08 00 06:26:15        0 m.c -rw-r--r-- root     root     /t/etc/=20=

> hosts.deny
>
>
>
> Where as the same command in my timeline is as follows=85
>
>
>
> Wed Nov 08 2000 08:26:15        0 m.c -/-rw-r--r-- root     =20
> root     26217    /etc/hosts.deny
>
>
>
> I have just checked Brian Carriers results and he also gets =20
> 08:26:15 within his timeline, and I am just wondering why there is =20
> a difference of two hours between the two results.  It was my =20
> understanding the time zone for the compromised image was GMT-0600, =20=

> so I setup my host using =91CST6CDT=92.

RE: [sleuthkit-users] Honeynet Forensic Challege TimeStamping

[Surago J. <su...@sj...>]

That was supposed to say 'an important event' not 'an import event'

=20

:-)

=20

________________________________

From: sle...@li...
[mailto:sle...@li...] On Behalf Of Surago
Jones
Sent: Wednesday, 7 September 2005 05:47
To: sle...@li...
Subject: [sleuthkit-users] Honeynet Forensic Challege TimeStamping

=20

Just a quick query for anyone that may have attempted the Forensic
Challenge available from the Honeynet Project
(http://www.honeynet.org/challenge/index.html)

=20

I have just created a timeline within Autopsy v2.05 and upon comparing
my times to the times in the answers provided by The Honeynet Projects
analysis
(http://www.honeynet.org/challenge/results/dittrich/evidence.txt) an
import event (The first modification made) I note that my results differ
by two hours.

=20

Their first detail looks like this..

=20

Nov 08 00 06:26:15        0 m.c -rw-r--r-- root     root
/t/etc/hosts.deny

=20

Where as the same command in my timeline is as follows...

=20

Wed Nov 08 2000 08:26:15        0 m.c -/-rw-r--r-- root     root
26217    /etc/hosts.deny

=20

I have just checked Brian Carriers results and he also gets 08:26:15
within his timeline, and I am just wondering why there is a difference
of two hours between the two results.  It was my understanding the time
zone for the compromised image was GMT-0600, so I setup my host using
'CST6CDT'.

=20

I also just checked some of the other contributors timelines, and a few
match what I have, where as others are quite different for the hours
(i.e. a couple people state the above modification occurs at 15.26:15 on
the same day.)

=20

What are the implications of performing an analysis on a system when it
is possible the analysis will be performed in different parts of the
world with varying time zones?  How important is it to be completely
accurate with time information, especially if when peer reviewed by
people in different time zones different times could be provided?  Does
this merely point out the importance of proper procedure when
establishing the correct 'time zone' of a compromised machine?

=20

I am not aware of the technical experience, or expertise of the
contributors to this challenge but it does come across as a very
important point, especially when one would hope that with correct
process and procedure another Forensic Examiner could arrive at the same
conclusion (Or times as this case may be)

=20

Any thoughts/ideas/comments would be appreciated, especially so if
anyone here had attempted the forensic challenge itself.

=20

Cheers

=20

Surago.

[sleuthkit-users] Honeynet Forensic Challege TimeStamping

[Surago J. <su...@sj...>]

Just a quick query for anyone that may have attempted the Forensic
Challenge available from the Honeynet Project
(http://www.honeynet.org/challenge/index.html)

=20

I have just created a timeline within Autopsy v2.05 and upon comparing
my times to the times in the answers provided by The Honeynet Projects
analysis
(http://www.honeynet.org/challenge/results/dittrich/evidence.txt) an
import event (The first modification made) I note that my results differ
by two hours.

=20

Their first detail looks like this..

=20

Nov 08 00 06:26:15        0 m.c -rw-r--r-- root     root
/t/etc/hosts.deny

=20

Where as the same command in my timeline is as follows...

=20

Wed Nov 08 2000 08:26:15        0 m.c -/-rw-r--r-- root     root
26217    /etc/hosts.deny

=20

I have just checked Brian Carriers results and he also gets 08:26:15
within his timeline, and I am just wondering why there is a difference
of two hours between the two results.  It was my understanding the time
zone for the compromised image was GMT-0600, so I setup my host using
'CST6CDT'.

=20

I also just checked some of the other contributors timelines, and a few
match what I have, where as others are quite different for the hours
(i.e. a couple people state the above modification occurs at 15.26:15 on
the same day.)

=20

What are the implications of performing an analysis on a system when it
is possible the analysis will be performed in different parts of the
world with varying time zones?  How important is it to be completely
accurate with time information, especially if when peer reviewed by
people in different time zones different times could be provided?  Does
this merely point out the importance of proper procedure when
establishing the correct 'time zone' of a compromised machine?

=20

I am not aware of the technical experience, or expertise of the
contributors to this challenge but it does come across as a very
important point, especially when one would hope that with correct
process and procedure another Forensic Examiner could arrive at the same
conclusion (Or times as this case may be)

=20

Any thoughts/ideas/comments would be appreciated, especially so if
anyone here had attempted the forensic challenge itself.

=20

Cheers

=20

Surago.

Re: [sleuthkit-users] Linux LVM on ext3: partitions or offsets?

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

On Sep 1, 2005, at 10:57 AM, Chris Stoughton wrote:

> I created a disk image using dd_rhelp, which claimed to finish  
> without error.  I am using sleuth kit ver 2.02 to inspect the disk  
> image, called dev-scd.img
>
> fdisk and mmls seem to disagree about the partitions.  Can you  
> help?  Is there something I need to do with the partition table or  
> offset calculations?  Do I need to set the cylinders in the image,  
> and if so, how?


The mmls output looks more normal since most partitions start in  
sector 63.  Further, mmls properly shows the location of the /boot/  
partition.  However, there is another level of partitions because LVM  
is being used.  The big partition at the end actually contains one or  
more partitions, which is why you can't run any tools directly on  
it.  I have not been able to restore LVM partitions using loopback or  
other techniques and have had to restore the image to a disk and boot  
a linux system.  This process is described in my book and you may be  
able to find some online references in the book bibliography:

http://digital-evidence.org/fsfa/biblio.html#ch7

brian



>
> Here is the output of fdisk -l
>
> # /sbin/fdisk -l dev-scd.img
> You must set cylinders.
> You can do this from the extra functions menu.
> Disk dev-scd.img: 0 MB, 0 bytes
> 255 heads, 63 sectors/track, 0 cylinders
> Units = cylinders of 16065 * 512 = 8225280 bytes
>      Device Boot    Start       End    Blocks   Id  System
> dev-scd.img1   *         1        13    104391   83  Linux
> dev-scd.img2            14      7296  58500697+  8e  Linux LVM
> Partition 2 has different physical/logical endings:
>     phys=(1023, 254, 63) logical=(7295, 254, 63)
>
> In the log file below, lines beginning with "+" echo the command  
> performed, generated by running this bash script:
>
> ========= listing of sleuth.sh ============================
> #!/bin/bash -x
> ls -l dev-scd.img
> img_stat -V
> mmls -V
> fsstat -V
> img_stat dev-scd.img
> mmls dev-scd.img
> fsstat -o 0 dev-scd.img
> fsstat -o 1 dev-scd.img
> fsstat -o 63 dev-scd.img
> fsstat -o 208845 dev-scd.img
>
>
> It looks like I can see the third partition (Linux 0x83) but I can  
> not see the fourth partition (Linux Logical Volume Manager (0x8e)  
> which is where the "good stuff" is I'd like to recover.
>
> Is there something else I need to be able to inspect a Linux  
> Logical Volume?
>
> The image was created from a disk which was running and ext3 file  
> system under Fedora Core3.  Please let me know if there is  
> something else I can provide.
>
> Thanks, and thanks for this tool set.
>
> Chris
>
> ======= log file of sleuth.sh  
> ========================================================
>
> + ls -l dev-scd.img
> -rw-r--r--    1 stoughto sdss     60003254272 Aug 31 16:40 dev-scd.img
> + img_stat -V
> The Sleuth Kit ver 2.02
> + mmls -V
> The Sleuth Kit ver 2.02
> + fsstat -V
> The Sleuth Kit ver 2.02
> + img_stat dev-scd.img
> IMAGE FILE INFORMATION
> --------------------------------------------
> Image Type: raw
> Size in bytes: 60003254272
> + mmls dev-scd.img
> DOS Partition Table
> Sector: 0
> Units are in 512-byte sectors
>     Slot    Start        End          Length       Description
> 00:  -----   0000000000   0000000000   0000000001   Primary Table (#0)
> 01:  -----   0000000001   0000000062   0000000062   Unallocated
> 02:  00:00   0000000063   0000208844   0000208782   Linux (0x83)
> 03:  00:01   0000208845   0117210239   0117001395   Linux Logical  
> Volume Manager (0x8e)
> + fsstat -o 0 dev-scd.img
> Cannot determine file system type
> + fsstat -o 1 dev-scd.img
> Cannot determine file system type
> + fsstat -o 63 dev-scd.img
> FILE SYSTEM INFORMATION
> --------------------------------------------
> File System Type: Ext3
> Volume Name: /boot
> Volume ID: 1c41e5f4cd136bb7a5448b3056203ba5
> Last Written at: Sun Aug 14 23:19:30 2005
> Last Checked at: Thu Feb  3 08:15:06 2005
> Last Mounted at: Sun Aug 14 23:19:30 2005
> Unmounted properly
> Last mounted on:
> Source OS: Linux
> Dynamic Structure
> Compat Features: Journal, Ext Attributes, Resize Inode, Dir Index
> InCompat Features: Filetype, Needs Recovery,
> Read Only Compat Features: Sparse Super,
> Journal ID: 00
> Journal Inode: 8
> METADATA INFORMATION
> --------------------------------------------
> Inode Range: 1 - 26104
> Root Directory: 2
> Free Inodes: 26040
> CONTENT INFORMATION
> --------------------------------------------
> Block Range: 0 - 104387
> Block Size: 1024
> Reserved Blocks Before Block Groups: 1
> Free Blocks: 69023
> BLOCK GROUP INFORMATION
> --------------------------------------------
> Number of Block Groups: 13
> Inodes per group: 2008
> Blocks per group: 8192
> Group: 0:
>  Inode Range: 1 - 2008
>  Block Range: 1 - 8192
>  Layout:
>    Super Block: 1 - 1
>    Group Descriptor Table: 2 - 2
>    Data bitmap: 259 - 259
>    Inode bitmap: 260 - 260
>    Inode Table: 261 - 511
>    Data Blocks: 512 - 8192
>  Free Inodes: 1984 (98%)
>  Free Blocks: 0 (0%)
>  Total Directories: 2
> Group: 1:
>  Inode Range: 2009 - 4016
>  Block Range: 8193 - 16384
>  Layout:
>    Super Block: 8193 - 8193
>    Group Descriptor Table: 8194 - 8194
>    Data bitmap: 8451 - 8451
>    Inode bitmap: 8452 - 8452
>    Inode Table: 8453 - 8703
>    Data Blocks: 8704 - 16384
>  Free Inodes: 1991 (99%)
>  Free Blocks: 3972 (48%)
>  Total Directories: 1
> Group: 2:
>  Inode Range: 4017 - 6024
>  Block Range: 16385 - 24576
>  Layout:
>    Data bitmap: 16385 - 16385
>    Inode bitmap: 16386 - 16386
>    Inode Table: 16387 - 16637
>    Data Blocks: 16387 - 16386, 16638 - 24576
>  Free Inodes: 2008 (100%)
>  Free Blocks: 7939 (96%)
>  Total Directories: 0
> Group: 3:
>  Inode Range: 6025 - 8032
>  Block Range: 24577 - 32768
>  Layout:
>    Super Block: 24577 - 24577
>    Group Descriptor Table: 24578 - 24578
>    Data bitmap: 24835 - 24835
>    Inode bitmap: 24836 - 24836
>    Inode Table: 24837 - 25087
>    Data Blocks: 25088 - 32768
>  Free Inodes: 1995 (99%)
>  Free Blocks: 0 (0%)
>  Total Directories: 0
> Group: 4:
>  Inode Range: 8033 - 10040
>  Block Range: 32769 - 40960
>  Layout:
>    Data bitmap: 32769 - 32769
>    Inode bitmap: 32770 - 32770
>    Inode Table: 32771 - 33021
>    Data Blocks: 32771 - 32770, 33022 - 40960
>  Free Inodes: 2008 (100%)
>  Free Blocks: 5821 (71%)
>  Total Directories: 0
> Group: 5:
>  Inode Range: 10041 - 12048
>  Block Range: 40961 - 49152
>  Layout:
>    Super Block: 40961 - 40961
>    Group Descriptor Table: 40962 - 40962
>    Data bitmap: 41219 - 41219
>    Inode bitmap: 41220 - 41220
>    Inode Table: 41221 - 41471
>    Data Blocks: 41472 - 49152
>  Free Inodes: 1998 (99%)
>  Free Blocks: 1074 (13%)
>  Total Directories: 0
> Group: 6:
>  Inode Range: 12049 - 14056
>  Block Range: 49153 - 57344
>  Layout:
>    Data bitmap: 49153 - 49153
>    Inode bitmap: 49154 - 49154
>    Inode Table: 49155 - 49405
>    Data Blocks: 49155 - 49154, 49406 - 57344
>  Free Inodes: 2008 (100%)
>  Free Blocks: 5208 (63%)
>  Total Directories: 0
> Group: 7:
>  Inode Range: 14057 - 16064
>  Block Range: 57345 - 65536
>  Layout:
>    Super Block: 57345 - 57345
>    Group Descriptor Table: 57346 - 57346
>    Data bitmap: 57603 - 57603
>    Inode bitmap: 57604 - 57604
>    Inode Table: 57605 - 57855
>    Data Blocks: 57856 - 65536
>  Free Inodes: 2008 (100%)
>  Free Blocks: 7681 (93%)
>  Total Directories: 0
> Group: 8:
>  Inode Range: 16065 - 18072
>  Block Range: 65537 - 73728
>  Layout:
>    Data bitmap: 65537 - 65537
>    Inode bitmap: 65538 - 65538
>    Inode Table: 65539 - 65789
>    Data Blocks: 65539 - 65538, 65790 - 73728
>  Free Inodes: 2008 (100%)
>  Free Blocks: 7939 (96%)
>  Total Directories: 0
> Group: 9:
>  Inode Range: 18073 - 20080
>  Block Range: 73729 - 81920
>  Layout:
>    Super Block: 73729 - 73729
>    Group Descriptor Table: 73730 - 73730
>    Data bitmap: 73987 - 73987
>    Inode bitmap: 73988 - 73988
>    Inode Table: 73989 - 74239
>    Data Blocks: 74240 - 81920
>  Free Inodes: 2008 (100%)
>  Free Blocks: 7681 (93%)
>  Total Directories: 0
> Group: 10:
>  Inode Range: 20081 - 22088
>  Block Range: 81921 - 90112
>  Layout:
>    Data bitmap: 81921 - 81921
>    Inode bitmap: 81922 - 81922
>    Inode Table: 81923 - 82173
>    Data Blocks: 81923 - 81922, 82174 - 90112
>  Free Inodes: 2008 (100%)
>  Free Blocks: 7939 (96%)
>  Total Directories: 0
> Group: 11:
>  Inode Range: 22089 - 24096
>  Block Range: 90113 - 98304
>  Layout:
>    Data bitmap: 90113 - 90113
>    Inode bitmap: 90114 - 90114
>    Inode Table: 90115 - 90365
>    Data Blocks: 90115 - 90114, 90366 - 98304
>  Free Inodes: 2008 (100%)
>  Free Blocks: 7939 (96%)
>  Total Directories: 0
> Group: 12:
>  Inode Range: 24097 - 26104
>  Block Range: 98305 - 104387
>  Layout:
>    Data bitmap: 98305 - 98305
>    Inode bitmap: 98306 - 98306
>    Inode Table: 98307 - 98557
>    Data Blocks: 98307 - 98306, 98558 - 104387
>  Free Inodes: 2008 (100%)
>  Free Blocks: 5830 (95%)
>  Total Directories: 0
> + fsstat -o 208845 dev-scd.img
> Cannot determine file system type
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle  
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams *  
> Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/ 
> bsce5sf
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>
>
>

Re: [sleuthkit-users] how can I undelete a file on Linux ext3?

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

On Aug 30, 2005, at 9:19 AM, beginner wrote:

> Hello,
>
> Did anyone has such experience?

You will probably need to rely on carving tools, such as foremost.   
The block pointers are cleared when an Ext3 file is deleted.  I did  
an article on this for Linux World:


Why Recovering a Deleted Ext3 File Is Difficult
http://linux.sys-con.com/author/5646Carrier.htm

brian

[sleuthkit-users] Linux LVM on ext3: partitions or offsets?

[Chris S. <sto...@fn...>]

I created a disk image using dd_rhelp, which claimed to finish without 
error.  I am using sleuth kit ver 2.02 to inspect the disk image, called 
dev-scd.img

fdisk and mmls seem to disagree about the partitions.  Can you help?  Is 
there something I need to do with the partition table or offset 
calculations?  Do I need to set the cylinders in the image, and if so, how?

Here is the output of fdisk -l

# /sbin/fdisk -l dev-scd.img
You must set cylinders.
You can do this from the extra functions menu.
 
Disk dev-scd.img: 0 MB, 0 bytes
255 heads, 63 sectors/track, 0 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
 
      Device Boot    Start       End    Blocks   Id  System
dev-scd.img1   *         1        13    104391   83  Linux
dev-scd.img2            14      7296  58500697+  8e  Linux LVM
Partition 2 has different physical/logical endings:
     phys=(1023, 254, 63) logical=(7295, 254, 63)

In the log file below, lines beginning with "+" echo the command 
performed, generated by running this bash script:

========= listing of sleuth.sh ============================
#!/bin/bash -x
ls -l dev-scd.img
img_stat -V
mmls -V
fsstat -V
img_stat dev-scd.img
mmls dev-scd.img
fsstat -o 0 dev-scd.img
fsstat -o 1 dev-scd.img
fsstat -o 63 dev-scd.img
fsstat -o 208845 dev-scd.img


It looks like I can see the third partition (Linux 0x83) but I can not 
see the fourth partition (Linux Logical Volume Manager (0x8e) which is 
where the "good stuff" is I'd like to recover.

Is there something else I need to be able to inspect a Linux Logical Volume?

The image was created from a disk which was running and ext3 file system 
under Fedora Core3.  Please let me know if there is something else I can 
provide.

Thanks, and thanks for this tool set.

Chris

======= log file of sleuth.sh 
========================================================

+ ls -l dev-scd.img
-rw-r--r--    1 stoughto sdss     60003254272 Aug 31 16:40 dev-scd.img
+ img_stat -V
The Sleuth Kit ver 2.02
+ mmls -V
The Sleuth Kit ver 2.02
+ fsstat -V
The Sleuth Kit ver 2.02
+ img_stat dev-scd.img
IMAGE FILE INFORMATION
--------------------------------------------
Image Type: raw
 
Size in bytes: 60003254272
+ mmls dev-scd.img
DOS Partition Table
Sector: 0
Units are in 512-byte sectors
 
     Slot    Start        End          Length       Description
00:  -----   0000000000   0000000000   0000000001   Primary Table (#0)
01:  -----   0000000001   0000000062   0000000062   Unallocated
02:  00:00   0000000063   0000208844   0000208782   Linux (0x83)
03:  00:01   0000208845   0117210239   0117001395   Linux Logical Volume 
Manager (0x8e)
+ fsstat -o 0 dev-scd.img
Cannot determine file system type
+ fsstat -o 1 dev-scd.img
Cannot determine file system type
+ fsstat -o 63 dev-scd.img
FILE SYSTEM INFORMATION
--------------------------------------------
File System Type: Ext3
Volume Name: /boot
Volume ID: 1c41e5f4cd136bb7a5448b3056203ba5
 
Last Written at: Sun Aug 14 23:19:30 2005
Last Checked at: Thu Feb  3 08:15:06 2005
 
Last Mounted at: Sun Aug 14 23:19:30 2005
Unmounted properly
Last mounted on:
 
Source OS: Linux
Dynamic Structure
Compat Features: Journal, Ext Attributes, Resize Inode, Dir Index
InCompat Features: Filetype, Needs Recovery,
Read Only Compat Features: Sparse Super,
 
Journal ID: 00
Journal Inode: 8
 
METADATA INFORMATION
--------------------------------------------
Inode Range: 1 - 26104
Root Directory: 2
Free Inodes: 26040
 
CONTENT INFORMATION
--------------------------------------------
Block Range: 0 - 104387
Block Size: 1024
Reserved Blocks Before Block Groups: 1
Free Blocks: 69023
 
BLOCK GROUP INFORMATION
--------------------------------------------
Number of Block Groups: 13
Inodes per group: 2008
Blocks per group: 8192
 
Group: 0:
  Inode Range: 1 - 2008
  Block Range: 1 - 8192
  Layout:
    Super Block: 1 - 1
    Group Descriptor Table: 2 - 2
    Data bitmap: 259 - 259
    Inode bitmap: 260 - 260
    Inode Table: 261 - 511
    Data Blocks: 512 - 8192
  Free Inodes: 1984 (98%)
  Free Blocks: 0 (0%)
  Total Directories: 2
 
Group: 1:
  Inode Range: 2009 - 4016
  Block Range: 8193 - 16384
  Layout:
    Super Block: 8193 - 8193
    Group Descriptor Table: 8194 - 8194
    Data bitmap: 8451 - 8451
    Inode bitmap: 8452 - 8452
    Inode Table: 8453 - 8703
    Data Blocks: 8704 - 16384
  Free Inodes: 1991 (99%)
  Free Blocks: 3972 (48%)
  Total Directories: 1
 
Group: 2:
  Inode Range: 4017 - 6024
  Block Range: 16385 - 24576
  Layout:
    Data bitmap: 16385 - 16385
    Inode bitmap: 16386 - 16386
    Inode Table: 16387 - 16637
    Data Blocks: 16387 - 16386, 16638 - 24576
  Free Inodes: 2008 (100%)
  Free Blocks: 7939 (96%)
  Total Directories: 0
 
Group: 3:
  Inode Range: 6025 - 8032
  Block Range: 24577 - 32768
  Layout:
    Super Block: 24577 - 24577
    Group Descriptor Table: 24578 - 24578
    Data bitmap: 24835 - 24835
    Inode bitmap: 24836 - 24836
    Inode Table: 24837 - 25087
    Data Blocks: 25088 - 32768
  Free Inodes: 1995 (99%)
  Free Blocks: 0 (0%)
  Total Directories: 0
 
Group: 4:
  Inode Range: 8033 - 10040
  Block Range: 32769 - 40960
  Layout:
    Data bitmap: 32769 - 32769
    Inode bitmap: 32770 - 32770
    Inode Table: 32771 - 33021
    Data Blocks: 32771 - 32770, 33022 - 40960
  Free Inodes: 2008 (100%)
  Free Blocks: 5821 (71%)
  Total Directories: 0
 
Group: 5:
  Inode Range: 10041 - 12048
  Block Range: 40961 - 49152
  Layout:
    Super Block: 40961 - 40961
    Group Descriptor Table: 40962 - 40962
    Data bitmap: 41219 - 41219
    Inode bitmap: 41220 - 41220
    Inode Table: 41221 - 41471
    Data Blocks: 41472 - 49152
  Free Inodes: 1998 (99%)
  Free Blocks: 1074 (13%)
  Total Directories: 0
 
Group: 6:
  Inode Range: 12049 - 14056
  Block Range: 49153 - 57344
  Layout:
    Data bitmap: 49153 - 49153
    Inode bitmap: 49154 - 49154
    Inode Table: 49155 - 49405
    Data Blocks: 49155 - 49154, 49406 - 57344
  Free Inodes: 2008 (100%)
  Free Blocks: 5208 (63%)
  Total Directories: 0
 
Group: 7:
  Inode Range: 14057 - 16064
  Block Range: 57345 - 65536
  Layout:
    Super Block: 57345 - 57345
    Group Descriptor Table: 57346 - 57346
    Data bitmap: 57603 - 57603
    Inode bitmap: 57604 - 57604
    Inode Table: 57605 - 57855
    Data Blocks: 57856 - 65536
  Free Inodes: 2008 (100%)
  Free Blocks: 7681 (93%)
  Total Directories: 0
 
Group: 8:
  Inode Range: 16065 - 18072
  Block Range: 65537 - 73728
  Layout:
    Data bitmap: 65537 - 65537
    Inode bitmap: 65538 - 65538
    Inode Table: 65539 - 65789
    Data Blocks: 65539 - 65538, 65790 - 73728
  Free Inodes: 2008 (100%)
  Free Blocks: 7939 (96%)
  Total Directories: 0
 
Group: 9:
  Inode Range: 18073 - 20080
  Block Range: 73729 - 81920
  Layout:
    Super Block: 73729 - 73729
    Group Descriptor Table: 73730 - 73730
    Data bitmap: 73987 - 73987
    Inode bitmap: 73988 - 73988
    Inode Table: 73989 - 74239
    Data Blocks: 74240 - 81920
  Free Inodes: 2008 (100%)
  Free Blocks: 7681 (93%)
  Total Directories: 0
 
Group: 10:
  Inode Range: 20081 - 22088
  Block Range: 81921 - 90112
  Layout:
    Data bitmap: 81921 - 81921
    Inode bitmap: 81922 - 81922
    Inode Table: 81923 - 82173
    Data Blocks: 81923 - 81922, 82174 - 90112
  Free Inodes: 2008 (100%)
  Free Blocks: 7939 (96%)
  Total Directories: 0
 
Group: 11:
  Inode Range: 22089 - 24096
  Block Range: 90113 - 98304
  Layout:
    Data bitmap: 90113 - 90113
    Inode bitmap: 90114 - 90114
    Inode Table: 90115 - 90365
    Data Blocks: 90115 - 90114, 90366 - 98304
  Free Inodes: 2008 (100%)
  Free Blocks: 7939 (96%)
  Total Directories: 0
 
Group: 12:
  Inode Range: 24097 - 26104
  Block Range: 98305 - 104387
  Layout:
    Data bitmap: 98305 - 98305
    Inode bitmap: 98306 - 98306
    Inode Table: 98307 - 98557
    Data Blocks: 98307 - 98306, 98558 - 104387
  Free Inodes: 2008 (100%)
  Free Blocks: 5830 (95%)
  Total Directories: 0
+ fsstat -o 208845 dev-scd.img
Cannot determine file system type

[sleuthkit-users] how can I undelete a file on Linux ext3?

[beginner <a_b...@16...>]

SGVsbG8sDQoNCkRpZCBhbnlvbmUgaGFzIHN1Y2ggZXhwZXJpZW5jZT8NCg0KVGhhbmsgeW91IHZl
cnkgbXVjaCBmb3IgYW55IGhlbHAhDQoNCmJlZ2lubmVy

Re: [sleuthkit-users] fls - error

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

On Thu, Aug 25, 2005 at 11:59:52AM +0200, Geert VAN ACKER wrote:
> I'm having a little problem with fls, output:
> 
> # fls -o 63 -r -m /mnt/case /mnt/flurk/hd1.dd > flsoutput
> fls: fatfs_file_walk: Invalid starting cluster address in Directory
> Entry (too large): 181248152

There is a file (probably deleted) with invalid data.   fls should
quietly ignore it.  My laptop recently died and I am waiting for a
replacement, so I will make the fix when everything is restored.

brian

Re: [sleuthkit-users] Keyword list in Autopsy

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

On Tue, Aug 23, 2005 at 12:05:03PM +0200, Geert VAN ACKER wrote:
> Hi list,
> 
> is there a possibility in autopsy to give a list of keywords to search
> for on a raw disk ?

Well, you can craft up a regular expression with all of the keywords in
one term, but the results will be a pain to go through.  You currently
need to do 1 by 1.

brian

[sleuthkit-users] fls - error

[Geert V. A. <gee...@pa...>]

I'm having a little problem with fls, output:

# fls -o 63 -r -m /mnt/case /mnt/flurk/hd1.dd > flsoutput
fls: fatfs_file_walk: Invalid starting cluster address in Directory
Entry (too large): 181248152

It's a hdd with 1 fat32 partitions starting at cluster 63, and I would
like to have a timeline (mactime)

Information about FS:

Sectors before file system: 63

File System Layout (in sectors)
Total Range: 0 - 6330176
* Reserved: 0 - 31
** Boot Sector: 0
** FS Info Sector: 1
** Backup Boot Sector: 6
* FAT 0: 32 - 6207
* FAT 1: 6208 - 12383
* Data Area: 12384 - 6330176
** Cluster Area: 12384 - 6330175
*** Root Directory: 12384 - 130855
** Non-clustered: 6330176 - 6330176

METADATA INFORMATION

Range: 2 - 101084674
Root Directory: 2

CONTENT INFORMATION

Sector Size: 512
Cluster Size: 4096
Total Cluster Range: 2 - 789725


Anyone who has idea ?

Brian, thanks for your efforts !

Thanks,

Geert VAN ACKER

[sleuthkit-users] Keyword list in Autopsy

[Geert V. A. <gee...@pa...>]

Hi list,

is there a possibility in autopsy to give a list of keywords to search
for on a raw disk ?

I know it's possible on the command line, just wondering if there is an
option somewhere in autopsy.

Thanks,

Geert VAN ACKER

Re: [sleuthkit-users] Corrupted floppy

[Nathan C. <na...@cc...>]

Sorry for the lag.

I have had success with reading 'damaged' sectors by using fdutils on
linux, this allows you to access the floppy controller at the raw level
(not through the linux floppy driver).

Even if the sector is in error fdutils *will* return data, not zeros as
when using dd. This allows you to:

1) Retry as many times as you want to re-read a particular sector until
you successfully read the sector (unlike the floppy driver in linux
which only retries several times, 3???).

2) Even if the CRC is incorrect recover some data in the sector.

When a floppy is on it's 'way out', use as many drives as you can lay
your hands on, chances are you will find a drive that at some point
*will* read the unreadable sector (unless it has been really badly
damaged).

Basically I ended up writing a perl script to use 'fdrawcmd' with a
ridiculous retry (50) to step through the disk sector-by-sector until it
was read, any sectors that wouldn't CRC check were just added anyway
(with whatever data was there).

This actually solved my problem, the next step would have been to
re-read the sectors in error and analyse the bytes in the read to see if
'good' bytes can be detected (by re-reading the sector and getting some
sort of consistent readings of bytes).

regards,

Nathan


On Sun, 2005-05-01 at 22:17 +0100, Enda Cronnolly wrote:
> I find that when accessing a damaged floppy from windows / linux through an
> application, when it can't read to EOF it refuses to display what it can
> read resulting in you not being able to retrieve any data. Even without the
> padded zero's, you will be able to read a corrupted file from the image
> through to EOF, and it will display all that is available despite the file
> integrity. Typically you loose a lot of formatting etc, and have to fish out
> the relevant info. Strings is very useful for that.
> 
>  -Enda.
> 
> ----- Original Message ----- 
> From: "Bradley B" <br...@de...>
> To: "'Enda Cronnolly'" <en...@co...>
> Cc: <sle...@li...>
> Sent: Sunday, May 01, 2005 1:33 AM
> Subject: RE: [sleuthkit-users] Corrupted floppy
> 
> 
> > When using conv=noerror it will begin writing to the file when it can read
> > more data, which will prevent offsets from being correct. A solution is
> > conv=sync,noerror where it will write zeroes when it has an error reading
> > the disk. I find using sleuthkit and autopsy to recover files on a damaged
> > filesystem is more successful than using the operating system and trying
> to
> > access the data.
> >
> > -----Original Message-----
> > From: sle...@li...
> > [mailto:sle...@li...] On Behalf Of Enda
> > Cronnolly
> > Sent: Monday, April 25, 2005 12:33 PM
> > To: sle...@li...
> > Subject: Re: [sleuthkit-users] Corrupted floppy
> >
> >
> > when dd'ing a floppy, try using bs=1 and conv=noerror, then mounting the
> > image under loopback.
> >
> > Have had sucess recovering some files which suffered the "thesis field
> > effect" that way where there was physical damage to the disk. Document
> > probably won't be 100% intact, but the majority of the content was
> > recoverable.
> >
> > HTH,
> >
> >  -Enda.
> >
> > ----- Original Message ----- 
> > From: "Brian Carrier" <ca...@sl...>
> > To: "Pradeep M" <pra...@gm...>
> > Cc: <sle...@li...>
> > Sent: Monday, April 25, 2005 3:18 PM
> > Subject: Re: [sleuthkit-users] Corrupted floppy
> >
> >
> > > How do you mean "corrupted"?  Is the file system corrupt or is the
> > > physical media damaged and it generates errors when you try to read it?
> > >   If it is physical damage, then TSK / Autopsy will not help.  If it is
> > > file system corruption, then you can try them but they will not fix any
> > > errors that exist.  You can also make  an image of the floppy using
> > > 'dd' and then run fsck on a copy so that it fixes any errors.
> > >
> > > brian
> > >
> > >
> > >
> > > On Apr 25, 2005, at 5:15 AM, Pradeep M wrote:
> > >
> > > > Hi
> > > >         Is it possible to recover data from  a corrupted floppy using
> > > > sleuthkit and autopsy.
> > > > I tried using the tool but first of all its not possible to mount the
> > > > floppy itself. I want to know whether it is possible to recover data
> > > > from a corrupted floppy using this tool and if its not possible then
> > > > which tool should be used. Pls help.
> > > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > SF email is sponsored by - The IT Product Guide
> > > Read honest & candid reviews on hundreds of IT Products from real users.
> > > Discover which products truly live up to the hype. Start reading now.
> > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> > > _______________________________________________
> > > sleuthkit-users mailing list
> > > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> > > http://www.sleuthkit.org
> > >
> >
> >
> >
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real users.
> > Discover which products truly live up to the hype. Start reading now.
> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&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: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4 great events, 4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

Re: [sleuthkit-users] fls & short names

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

On Aug 12, 2005, at 6:12 AM, dave wrote:
>>
> Hi Brian, no issues here, I'd love to see this happen. In particular,
> all entries in the path should show the long name when listing files
> and directories. I have attached a patch which does just this for 
> fat32,
> I use this in pyflag. Its a very minimal patch and could potentially
> truncate the path.

That will be included in this update as well.

Thanks.
brian

Re: [sleuthkit-users] fls & short names

[<da...@tp...>]

On Thu, Aug 11, 2005 at 12:23:09PM -0500, Brian Carrier wrote:
> I'm in the process of upgrading the unicode and short name handling of 
> TSK for FAT and NTFS.  Currently, fls prints the short (i.e. 8.3) name 
> of a FAT file in parentheses, but skips the short name for NTFS files.  
> I'm inclined to change the behavior so that the short FAT name is also 
> skipped.  It can be found from the istat output, but would not be in 
> the fls output.  Anyone have major issues with that and find the short 
> names useful?

Hi Brian, no issues here, I'd love to see this happen. In particular,
all entries in the path should show the long name when listing files 
and directories. I have attached a patch which does just this for fat32,
I use this in pyflag. Its a very minimal patch and could potentially 
truncate the path.

Dave

> 
> thanks,
> brian
> 
> PS - For those who have asked, yes I realize that I missed the July 
> 15th issue of the Informer...  too many things going on.
> 
> PPS - For those who will be at DFRWS or HTCIA in the next few weeks, I 
> got some small TSK stickers made up so come track me down if you want 
> some.
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
> 

[sleuthkit-users] fls & short names

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

I'm in the process of upgrading the unicode and short name handling of 
TSK for FAT and NTFS.  Currently, fls prints the short (i.e. 8.3) name 
of a FAT file in parentheses, but skips the short name for NTFS files.  
I'm inclined to change the behavior so that the short FAT name is also 
skipped.  It can be found from the istat output, but would not be in 
the fls output.  Anyone have major issues with that and find the short 
names useful?

thanks,
brian

PS - For those who have asked, yes I realize that I missed the July 
15th issue of the Informer...  too many things going on.

PPS - For those who will be at DFRWS or HTCIA in the next few weeks, I 
got some small TSK stickers made up so come track me down if you want 
some.

Re: [sleuthkit-users] file analysis in autopsy

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

On Jul 29, 2005, at 5:36 PM, youcef bichbiche wrote:

> Hi,
> I got a couple of questions regarding file analysis in
> autopsy.
>
> When conduction a file type analysis using the
> undelete images test #6 I came up with a summary
> where:
>
> Files (27)
> Files Skipped (9)
>
>
> 1- Can I assume that the skipped files in FAT system
> would be used to list the directory & volume entries,
> in other word any directory entry structure that's not
> a file?

I forget the details of this specific image, but that is typically the 
reason for the skipped files (and device files in Unix systems).

> 2- Also under the mismatch section I've seen a zero
> hit even though there is an image on the image system
> with a dll extension, like in the volume lable test
> image #9.
>
> How does autopsy detect mistmach. Does it need a hash
> database or can it use the file command instead?

Interesting. I hadn't noticed that one before.  The reason that it 
occurs with test #9 is that those "dll" files have an attribute type of 
volume label, which means that the 11 bytes in the name field are used 
as a full name and a '.' isn't added between bytes 8 and 9 (like what 
happens for normal directory entries).  Therefore, the name of the file 
is "FILE2   DLL" with spaces between the name and extension.  That is 
why 'sorter' does not pick them up as extension mismatches -- because 
there is no extension.

> 2- Looking at the saved files in the data category,
> I've seen a lot of files with a dead suffix like:
> data/6-fat-undel.dd-4-dead
> data/6-fat-undel.dd-5-dead
> data/6-fat-undel.dd-6-dead
>
> Interestingly enough the same inodes are also used for
> recovered files like:
>
> C:/_rag1.dat
> data/6-fat-undel.dd-4.dat
>
> C:/_rag2.dat
> data/6-fat-undel.dd-5.dat
>
> C:/_ing.dat
> data/6-fat-undel.dd-6.dat
>
>
> What are these files? and Why they are considered dead
> when they already appear as undeleted?

dead and deleted are the same.  The dead ones are found by looking for 
any unallocated directory entry.  This searches every sector of the 
disk. The "_XYZ" ones are from recursing the directory hierarchy.  
There will be overlap. Ideally, I should keep a history of the ones 
found from recursing the directory and show them only once, but 
currently they are in their twice.  There could be "dead" ones that are 
not in the directory structure if the parent directory was deleted and 
could not be recovered.

brian

Re: [sleuthkit-users] Was FAT32, now NTFS

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

On Jul 26, 2005, at 5:26 PM, Mark K. Murdock wrote:

> Hi all,
>
> I have a drive that was previously a FAT32 drive on a Windows ME=20
> system.=A0 The drive was recently formatted as NTFS in Windows XP (and=20=

> *very* little activity has occurred on it since then).=A0 I still see=20=

> FAT structures on the drive, as well as data, but I'm having a=20
> difficult time importing it into Autopsy for examination.=A0 Choosing=20=

> NTFS as the image filesystem doesn't seem correct, since the data I=20
> want to access is in the residual FAT structures.=A0 Choosing a FAT=20
> filesystem doesn't work, because of the current NTFS format of the=20
> filesystem.=A0 Are there any simple methods I can use to salvage FAT=20=

> structures and files through Sleuthkit/Autopsy?


Sleuth Kit and Autopsy can't repair damaged file systems.

brian=

[sleuthkit-users] file analysis in autopsy

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

Hi,
I got a couple of questions regarding file analysis in
autopsy.

When conduction a file type analysis using the
undelete images test #6 I came up with a summary
where:

Files (27) 
Files Skipped (9) 


1- Can I assume that the skipped files in FAT system
would be used to list the directory & volume entries,
in other word any directory entry structure that's not
a file?

2- Also under the mismatch section I've seen a zero
hit even though there is an image on the image system
with a dll extension, like in the volume lable test
image #9.

How does autopsy detect mistmach. Does it need a hash
database or can it use the file command instead?

2- Looking at the saved files in the data category,
I've seen a lot of files with a dead suffix like:
data/6-fat-undel.dd-4-dead
data/6-fat-undel.dd-5-dead
data/6-fat-undel.dd-6-dead

Interestingly enough the same inodes are also used for
recovered files like:

C:/_rag1.dat
data/6-fat-undel.dd-4.dat

C:/_rag2.dat
data/6-fat-undel.dd-5.dat

C:/_ing.dat
data/6-fat-undel.dd-6.dat


What are these files? and Why they are considered dead
when they already appear as undeleted?


Regards

Youcef



		
___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

[sleuthkit-users] Was FAT32, now NTFS

[Mark K. M. <mar...@la...>]

Hi all,

I have a drive that was previously a FAT32 drive on a Windows ME system.
The drive was recently formatted as NTFS in Windows XP (and *very*
little activity has occurred on it since then).  I still see FAT
structures on the drive, as well as data, but I'm having a difficult
time importing it into Autopsy for examination.  Choosing NTFS as the
image filesystem doesn't seem correct, since the data I want to access
is in the residual FAT structures.  Choosing a FAT filesystem doesn't
work, because of the current NTFS format of the filesystem.  Are there
any simple methods I can use to salvage FAT structures and files through
Sleuthkit/Autopsy?

Thanks,
Mark K. Murdock, CISSP
Lantern Secure Solutions, LLC
Office: (314) 721-1600
Direct: (314) 283-4317
************************************************************************
***
This email and any files transmitted with it are confidential and
intended
solely for the use of the individual or entity to whom they are
addressed.
If you have received this email in error please notify the sender.
************************************************************************
***

Re: [sleuthkit-users] fsstat computation method

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

For both of these calculations, you need to use the sector count that 
is allocated to clusters.

* Data Area: 30016 - 61432496
** Cluster Area: 30016 - 61432479
*** Root Directory: 30016 - 30047
** Non-clustered: 61432480 - 61432496

There are 17 sectors at the end of the Data Area that are not allocated 
to a cluster and therefore they are not used in the calculation.  So, 
use 61432479 instead of 61432496.

brian


On Jul 25, 2005, at 4:39 PM, youcef bichbiche wrote:

> Hi,
> does anyone know how the values shown in fsstat are
> computed for the meta-data range and the content
> cluster range?
>
> if I take the example shown in the informer #18, we
> have a FAT32 file system with with sectors ranging
> from 0-61432496. the data area start at 30016 sector.
>
> according to my understanding the meta-data would be:
> 61432496-30016 = 61402480 addreesable sectors
> each sector can hold 16 meta-data entry (i.e. 512/32)
> so the addressable mata-data range is: 61402480*16
> which gives me: 982439680. because TSK assumes that
> the meta-data range doesnt start from 0 but from 3
> then the result will be 982439683 which different from
> the value given in the informer which is 982439426.
>
> the same thing for the cluster range:
> 61432496-30016 = 61402480
> 61402480/32 = 1918827.5
> why it's being rounded to 1818828 and not 1918827?
>
> My last question is just a recommnedation for this
> wonderful tool. I really think that directory entry
> which contains long file name should show the sequence
> number and the checksum. this will ensure that the
> long file name and short name match up and can help to
> detect hiding data by using unconnected long file name
> entries.
>
> regards
>
> youcef
>
>
>
> 	
> 	
> 		
> ___________________________________________________________
> Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with 
> voicemail http://uk.messenger.yahoo.com
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>
>

[sleuthkit-users] fsstat computation method

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

Hi,
does anyone know how the values shown in fsstat are
computed for the meta-data range and the content
cluster range?

if I take the example shown in the informer #18, we
have a FAT32 file system with with sectors ranging
from 0-61432496. the data area start at 30016 sector.

according to my understanding the meta-data would be:
61432496-30016 = 61402480 addreesable sectors
each sector can hold 16 meta-data entry (i.e. 512/32)
so the addressable mata-data range is: 61402480*16
which gives me: 982439680. because TSK assumes that
the meta-data range doesnt start from 0 but from 3
then the result will be 982439683 which different from
the value given in the informer which is 982439426.

the same thing for the cluster range: 
61432496-30016 = 61402480
61402480/32 = 1918827.5
why it's being rounded to 1818828 and not 1918827?

My last question is just a recommnedation for this
wonderful tool. I really think that directory entry
which contains long file name should show the sequence
number and the checksum. this will ensure that the
long file name and short name match up and can help to
detect hiding data by using unconnected long file name
entries.

regards

youcef



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