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

Re: [sleuthkit-users] Examining RAID-5 with only 1 drive

[DePriest, J. R. <jrd...@gm...>]

On 11/10/06, Simson L. Garfinkel's Treo 700p  wrote:
- - - - - - - - - - 8< - - - - - - - - - - - - - - - - - - - -
> >Brian's book claims that I might have luck with a simple keyword
> >search, but has anyone had any experience to back it up?
>
> Yes, but it depends on what you are looking for. What kinds of object are
> you looking for? Word file? JPEG? Incriminating sentence?
- - - - - - - - - - - - - - - - - - - - - >8 - - - - - - - - -

Most likely, the information would either be contained in some sort of
email file, HTML file, or plain-text file.

-Jason

-- 
+ + + NO CARRIER

Re: [sleuthkit-users] Examining RAID-5 with only 1 drive

[Colby Gutierrez-K. <co...@ge...>]

On Nov 10, 2006, at 1:24 PM, Simson L. Garfinkel's Treo 700p wrote:

>
> ___
> Sent with SnapperMail
> www.snappermail.com
>
> ...... Original Message .......
> On Fri, 10 Nov 2006 09:39:28 -0800 "Colby Gutierrez-Kraybill"
> <co...@ge...> wrote:
>>
>> On Nov 10, 2006, at 8:50 AM, DePriest, Jason R. wrote:
>>
>>>
>>> I am only assuming this is RAID-5 since "the other two drives" were
>>> mentioned as being discarded.
>>>
>>
>> It could be from a RAID-3, and if it's the parity drive from that  
>> set,
>> then the chance of getting anything useful off of it is 0%.  If it's
>> one of the other disks from the RAID-3, then chances are about 50%
>> in the best case (see data block size vs actionable data below).
>
>
> Who uses RAID-3? Most controllers don't even support it...


The XFX Revo64 3-port does.  I don't think it was out 3+ years ago  
though.
Don't know other controllers that support it off the top of my head.   
Use
them a lot because they are transparent to the OS.

I also pointed out in a private e-mail that perhaps you could get  
information
off of the parity drive if you already knew the text you were looking  
for
and approached the problem from the angle of retrieving a key  
(missing info)
when you already have the known text (keyword(s)) and the crypt text
(parity info) available.

Just depends on how hard you're willing to work for it and whether or
not you can convince a court that the information really is there.

Or maybe I'm being daft.

- Colby

Re: [sleuthkit-users] Examining RAID-5 with only 1 drive

[Simson L. Garfinkel's T. 7. <si...@ac...>]

___
Sent with SnapperMail
www.snappermail.com

...... Original Message .......
On Fri, 10 Nov 2006 09:39:28 -0800 "Colby Gutierrez-Kraybill" 
<co...@ge...> wrote:
>
>On Nov 10, 2006, at 8:50 AM, DePriest, Jason R. wrote:
>
>>
>> I am only assuming this is RAID-5 since "the other two drives" were
>> mentioned as being discarded.
>>
>
>It could be from a RAID-3, and if it's the parity drive from that set,
>then the chance of getting anything useful off of it is 0%.  If it's
>one of the other disks from the RAID-3, then chances are about 50%
>in the best case (see data block size vs actionable data below).


Who uses RAID-3? Most controllers don't even support it...
>
>>
>> Is it possible for me to get anything useful out of this single drive?
>>
>
>Yes.
>
>> Brian's book claims that I might have luck with a simple keyword
>> search, but has anyone had any experience to back it up?
>>
>
>Not directly, no.
>
>If you're lucky, and it really is from a RAID-5 set, and the block
>size was set to something large, like say 64KB, and the information
>you're looking for was plain text, then the chances are better that
>you'll find enough data intact to pass along.  If the blocks are
>smaller, then chances are slimmer.  It depends on what size
>of data block is actionable for the court case.  If it's under
>4KB (which is the usual default block size) then I'd say the
>33/67 break down is close enough.  If larger, then the the 33%
>chance must shrink.
>
>
>> I probably cannot discuss what I am looking for per the litigation,
>> but a simple keyword search would be useful and possibly even
>> adequate.
>>
>
>Huzzah!
>
>> Pulling numbers out of the air, I told the person sending me the drive
>> that there is only a 33% chance that useful information is on this
>> drive and a 67% chance that there is nothing on there.
>>
>> That was just based on RAID-5 taking 3 disks... in retrospect, I
>> realize that those numbers aren't right since RAID-5 can survive while
>> a disk is being replaced.
>>
>
>It can only survive if there are at least two remaining members (out  
>of three)
>because the data on the missing disk can be recovered based on the data
>and parity information from the other two.  Having just one disk doesn't
>help at all.
>
>> So, I don't know what I am really asking for except for other people's
>> experiences and advice on this type of investigation.
>>
>
>Not much help really.  Mostly trying to set expectations.
>
>- Colby
>
>
>-------------------------------------------------------------------------
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job 
easier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>_______________________________________________
>sleuthkit-users mailing list
>https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>http://www.sleuthkit.org
>

Re: [sleuthkit-users] Examining RAID-5 with only 1 drive

[<rob...@us...>]

Let me try that again...Raid 0 (striped, no parity), not raid 1 (mirroring) :)

ROBERT C. CIPRIANI
1LT, SC, FLARNG
XO, A/146TH SIG BN
"VOICE OF COMMAND"
H:(813) 333-2676
W:(727) 329-2000 x74264

"Whenever you do a thing, act as if all the world were watching." - Thomas Jefferson 

----- Original Message -----
From: Colby Gutierrez-Kraybill <co...@ge...>
Date: Friday, November 10, 2006 12:39 pm
Subject: Re: [sleuthkit-users] Examining RAID-5 with only 1 drive

> 
> On Nov 10, 2006, at 8:50 AM, DePriest, Jason R. wrote:
> 
> >
> > I am only assuming this is RAID-5 since "the other two drives" were
> > mentioned as being discarded.
> >
> 
> It could be from a RAID-3, and if it's the parity drive from that set,
> then the chance of getting anything useful off of it is 0%.  If it's
> one of the other disks from the RAID-3, then chances are about 50%
> in the best case (see data block size vs actionable data below).
> 
> >
> > Is it possible for me to get anything useful out of this single 
> drive?>
> 
> Yes.
> 
> > Brian's book claims that I might have luck with a simple keyword
> > search, but has anyone had any experience to back it up?
> >
> 
> Not directly, no.
> 
> If you're lucky, and it really is from a RAID-5 set, and the block
> size was set to something large, like say 64KB, and the information
> you're looking for was plain text, then the chances are better that
> you'll find enough data intact to pass along.  If the blocks are
> smaller, then chances are slimmer.  It depends on what size
> of data block is actionable for the court case.  If it's under
> 4KB (which is the usual default block size) then I'd say the
> 33/67 break down is close enough.  If larger, then the the 33%
> chance must shrink.
> 
> 
> > I probably cannot discuss what I am looking for per the litigation,
> > but a simple keyword search would be useful and possibly even
> > adequate.
> >
> 
> Huzzah!
> 
> > Pulling numbers out of the air, I told the person sending me the 
> drive> that there is only a 33% chance that useful information is 
> on this
> > drive and a 67% chance that there is nothing on there.
> >
> > That was just based on RAID-5 taking 3 disks... in retrospect, I
> > realize that those numbers aren't right since RAID-5 can survive 
> while> a disk is being replaced.
> >
> 
> It can only survive if there are at least two remaining members 
> (out  
> of three)
> because the data on the missing disk can be recovered based on the 
> dataand parity information from the other two.  Having just one 
> disk doesn't
> help at all.
> 
> > So, I don't know what I am really asking for except for other 
> people's> experiences and advice on this type of investigation.
> >
> 
> Not much help really.  Mostly trying to set expectations.
> 
> - Colby
> 
> 
> -------------------------------------------------------------------
> ------
> Using Tomcat but need to do more? Need to support web services, 
> security?Get stuff done quickly with pre-integrated technology to 
> make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache 
> Geronimohttp://sel.as-
> us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642_______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
> 

Re: [sleuthkit-users] Examining RAID-5 with only 1 drive

[Colby Gutierrez-K. <co...@ge...>]

On Nov 10, 2006, at 8:50 AM, DePriest, Jason R. wrote:

>
> I am only assuming this is RAID-5 since "the other two drives" were
> mentioned as being discarded.
>

It could be from a RAID-3, and if it's the parity drive from that set,
then the chance of getting anything useful off of it is 0%.  If it's
one of the other disks from the RAID-3, then chances are about 50%
in the best case (see data block size vs actionable data below).

>
> Is it possible for me to get anything useful out of this single drive?
>

Yes.

> Brian's book claims that I might have luck with a simple keyword
> search, but has anyone had any experience to back it up?
>

Not directly, no.

If you're lucky, and it really is from a RAID-5 set, and the block
size was set to something large, like say 64KB, and the information
you're looking for was plain text, then the chances are better that
you'll find enough data intact to pass along.  If the blocks are
smaller, then chances are slimmer.  It depends on what size
of data block is actionable for the court case.  If it's under
4KB (which is the usual default block size) then I'd say the
33/67 break down is close enough.  If larger, then the the 33%
chance must shrink.


> I probably cannot discuss what I am looking for per the litigation,
> but a simple keyword search would be useful and possibly even
> adequate.
>

Huzzah!

> Pulling numbers out of the air, I told the person sending me the drive
> that there is only a 33% chance that useful information is on this
> drive and a 67% chance that there is nothing on there.
>
> That was just based on RAID-5 taking 3 disks... in retrospect, I
> realize that those numbers aren't right since RAID-5 can survive while
> a disk is being replaced.
>

It can only survive if there are at least two remaining members (out  
of three)
because the data on the missing disk can be recovered based on the data
and parity information from the other two.  Having just one disk doesn't
help at all.

> So, I don't know what I am really asking for except for other people's
> experiences and advice on this type of investigation.
>

Not much help really.  Mostly trying to set expectations.

- Colby

[sleuthkit-users] Examining RAID-5 with only 1 drive

[DePriest, J. R. <jrd...@gm...>]

This upcoming Monday, I am going to have to assist in an investigation
involving a single drive from a RAID system.

The drive was pulled two years ago and neither the original system nor
the other drives exist any more.

This investigation involves litigation so I have to make sure I use
due diligence.

I am only assuming this is RAID-5 since "the other two drives" were
mentioned as being discarded.

And since both the system and whatever controller was being used is
gone, I can't know for sure.

Is it possible for me to get anything useful out of this single drive?

Brian's book claims that I might have luck with a simple keyword
search, but has anyone had any experience to back it up?

I probably cannot discuss what I am looking for per the litigation,
but a simple keyword search would be useful and possibly even
adequate.

Pulling numbers out of the air, I told the person sending me the drive
that there is only a 33% chance that useful information is on this
drive and a 67% chance that there is nothing on there.

That was just based on RAID-5 taking 3 disks... in retrospect, I
realize that those numbers aren't right since RAID-5 can survive while
a disk is being replaced.

So, I don't know what I am really asking for except for other people's
experiences and advice on this type of investigation.

-- 
+ + + NO CARRIER

Re: [sleuthkit-users] Current/future status of HFS+ support?

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

You probably did not uncomment enough code in fs_open.c (or fs_types.c) 
if you are getting that error message.  HFS+ will not compile with the 
latest versions because there have been many internal changes and 
improvements that were not made to HFS+.  Wyatt Banks has been the main 
person for HFS+, so he can better comment on what its status is.

brian

Brian Smith-Sweeney wrote:
> Barry J. Grundy wrote:
>> On Mon, 2006-10-30 at 09:51 -0500, Brian Smith-Sweeney wrote:
>>
>>> unknown filesystem type: hfs+
>>> known types:
>> ...
>>>         hfs (HFS+)
>> ...
>>
>> The error is telling you that "hfs+" is an incorrect argument.  It then
>> goes on to tell you that "hfs" is the correct argument for HFS+...
>> Rerun your commands with just "hfs" (drop the +) and see if that helps.
>>
> Sorry, that was a typo this morning when I was re-running the command to
> recreate the error.  Previously I had typed it correctly; I just
> confirmed this again:
> 
> unknown filesystem type: hfs
> known types:
>         ext (Ext2/Ext3)
>         fat (FAT12/16/32)
>         ntfs (NTFS)
>         hfs (HFS+)
>         ufs (UFS 1 & 2)
>         raw (Raw Data)
>         swap (Swap Space)
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

Re: [sleuthkit-users] Current/future status of HFS+ support?

[Brian Smith-S. <ti...@ny...>]

Barry J. Grundy wrote:
> On Mon, 2006-10-30 at 09:51 -0500, Brian Smith-Sweeney wrote:
> 
>> unknown filesystem type: hfs+
>> known types:
> ...
>>         hfs (HFS+)
> ...
> 
> The error is telling you that "hfs+" is an incorrect argument.  It then
> goes on to tell you that "hfs" is the correct argument for HFS+...
> Rerun your commands with just "hfs" (drop the +) and see if that helps.
> 
Sorry, that was a typo this morning when I was re-running the command to
recreate the error.  Previously I had typed it correctly; I just
confirmed this again:

unknown filesystem type: hfs
known types:
        ext (Ext2/Ext3)
        fat (FAT12/16/32)
        ntfs (NTFS)
        hfs (HFS+)
        ufs (UFS 1 & 2)
        raw (Raw Data)
        swap (Swap Space)

Re: [sleuthkit-users] Current/future status of HFS+ support?

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

On Mon, 2006-10-30 at 09:51 -0500, Brian Smith-Sweeney wrote:

> unknown filesystem type: hfs+
> known types:
...
>         hfs (HFS+)
...

The error is telling you that "hfs+" is an incorrect argument.  It then
goes on to tell you that "hfs" is the correct argument for HFS+...
Rerun your commands with just "hfs" (drop the +) and see if that helps.

Barry
NASA OIG CCD

! WARNING !  This email including any attachments is intended only for
authorized recipients.  Recipients may only forward this information as
authorized.  This email may contain non-public information that is "Law
Enforcement Sensitive," "Sensitive but Unclassified," or otherwise
subject to the Privacy Act and/or legal and other applicable privileges
that restrict release without appropriate legal authority and clearance.
Accordingly, the use, dissemination, distribution or reproduction of
this information to or by unauthorized or unintended recipients,
including but not limited to non-NASA recipients, may be unlawful.

[sleuthkit-users] Current/future status of HFS+ support?

[Brian Smith-S. <ti...@ny...>]

Hey folks,

I recently had to perform an analysis on an OS X box using HFS+ and was
surprised to find Sleuthkit didn't support HFS+.  I grep'd through the
mail archives and found one note about it working if you uncommented the
relevant lines, and then another later post stating it's unsupported.
It is mentioned in the CHANGES file though.

2.06 won't compile with the HFS+ stuff uncommented.  2.03 would, but I
ended up with most of the filesystem utilities giving me back the
following error:

unknown filesystem type: hfs+
known types:
        ext (Ext2/Ext3)
        fat (FAT12/16/32)
        ntfs (NTFS)
        hfs (HFS+)
        ufs (UFS 1 & 2)
        raw (Raw Data)
        swap (Swap Space)

So clearly I did something wrong; that something may have been
attempting to use Sleuthkit for this purpose.  Is there any way to get
HFS+ working, and if not is there any intention to get this working in
the future?

Cheers,
Brian

Re: [sleuthkit-users] You opinion needed on clicking harddisk (with video)

[Simson G. <si...@ac...>]

Hi, Jelle.  Your poor little disk drive is looking for tracking  
information.  It moves the head out, looks around, and can't find any  
sector numbers. It it goes back home, moves the head out again, and  
tries again.


On Oct 30, 2006, at 5:05 AM, Jelle S. wrote:

> Hi all,
>
> Granted, a bit off topic for this list,...
>
> I have this portable harddisk which has "died".
> No important data is on it.  So experimenting with the disk for
> educational purposes is no problem.
> I have opened the disk to check what the clicking noise exactly was.
> I have made a short video of this:
>
> http://www.youtube.com/watch?v=yFz8K-eODUA
>
> What could be the cause of this ?
>
> Thanks all,..
>
>
> ---------------------------------------------------------------------- 
> ---
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>

Re: [sleuthkit-users] You opinion needed on clicking harddisk (withvideo)

[Svein Y. W. <sv...@wi...>]

 
> I have this portable harddisk which has "died".
> No important data is on it.  So experimenting with the disk for
> educational purposes is no problem.
> I have opened the disk to check what the clicking noise exactly was.
> I have made a short video of this:
> 
> http://www.youtube.com/watch?v=yFz8K-eODUA

Unfortunately I was not able to open your video, but in general: 

"Clicking sounds" is a very common failure mode for hard drives. The
explanation goes back to the way hard drives are made. 

The r/w head is mounted on the end of an arm above the platters. The arm is
fixed to an actuator. The actuator moves the arm, thereby moving the r/w
head from one track to another. The positioning of the arm is determined by
using a feedback of the signal read from the disk: In order to accurately
position the head above a data track, the signal stored on the track is
amplified and fed back into the actuator to move the head into a position
where it is at the centre of the track. Due to the very small size of the
tracks, this system works much better than any mechanical or pre-programmed
positioning of the tracks.

Now, consider what happens if one of the heads stops working: there will no
longer be a signal to amplify, and it will no longer be possible for the
actuator to position the read/write head above a track. In this situation,
the arm with the r/w head will search for tracks in vain and will inevitably
crash with the centre-spindle, causing the click sound. In most cases, the
disk controller will try again a number of times before it gives up, causing
a number of repeated click sounds.

R/w-heads are very sensitive electromechanical devices, so although there
could also be other explanations, the most likely reason for this failure
mode is one or more defective r/w heads. Defects in r/w heads may be caused
by electric shock (even small static voltages may cause damage), crash
(often due to movement while the unit was operational), heat or perhaps
other reasons.


Regards,

Svein Willassen
Researcher, Department of Telematics
Norwegian University of Science and Technology

[sleuthkit-users] You opinion needed on clicking harddisk (with video)

[Jelle S. <fo...@em...>]

Hi all,

Granted, a bit off topic for this list,...

I have this portable harddisk which has "died".
No important data is on it.  So experimenting with the disk for
educational purposes is no problem.
I have opened the disk to check what the clicking noise exactly was.
I have made a short video of this:

http://www.youtube.com/watch?v=yFz8K-eODUA

What could be the cause of this ?

Thanks all,..

[sleuthkit-users] obtaining a viable image of an encrypted hard disk drive

[DePriest, J. R. <jrd...@gm...>]

I use Sleuthkit and Autopsy for forensic investigations at work.

I have been struggling with my first Pointsec
(http://www.pointsec.com) whole disk encrypted hard disk drive.

Pointsec is our enterprises chosen method of whole disk encryption
which was purchased without input from IT Risk Management (which
includes Data Security), so we had no idea what we were getting into
from an investigation point of view.

According to Pointsec's technical support, you can create an image of
a Pointsec encrypted disk by booting off of a CD or floppy.  This
image will be complete gibberish and there is no way to decrypt the
data inside of it.

They also told me that if you get to the Pointsec authorization screen
(which comes up right after POST and before initializing the OS) and
press a magic key combination you can choose another boot device.

You still have to have the proper user name and password to authorize
the decryption (which I have).

If you press CTRL-F9, Pointsec tries to boot from the floppy drive.
If you press CTRL-F10, Pointsec lets you pick.

I booted from a Helix CD and have tried on two occasions to create an image.

Both are unrecognizable to Sleuthkit.

The only image I have that is mountable is one I created by removing
the hard disk drive from the laptop and connecting it to a Windows
system via a firewire attached write blocker.

The image is useless however, because everything is encrypted.

Some information about the images.

First image information --
Pointsec status: disk encrypted
Hard disk read / write: hardware write block
Host OS: Windows 2003 Server with SP1
Imaging Application: dd from George M. Garner, Jr.'s Forensic
Acquisition Utilities (http://users.erols.com/gmgarner/forensics/)
Imaging Application options: conv=noerror
Imaging Results: 9767003+0 records in, 9767520+0 records out (517
'Permission denied' errors)
mmls says:
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
$ /sleuthkit/sleuthkit/bin/mmls -v -t dos -i raw
/cygdrive/g/SP/2006/2006-027/hdd/2006-027-01.img
img_open: Type: raw   NumImg: 1  Img1:
/cygdrive/g/SP/2006/2006-027/hdd/2006-027-01.img
dos_load_prim: Table Sector: 0
raw_read_random: byte offset: 0 len: 512
load_pri:0:0    Start: 63   Size: 78124977  Type: 7
load_pri:0:1    Start: 0   Size: 0  Type: 0
load_pri:0:2    Start: 0   Size: 0  Type: 0
load_pri:0:3    Start: 0   Size: 0  Type: 0
DOS Partition Table
Offset 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   0078125039   0078124977   NTFS (0x07)
03:  -----   0078125040   0078140159   0000015120   Unallocated

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Second image information --
Pointsec status: disk encrypted
Hard disk read / write: hardware write block
Host OS: cygwin 1.5.21(0.156/4/2) on Windows 2003 Server with SP1
Imaging Application: GNU ddrescue
(http://www.gnu.org/software/ddrescue/ddrescue.html)
Imaging Application options: -r 8 -v
Imaging Results: rescued 40006 MB,  errsize 1570 kB, errors 3068
mmls says:
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
$ /sleuthkit/sleuthkit/bin/mmls -v -t dos -i raw
/cygdrive/g/SP/2006/2006-027/hdd/2006-027-02.img
img_open: Type: raw   NumImg: 1  Img1:
/cygdrive/g/SP/2006/2006-027/hdd/2006-027-02.img
dos_load_prim: Table Sector: 0
raw_read_random: byte offset: 0 len: 512
Invalid magic value (File is not a DOS partition (invalid primary
magic) (Sector: 0))
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
$ /sleuthkit/sleuthkit/bin/mmls -v
/cygdrive/g/SP/2006/2006-027/hdd/2006-027-02.img
img_open: Type: n/a   NumImg: 1  Img1:
/cygdrive/g/SP/2006/2006-027/hdd/2006-027-02.img
Not an AFF/AFD/AFM file
Not an EWF file
dos_load_prim: Table Sector: 0
raw_read_random: byte offset: 0 len: 512
bsd_load_table: Table Sector: 1
raw_read_random: byte offset: 512 len: 512
gpt_load_table: Sector: 0
raw_read_random: byte offset: 0 len: 512
sun_load_table: Trying sector: 0
raw_read_random: byte offset: 0 len: 512
sun_load_table: Trying sector: 1
raw_read_random: byte offset: 512 len: 512
mac_load_table: Sector: 1
raw_read_random: byte offset: 512 len: 512
Cannot determine partiton type
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Third image information --
Pointsec status: disk decrypted
Host OS: Helix (Knoppix Linux) 1.8 from 10/06/2006
(http://www.e-fense.com/helix/index.php)
Hard disk read / write: software read only
Imaging Application: dd_rescue by Kurt Garloff
(http://www.garloff.de/kurt/linux/ddrescue/)
Imaging Results: ipos 39062488.5k, opos 39062488.5k, xferd 39062488.5k, errs 0
mmls says:
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
$ /sleuthkit/sleuthkit/bin/mmls -v -t dos -i raw
/cygdrive/g/SP/2006/2006-027/hdd/2006-027-03.img
img_open: Type: raw   NumImg: 1  Img1:
/cygdrive/g/SP/2006/2006-027/hdd/2006-027-03.img
dos_load_prim: Table Sector: 0
raw_read_random: byte offset: 0 len: 512
load_pri:0:0    Start: 3896685812   Size: 3296919557  Type: 81
Starting sector 3896685812 too large for image
Invalid sector address (dos_load_prim_table: Starting sector too large
for image)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
$ /sleuthkit/sleuthkit/bin/mmls -v
/cygdrive/g/SP/2006/2006-027/hdd/2006-027-03.img
img_open: Type: n/a   NumImg: 1  Img1:
/cygdrive/g/SP/2006/2006-027/hdd/2006-027-03.img
Not an AFF/AFD/AFM file
Not an EWF file
dos_load_prim: Table Sector: 0
raw_read_random: byte offset: 0 len: 512
dos_load_prim_table: Testing FAT/NTFS conditions
bsd_load_table: Table Sector: 1
raw_read_random: byte offset: 512 len: 512
gpt_load_table: Sector: 0
raw_read_random: byte offset: 0 len: 512
sun_load_table: Trying sector: 0
raw_read_random: byte offset: 0 len: 512
sun_load_table: Trying sector: 1
raw_read_random: byte offset: 512 len: 512
mac_load_table: Sector: 1
raw_read_random: byte offset: 512 len: 512
Cannot determine partiton type
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

hexedits of the 3rd (supposedly decrypted) image turn up confusing
results, such as large sections of disk that just say 'PROTECT Sector
#{some number}' and then a bunch of dashes.

The 1st and 2nd images don't have anything that resembles legible text
(ie - 'strings' turns up only gibberish).

Since the 1st and 2nd images were created with lots of errors, I
booted the system off of a SpinRite 6.0 CD (http://grc.com) and let it
run a repair over the weekend.  It found absolutely no problems at
all.  I used the CTRL+F10 method to let SpinRite get to the decrypted
hard disk drive, but I have no idea if it really makes a difference.

Incidentally, I gave up on performing a true forensic analysis since
my time is running out.

The OS running on the laptop is Windows XP with SP1 and it boots up
just fine with no errors at all.

Any expertise would be appreciated in this area.

If there are requests for me to perform some additional tasks, let me know.

Corp Sec is willing to let me keep the system to figure this out as
long as I give them copies of what they are looking for.

Thanks!

-Jason

[sleuthkit-users] Help: Bug in icat?

[Mark W. J. <mar...@cc...>]

First off, this is my first time postin	g to this list.  So, if this 
isn't the right place to request some help, then please let me know, and 
I'll happily take my request elsewhere.  I don't want to offend.

I've been using TSK and Autopsy for about 2 years now.  It's been a 
great toolset.  Kudos to everyone involved!

Today, I ran into my first big problem:  When running the File Type
Sort in Autopsy, I get errors and an incomplete result set.  In my
output directory, it finds some of the images / graphics I'm looking
for, and some that were on the disk and deleted, but not all of them.
For example, when I mount the disk image via loopback, I can find
JPG's (just using "find") that the File Type Sort doesn't.

Here are some of the details:

I'm running autopsy 2.08 and Sleuthkit 2.06.

I ran "sorter" manually like this:
/sorter -h -m 'C:/' -d /var/opt/data/tmp/ -o 0 -i raw -f ntfs -C \
~/forensics/sleuthkit-2.06/share/sorter/images.sort -s -U \
/var/opt/data/evidence/yyyymmdd-xxyy/pyy-xxxx/images/sda1

Here is the output from that command:

Analyzing  "/var/opt/data/evidence/20061006-0201/p06-2165/images/sda1"
  Loading Allocated File Listing
  Processing 2054 Allocated Files and Directories
  Invalid argument (fs_data_lookup: Null head pointer) ( -
proc_attrseq: put run)
Invalid argument (fs_data_lookup: Null head pointer) ( - proc_attrseq: 
put run)
100%

  Loading Unallocated File Listing
  Processing 2488 Unallocated meta-data structures
  *** glibc detected ***
/home/markj/forensics/sleuthkit-2.06//bin/icat: double free or
corruption (!prev): 0x09d216d8 ***
======= Backtrace: =========
/lib/libc.so.6[0x267a68]
/lib/libc.so.6(__libc_free+0x78)[0x26af6f]
/home/markj/forensics/sleuthkit-2.06//bin/icat[0x806c343]
/home/markj/forensics/sleuthkit-2.06//bin/icat[0x806e95f]
/home/markj/forensics/sleuthkit-2.06//bin/icat[0x806ee1b]
/home/markj/forensics/sleuthkit-2.06//bin/icat[0x807d734]
/home/markj/forensics/sleuthkit-2.06//bin/icat[0x8049f8a]
/lib/libc.so.6(__libc_start_main+0xdc)[0x2194e4]
/home/markj/forensics/sleuthkit-2.06//bin/icat(__gxx_personality_v0+0x91)[0x8049a31]
======= Memory map: ========
00101000-0010c000 r-xp 00000000 fd:00 124961
/lib/libgcc_s-4.1.1-20060525.so.1
0010c000-0010d000 rwxp 0000a000 fd:00 124961
/lib/libgcc_s-4.1.1-20060525.so.1
001e6000-001e7000 r-xp 001e6000 00:00 0          [vdso]
001e7000-00200000 r-xp 00000000 fd:00 124930     /lib/ld-2.4.so
00200000-00201000 r-xp 00018000 fd:00 124930     /lib/ld-2.4.so
00201000-00202000 rwxp 00019000 fd:00 124930     /lib/ld-2.4.so
00204000-00331000 r-xp 00000000 fd:00 124946     /lib/libc-2.4.so
00331000-00333000 r-xp 0012d000 fd:00 124946     /lib/libc-2.4.so
00333000-00334000 rwxp 0012f000 fd:00 124946     /lib/libc-2.4.so
00334000-00337000 rwxp 00334000 00:00 0
00339000-0035c000 r-xp 00000000 fd:00 124953     /lib/libm-2.4.so
0035c000-0035d000 r-xp 00022000 fd:00 124953     /lib/libm-2.4.so
0035d000-0035e000 rwxp 00023000 fd:00 124953     /lib/libm-2.4.so
00360000-00362000 r-xp 00000000 fd:00 124957     /lib/libdl-2.4.so
00362000-00363000 r-xp 00001000 fd:00 124957     /lib/libdl-2.4.so
00363000-00364000 rwxp 00002000 fd:00 124957     /lib/libdl-2.4.so
00484000-00496000 r-xp 00000000 fd:03 1083798    /usr/lib/libz.so.1.2.3
00496000-00497000 rwxp 00011000 fd:03 1083798    /usr/lib/libz.so.1.2.3
03bdb000-03cbd000 r-xp 00000000 fd:03 1083860    /usr/lib/libstdc++.so.6.0.8
03cbd000-03cc1000 r-xp 000e1000 fd:03 1083860    /usr/lib/libstdc++.so.6.0.8
03cc1000-03cc2000 rwxp 000e5000 fd:03 1083860    /usr/lib/libstdc++.so.6.0.8
03cc2000-03cc8000 rwxp 03cc2000 00:00 0
03cca000-03de9000 r-xp 00000000 fd:00 124969     /lib/libcrypto.so.0.9.8a
03de9000-03dfc000 rwxp 0011e000 fd:00 124969     /lib/libcrypto.so.0.9.8a
03dfc000-03dff000 rwxp 03dfc000 00:00 0
08048000-080a4000 r-xp 00000000 fd:01 230521
/home/markj/forensics/sleuthkit-2.06/bin/icat
080a4000-080a5000 rw-p 0005c000 fd:01 230521
/home/markj/forensics/sleuthkit-2.06/bin/icat
080a5000-080a6000 rw-p 080a5000 00:00 0
09c9c000-09d52000 rw-p 09c9c000 00:00 0          [heap]
b7b00000-b7b21000 rw-p b7b00000 00:00 0
b7b21000-b7c00000 ---p b7b21000 00:00 0
b7cf3000-b7cf4000 rw-p b7cf3000 00:00 0
b7cf4000-b7ef4000 r--p 00000000 fd:03 1085707 /usr/lib/locale/locale-archive
b7ef4000-b7ef6000 rw-p b7ef4000 00:00 0
b7f0a000-b7f0b000 rw-p b7f0a000 00:00 0
bfca1000-bfcb7000 rw-p bfca1000 00:00 0          [stack]
sh: line 1: 27188 Aborted                 (core dumped)
"/home/markj/forensics/sleuthkit-2.06//bin/icat" -i raw -o 0 -f ntfs
-R "/var/opt/data/evidence/20061006-0201/p06-2165/images/sda1" "34539"
 > "/var/opt/data/tmp//.sorter-sda1-22198-34539"
*** glibc detected *** /home/markj/forensics/sleuthkit-2.06//bin/icat:
free(): invalid next size (normal): 0x090166d8 ***
======= Backtrace: =========
/lib/libc.so.6[0x267a68]
/lib/libc.so.6(__libc_free+0x78)[0x26af6f]
/home/markj/forensics/sleuthkit-2.06//bin/icat[0x806c343]
/home/markj/forensics/sleuthkit-2.06//bin/icat[0x806e95f]
/home/markj/forensics/sleuthkit-2.06//bin/icat[0x806ee1b]
/home/markj/forensics/sleuthkit-2.06//bin/icat[0x807d734]
/home/markj/forensics/sleuthkit-2.06//bin/icat[0x8049f8a]
/lib/libc.so.6(__libc_start_main+0xdc)[0x2194e4]
/home/markj/forensics/sleuthkit-2.06//bin/icat(__gxx_personality_v0+0x91)[0x8049a31]
======= Memory map: ========
00101000-0010c000 r-xp 00000000 fd:00 124961
/lib/libgcc_s-4.1.1-20060525.so.1
0010c000-0010d000 rwxp 0000a000 fd:00 124961
/lib/libgcc_s-4.1.1-20060525.so.1
001e6000-001e7000 r-xp 001e6000 00:00 0          [vdso]
001e7000-00200000 r-xp 00000000 fd:00 124930     /lib/ld-2.4.so
00200000-00201000 r-xp 00018000 fd:00 124930     /lib/ld-2.4.so
00201000-00202000 rwxp 00019000 fd:00 124930     /lib/ld-2.4.so
00204000-00331000 r-xp 00000000 fd:00 124946     /lib/libc-2.4.so
00331000-00333000 r-xp 0012d000 fd:00 124946     /lib/libc-2.4.so
00333000-00334000 rwxp 0012f000 fd:00 124946     /lib/libc-2.4.so
00334000-00337000 rwxp 00334000 00:00 0
00339000-0035c000 r-xp 00000000 fd:00 124953     /lib/libm-2.4.so
0035c000-0035d000 r-xp 00022000 fd:00 124953     /lib/libm-2.4.so
0035d000-0035e000 rwxp 00023000 fd:00 124953     /lib/libm-2.4.so
00360000-00362000 r-xp 00000000 fd:00 124957     /lib/libdl-2.4.so
00362000-00363000 r-xp 00001000 fd:00 124957     /lib/libdl-2.4.so
00363000-00364000 rwxp 00002000 fd:00 124957     /lib/libdl-2.4.so
00484000-00496000 r-xp 00000000 fd:03 1083798    /usr/lib/libz.so.1.2.3
00496000-00497000 rwxp 00011000 fd:03 1083798    /usr/lib/libz.so.1.2.3
03bdb000-03cbd000 r-xp 00000000 fd:03 1083860    /usr/lib/libstdc++.so.6.0.8
03cbd000-03cc1000 r-xp 000e1000 fd:03 1083860    /usr/lib/libstdc++.so.6.0.8
03cc1000-03cc2000 rwxp 000e5000 fd:03 1083860    /usr/lib/libstdc++.so.6.0.8
03cc2000-03cc8000 rwxp 03cc2000 00:00 0
03cca000-03de9000 r-xp 00000000 fd:00 124969     /lib/libcrypto.so.0.9.8a
03de9000-03dfc000 rwxp 0011e000 fd:00 124969     /lib/libcrypto.so.0.9.8a
03dfc000-03dff000 rwxp 03dfc000 00:00 0
08048000-080a4000 r-xp 00000000 fd:01 230521
/home/markj/forensics/sleuthkit-2.06/bin/icat
080a4000-080a5000 rw-p 0005c000 fd:01 230521
/home/markj/forensics/sleuthkit-2.06/bin/icat
080a5000-080a6000 rw-p 080a5000 00:00 0
08f91000-09047000 rw-p 08f91000 00:00 0          [heap]
b7b00000-b7b21000 rw-p b7b00000 00:00 0
b7b21000-b7c00000 ---p b7b21000 00:00 0
b7cfe000-b7cff000 rw-p b7cfe000 00:00 0
b7cff000-b7eff000 r--p 00000000 fd:03 1085707 /usr/lib/locale/locale-archive
b7eff000-b7f01000 rw-p b7eff000 00:00 0
b7f15000-b7f16000 rw-p b7f15000 00:00 0
bfd75000-bfd8a000 rw-p bfd75000 00:00 0          [stack]
sh: line 1: 27362 Aborted                 (core dumped)
"/home/markj/forensics/sleuthkit-2.06//bin/icat" -i raw -o 0 -f ntfs
-R "/var/opt/data/evidence/20061006-0201/p06-2165/images/sda1" "34786"
 > "/var/opt/data/tmp//.sorter-sda1-22198-34786"
100%

All files have been saved to: /var/opt/data/tmp/

This is basically the same output that I get when I run the command
("sorter") from inside Autopsy rather than from the command line.

I have two core files that were generated by this.  I'm happy to send
them to someone if that would help.  I'm not all that great with a
debugger, but here's what gdb had to say:

[markj@forwkstn1 autopsy-2.08]$ gdb ../sleuthkit-2.06/bin/icat core.1983
GNU gdb Red Hat Linux (6.3.0.0-1.134.fc5rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host
libthread_db library "/lib/libthread_db.so.1".

Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0x1e6000
Core was generated by `/home/markj/forensics/sleuthkit-2.06//bin/icat
-i raw -o 0 -f ntfs -R /var/opt/'.
Program terminated with signal 6, Aborted.

warning: svr4_current_sos: Can't read pathname for load map: 
Input/output error

Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libcrypto.so.6...done.
Loaded symbols for /lib/libcrypto.so.6
Reading symbols from /usr/lib/libstdc++.so.6...done.
Loaded symbols for /usr/lib/libstdc++.so.6
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0  0x001e6402 in __kernel_vsyscall ()
(gdb) where
#0  0x001e6402 in __kernel_vsyscall ()
#1  0x0022bee9 in raise () from /lib/libc.so.6
#2  0x0022d4f1 in abort () from /lib/libc.so.6
#3  0x0026053b in __libc_message () from /lib/libc.so.6
#4  0x00267a68 in _int_free () from /lib/libc.so.6
#5  0x0026af6f in free () from /lib/libc.so.6
#6  0x0806c343 in ntfs_uncompress_done (comp=0xbfb430a4) at ntfs.c:754
#7  0x0806e95f in ntfs_data_walk (ntfs=0x859e048, inum=34539,
    fs_data=0x85a26f0, flags=36, action=0x807d761 <icat_action>, ptr=0x0)
    at ntfs.c:1432
#8  0x0806ee1b in ntfs_file_walk (fs=0x859e048, fs_inode=0x85a0570, 
type=128,
    id=0, flags=Variable "flags" is not available.
) at ntfs.c:3039
#9  0x0807d734 in fs_icat (fs=0x859e048, lclflags=0 '\0', inum=34539, 
type=0,
    id=0, flags=36) at icat_lib.c:71
#10 0x08049f8a in main (argc=10, argv=Cannot access memory at address 0x7c3
) at icat.c:173
(gdb)

This is all on an up to date Fedora Core 5 box.

I'd be grateful if someone could provide some guidance on where to go 
from here.

Thanks,

Mark W. Jeanmougin

[sleuthkit-users] Fwd: Help: Bug in icat?

[Mark W. J. <ma...@gm...>]

First off, this is my first time posting to this list.  So, if this
isn't the right place to request some help, then please let me know,
and I'll happily take my request elsewhere.  I don't want to offend.

I've been using TSK and Autopsy for about 2 years now.  It's been a
great toolset.  Kudos to everyone involved!

Today, I ran into my first big problem:  When running the File Type
Sort in Autopsy, I get errors and an incomplete result set.  In my
output directory, it finds some of the images / graphics I'm looking
for, and some that were on the disk and deleted, but not all of them.
For example, when I mount the disk image via loopback, I can find
.JPG's (just using "find") that the File Type Sort doesn't.

Here are some of the details:

I'm running autopsy 2.08 and Sleuthkit 2.06.

I ran "sorter" manually like this:
./sorter -h -m 'C:/' -d /var/opt/data/tmp/ -o 0 -i raw -f ntfs -C \
~/forensics/sleuthkit-2.06/share/sorter/images.sort -s -U \
/var/opt/data/evidence/yyyymmdd-xxyy/pyy-xxxx/images/sda1

Here is the output from that command:

Analyzing  "/var/opt/data/evidence/20061006-0201/p06-2165/images/sda1"
  Loading Allocated File Listing
  Processing 2054 Allocated Files and Directories
  Invalid argument (fs_data_lookup: Null head pointer) ( -
proc_attrseq: put run)
Invalid argument (fs_data_lookup: Null head pointer) ( - proc_attrseq: put run)
100%

  Loading Unallocated File Listing
  Processing 2488 Unallocated meta-data structures
  *** glibc detected ***
/home/markj/forensics/sleuthkit-2.06//bin/icat: double free or
corruption (!prev): 0x09d216d8 ***
======= Backtrace: =========
/lib/libc.so.6[0x267a68]
/lib/libc.so.6(__libc_free+0x78)[0x26af6f]
/home/markj/forensics/sleuthkit-2.06//bin/icat[0x806c343]
/home/markj/forensics/sleuthkit-2.06//bin/icat[0x806e95f]
/home/markj/forensics/sleuthkit-2.06//bin/icat[0x806ee1b]
/home/markj/forensics/sleuthkit-2.06//bin/icat[0x807d734]
/home/markj/forensics/sleuthkit-2.06//bin/icat[0x8049f8a]
/lib/libc.so.6(__libc_start_main+0xdc)[0x2194e4]
/home/markj/forensics/sleuthkit-2.06//bin/icat(__gxx_personality_v0+0x91)[0x8049a31]
======= Memory map: ========
00101000-0010c000 r-xp 00000000 fd:00 124961
/lib/libgcc_s-4.1.1-20060525.so.1
0010c000-0010d000 rwxp 0000a000 fd:00 124961
/lib/libgcc_s-4.1.1-20060525.so.1
001e6000-001e7000 r-xp 001e6000 00:00 0          [vdso]
001e7000-00200000 r-xp 00000000 fd:00 124930     /lib/ld-2.4.so
00200000-00201000 r-xp 00018000 fd:00 124930     /lib/ld-2.4.so
00201000-00202000 rwxp 00019000 fd:00 124930     /lib/ld-2.4.so
00204000-00331000 r-xp 00000000 fd:00 124946     /lib/libc-2.4.so
00331000-00333000 r-xp 0012d000 fd:00 124946     /lib/libc-2.4.so
00333000-00334000 rwxp 0012f000 fd:00 124946     /lib/libc-2.4.so
00334000-00337000 rwxp 00334000 00:00 0
00339000-0035c000 r-xp 00000000 fd:00 124953     /lib/libm-2.4.so
0035c000-0035d000 r-xp 00022000 fd:00 124953     /lib/libm-2.4.so
0035d000-0035e000 rwxp 00023000 fd:00 124953     /lib/libm-2.4.so
00360000-00362000 r-xp 00000000 fd:00 124957     /lib/libdl-2.4.so
00362000-00363000 r-xp 00001000 fd:00 124957     /lib/libdl-2.4.so
00363000-00364000 rwxp 00002000 fd:00 124957     /lib/libdl-2.4.so
00484000-00496000 r-xp 00000000 fd:03 1083798    /usr/lib/libz.so.1.2.3
00496000-00497000 rwxp 00011000 fd:03 1083798    /usr/lib/libz.so.1.2.3
03bdb000-03cbd000 r-xp 00000000 fd:03 1083860    /usr/lib/libstdc++.so.6.0.8
03cbd000-03cc1000 r-xp 000e1000 fd:03 1083860    /usr/lib/libstdc++.so.6.0.8
03cc1000-03cc2000 rwxp 000e5000 fd:03 1083860    /usr/lib/libstdc++.so.6.0.8
03cc2000-03cc8000 rwxp 03cc2000 00:00 0
03cca000-03de9000 r-xp 00000000 fd:00 124969     /lib/libcrypto.so.0.9.8a
03de9000-03dfc000 rwxp 0011e000 fd:00 124969     /lib/libcrypto.so.0.9.8a
03dfc000-03dff000 rwxp 03dfc000 00:00 0
08048000-080a4000 r-xp 00000000 fd:01 230521
/home/markj/forensics/sleuthkit-2.06/bin/icat
080a4000-080a5000 rw-p 0005c000 fd:01 230521
/home/markj/forensics/sleuthkit-2.06/bin/icat
080a5000-080a6000 rw-p 080a5000 00:00 0
09c9c000-09d52000 rw-p 09c9c000 00:00 0          [heap]
b7b00000-b7b21000 rw-p b7b00000 00:00 0
b7b21000-b7c00000 ---p b7b21000 00:00 0
b7cf3000-b7cf4000 rw-p b7cf3000 00:00 0
b7cf4000-b7ef4000 r--p 00000000 fd:03 1085707    /usr/lib/locale/locale-archive
b7ef4000-b7ef6000 rw-p b7ef4000 00:00 0
b7f0a000-b7f0b000 rw-p b7f0a000 00:00 0
bfca1000-bfcb7000 rw-p bfca1000 00:00 0          [stack]
sh: line 1: 27188 Aborted                 (core dumped)
"/home/markj/forensics/sleuthkit-2.06//bin/icat" -i raw -o 0 -f ntfs
-R "/var/opt/data/evidence/20061006-0201/p06-2165/images/sda1" "34539"
>"/var/opt/data/tmp//.sorter-sda1-22198-34539"
*** glibc detected *** /home/markj/forensics/sleuthkit-2.06//bin/icat:
free(): invalid next size (normal): 0x090166d8 ***
======= Backtrace: =========
/lib/libc.so.6[0x267a68]
/lib/libc.so.6(__libc_free+0x78)[0x26af6f]
/home/markj/forensics/sleuthkit-2.06//bin/icat[0x806c343]
/home/markj/forensics/sleuthkit-2.06//bin/icat[0x806e95f]
/home/markj/forensics/sleuthkit-2.06//bin/icat[0x806ee1b]
/home/markj/forensics/sleuthkit-2.06//bin/icat[0x807d734]
/home/markj/forensics/sleuthkit-2.06//bin/icat[0x8049f8a]
/lib/libc.so.6(__libc_start_main+0xdc)[0x2194e4]
/home/markj/forensics/sleuthkit-2.06//bin/icat(__gxx_personality_v0+0x91)[0x8049a31]
======= Memory map: ========
00101000-0010c000 r-xp 00000000 fd:00 124961
/lib/libgcc_s-4.1.1-20060525.so.1
0010c000-0010d000 rwxp 0000a000 fd:00 124961
/lib/libgcc_s-4.1.1-20060525.so.1
001e6000-001e7000 r-xp 001e6000 00:00 0          [vdso]
001e7000-00200000 r-xp 00000000 fd:00 124930     /lib/ld-2.4.so
00200000-00201000 r-xp 00018000 fd:00 124930     /lib/ld-2.4.so
00201000-00202000 rwxp 00019000 fd:00 124930     /lib/ld-2.4.so
00204000-00331000 r-xp 00000000 fd:00 124946     /lib/libc-2.4.so
00331000-00333000 r-xp 0012d000 fd:00 124946     /lib/libc-2.4.so
00333000-00334000 rwxp 0012f000 fd:00 124946     /lib/libc-2.4.so
00334000-00337000 rwxp 00334000 00:00 0
00339000-0035c000 r-xp 00000000 fd:00 124953     /lib/libm-2.4.so
0035c000-0035d000 r-xp 00022000 fd:00 124953     /lib/libm-2.4.so
0035d000-0035e000 rwxp 00023000 fd:00 124953     /lib/libm-2.4.so
00360000-00362000 r-xp 00000000 fd:00 124957     /lib/libdl-2.4.so
00362000-00363000 r-xp 00001000 fd:00 124957     /lib/libdl-2.4.so
00363000-00364000 rwxp 00002000 fd:00 124957     /lib/libdl-2.4.so
00484000-00496000 r-xp 00000000 fd:03 1083798    /usr/lib/libz.so.1.2.3
00496000-00497000 rwxp 00011000 fd:03 1083798    /usr/lib/libz.so.1.2.3
03bdb000-03cbd000 r-xp 00000000 fd:03 1083860    /usr/lib/libstdc++.so.6.0.8
03cbd000-03cc1000 r-xp 000e1000 fd:03 1083860    /usr/lib/libstdc++.so.6.0.8
03cc1000-03cc2000 rwxp 000e5000 fd:03 1083860    /usr/lib/libstdc++.so.6.0.8
03cc2000-03cc8000 rwxp 03cc2000 00:00 0
03cca000-03de9000 r-xp 00000000 fd:00 124969     /lib/libcrypto.so.0.9.8a
03de9000-03dfc000 rwxp 0011e000 fd:00 124969     /lib/libcrypto.so.0.9.8a
03dfc000-03dff000 rwxp 03dfc000 00:00 0
08048000-080a4000 r-xp 00000000 fd:01 230521
/home/markj/forensics/sleuthkit-2.06/bin/icat
080a4000-080a5000 rw-p 0005c000 fd:01 230521
/home/markj/forensics/sleuthkit-2.06/bin/icat
080a5000-080a6000 rw-p 080a5000 00:00 0
08f91000-09047000 rw-p 08f91000 00:00 0          [heap]
b7b00000-b7b21000 rw-p b7b00000 00:00 0
b7b21000-b7c00000 ---p b7b21000 00:00 0
b7cfe000-b7cff000 rw-p b7cfe000 00:00 0
b7cff000-b7eff000 r--p 00000000 fd:03 1085707    /usr/lib/locale/locale-archive
b7eff000-b7f01000 rw-p b7eff000 00:00 0
b7f15000-b7f16000 rw-p b7f15000 00:00 0
bfd75000-bfd8a000 rw-p bfd75000 00:00 0          [stack]
sh: line 1: 27362 Aborted                 (core dumped)
"/home/markj/forensics/sleuthkit-2.06//bin/icat" -i raw -o 0 -f ntfs
-R "/var/opt/data/evidence/20061006-0201/p06-2165/images/sda1" "34786"
>"/var/opt/data/tmp//.sorter-sda1-22198-34786"
100%

All files have been saved to: /var/opt/data/tmp/

This is basically the same output that I get when I run the command
("sorter") from inside Autopsy rather than from the command line.

I have two core files that were generated by this.  I'm happy to send
them to someone if that would help.  I'm not all that great with a
debugger, but here's what gdb had to say:

[markj@forwkstn1 autopsy-2.08]$ gdb ../sleuthkit-2.06/bin/icat core.1983
GNU gdb Red Hat Linux (6.3.0.0-1.134.fc5rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host
libthread_db library "/lib/libthread_db.so.1".

Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0x1e6000
Core was generated by `/home/markj/forensics/sleuthkit-2.06//bin/icat
-i raw -o 0 -f ntfs -R /var/opt/'.
Program terminated with signal 6, Aborted.

warning: svr4_current_sos: Can't read pathname for load map: Input/output error

Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libcrypto.so.6...done.
Loaded symbols for /lib/libcrypto.so.6
Reading symbols from /usr/lib/libstdc++.so.6...done.
Loaded symbols for /usr/lib/libstdc++.so.6
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0  0x001e6402 in __kernel_vsyscall ()
(gdb) where
#0  0x001e6402 in __kernel_vsyscall ()
#1  0x0022bee9 in raise () from /lib/libc.so.6
#2  0x0022d4f1 in abort () from /lib/libc.so.6
#3  0x0026053b in __libc_message () from /lib/libc.so.6
#4  0x00267a68 in _int_free () from /lib/libc.so.6
#5  0x0026af6f in free () from /lib/libc.so.6
#6  0x0806c343 in ntfs_uncompress_done (comp=0xbfb430a4) at ntfs.c:754
#7  0x0806e95f in ntfs_data_walk (ntfs=0x859e048, inum=34539,
    fs_data=0x85a26f0, flags=36, action=0x807d761 <icat_action>, ptr=0x0)
    at ntfs.c:1432
#8  0x0806ee1b in ntfs_file_walk (fs=0x859e048, fs_inode=0x85a0570, type=128,
    id=0, flags=Variable "flags" is not available.
) at ntfs.c:3039
#9  0x0807d734 in fs_icat (fs=0x859e048, lclflags=0 '\0', inum=34539, type=0,
    id=0, flags=36) at icat_lib.c:71
#10 0x08049f8a in main (argc=10, argv=Cannot access memory at address 0x7c3
) at icat.c:173
(gdb)

This is all on an up to date Fedora Core 5 box.

I'd be grateful if someone could provide some guidance on where to go from here.

Thanks,

Mark W. Jeanmougin

Re: [sleuthkit-users] Some hyperlinks to directories are missing on newer Sleuthkit/Autopsy

[Rose, J. L S. C. <Jer...@sa...>]

I'll try an NTFS image file from another system to see if this is =
something
specific to this one image.

-----Original Message-----
From: Brooks, Prentis [mailto:pre...@tw...]=20
Sent: Friday, September 29, 2006 7:58 AM
To: Rose, Jerry L SAJ Contractor; Brian Carrier
Cc: sle...@li...
Subject: RE: [sleuthkit-users] Some hyperlinks to directories are =
missingon
newer Sleuthkit/Autopsy


The only time I have seen something like this is when the file's inode =
was
reallocated as a directory, yet still there was some vestigial data left =
for
sleuthkit to see.  In this case, however, it still reflects this in the =
color
of the file name and one of the columns will indicate the reallocated =
status.
In the previous versions where it provided a link, that link would take =
me to
the new directory.  It actually made things more confusing until I =
realized
that it was effectively linking to a new existing directory and there =
wasn't
anything left of the old file, but the name.

-----Original Message-----
<< snipped >>

Re: [sleuthkit-users] Some hyperlinks to directories are missingon newer Sleuthkit/Autopsy

[Brooks, P. <pre...@tw...>]

=0D=0AThe only time I have seen something like this is when the file's inod=
e was reallocated as a directory, yet still there was some vestigial data l=
eft for sleuthkit to see=2E  In this case, however, it still reflects this =
in the color of the file name and one of the columns will indicate the real=
located status=2E  In the previous versions where it provided a link, that =
link would take me to the new directory=2E  It actually made things more co=
nfusing until I realized that it was effectively linking to a new existing =
directory and there wasn't anything left of the old file, but the name=2E=
=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: sleuthkit-users-bounces@l=
ists=2Esourceforge=2Enet on behalf of Rose, Jerry L SAJ Contractor=0D=0ASen=
t: Fri 9/29/2006 7:10 AM=0D=0ATo: Brian Carrier=0D=0ACc: sleuthkit-users@li=
sts=2Esourceforge=2Enet=0D=0ASubject: Re: [sleuthkit-users] Some hyperlinks=
 to directories are missingon	newer Sleuthkit/Autopsy=0D=0A =0D=0ANo, the d=
irectories can be opened by either using the previous version(s) or=0D=0Aby=
 using the new version and typing them into the browse field=2E For this ca=
se=0D=0Athe NTFS image is for the "C:" partition=2E When I browse I can typ=
e in to the=0D=0Aform "winnt" below the C:\ and the files show up=2E=0D=0A=
=0D=0AJerry=0D=0A=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Brian Ca=
rrier [mailto:carrier@sleuthkit=2Eorg] =0D=0ASent: Thursday, September 28, =
2006 5:36 PM=0D=0ATo: Rose, Jerry L SAJ Contractor=0D=0ACc: sleuthkit-users=
@lists=2Esourceforge=2Enet=0D=0ASubject: Re: [sleuthkit-users] Some hyperli=
nks to directories are missing on=0D=0Anewer Sleuthkit/Autopsy=0D=0A=0D=0AA=
re the directories that are different deleted? Autopsy determines if it =0D=
=0Ashould provide a link based on the letter after the slash, which is why =
=0D=0Ait isn't showing you a link=2E  The question is why a "-" is being gi=
ven=2E=2E=2E=0D=0A=0D=0Abrian=0D=0A=0D=0A=0D=0A=0D=0A=0D=0ARose, Jerry L SA=
J Contractor wrote:=0D=0A> I am using Sleuthkit version 2=2E06 and Autopsy =
version 2=2E08 on a Linux =0D=0A> x86 box=2E The image file is NTFS=2E In A=
utopsy some of the directories are =0D=0A> showing as "d/-" and there is no=
 drill down hyperlink for them=2E But, =0D=0A> when I run Sleuthkit version=
 2=2E03 and Autopsy version 2=2E06 on the same =0D=0A> system and analyze t=
he same image file the older versions show the =0D=0A> "missing" links as n=
ormal "d/d"=2E What am I doing wrong?=0D=0A> =0D=0A> =0D=0A> --------------=
----------------------------------------------------------=0D=0A> =0D=0A> -=
------------------------------------------------------------------------=0D=
=0A> Take Surveys=2E Earn Cash=2E Influence the Future of IT=0D=0A> Join So=
urceForge=2Enet's Techsay panel and you'll get the chance to share=0D=0Ayou=
r=0D=0A> opinions on IT & business topics through brief surveys -- and earn=
 cash=0D=0A> http://www=2Etechsay=2Ecom/default=2Ephp?page=3Djoin=2Ephp&p=
=3Dsourceforge&CID=3DDEVDEV=0D=0A> =0D=0A> =0D=0A> ------------------------=
------------------------------------------------=0D=0A> =0D=0A> ___________=
____________________________________=0D=0A> sleuthkit-users mailing list=0D=
=0A> https://lists=2Esourceforge=2Enet/lists/listinfo/sleuthkit-users=0D=0A=
> http://www=2Esleuthkit=2Eorg=0D=0A=0D=0A---------------------------------=
----------------------------------------=0D=0ATake Surveys=2E Earn Cash=2E =
Influence the Future of IT=0D=0AJoin SourceForge=2Enet's Techsay panel and =
you'll get the chance to share your=0D=0Aopinions on IT & business topics t=
hrough brief surveys -- and earn cash=0D=0Ahttp://www=2Etechsay=2Ecom/defau=
lt=2Ephp?page=3Djoin=2Ephp&p=3Dsourceforge&CID=3DDEVDEV=0D=0A______________=
_________________________________=0D=0Asleuthkit-users mailing list=0D=0Aht=
tps://lists=2Esourceforge=2Enet/lists/listinfo/sleuthkit-users=0D=0Ahttp://=
www=2Esleuthkit=2Eorg=0D=0A=0D=0A=0D=0A------------------------------------=
-----=0D=0AThis E-mail and any of its attachments may contain Time Warner=
=0D=0ACable proprietary information, which is privileged, confidential,=0D=
=0Aor subject to copyright belonging to Time Warner Cable=2E This E-mail=0D=
=0Ais intended solely for the use of the individual or entity to which=0D=
=0Ait is addressed=2E If you are not the intended recipient of this=0D=0AE-=
mail, you are hereby notified that any dissemination,=0D=0Adistribution, co=
pying, or action taken in relation to the contents=0D=0Aof and attachments =
to this E-mail is strictly prohibited and may be=0D=0Aunlawful=2E If you ha=
ve received this E-mail in error, please notify=0D=0Athe sender immediately=
 and permanently delete the original and any=0D=0Acopy of this E-mail and a=
ny printout=2E=0D=0A

Re: [sleuthkit-users] Some hyperlinks to directories are missing on newer Sleuthkit/Autopsy

[Rose, J. L S. C. <Jer...@sa...>]

No, the directories can be opened by either using the previous =
version(s) or
by using the new version and typing them into the browse field. For this =
case
the NTFS image is for the "C:" partition. When I browse I can type in to =
the
form "winnt" below the C:\ and the files show up.

Jerry


-----Original Message-----
From: Brian Carrier [mailto:ca...@sl...]=20
Sent: Thursday, September 28, 2006 5:36 PM
To: Rose, Jerry L SAJ Contractor
Cc: sle...@li...
Subject: Re: [sleuthkit-users] Some hyperlinks to directories are =
missing on
newer Sleuthkit/Autopsy

Are the directories that are different deleted? Autopsy determines if it =

should provide a link based on the letter after the slash, which is why=20
it isn't showing you a link.  The question is why a "-" is being =
given...

brian




Rose, Jerry L SAJ Contractor wrote:
> I am using Sleuthkit version 2.06 and Autopsy version 2.08 on a Linux=20
> x86 box. The image file is NTFS. In Autopsy some of the directories =
are=20
> showing as "d/-" and there is no drill down hyperlink for them. But,=20
> when I run Sleuthkit version 2.03 and Autopsy version 2.06 on the same =

> system and analyze the same image file the older versions show the=20
> "missing" links as normal "d/d". What am I doing wrong?
>=20
>=20
> =
------------------------------------------------------------------------
>=20
> =
-------------------------------------------------------------------------=

> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to =
share
your
> opinions on IT & business topics through brief surveys -- and earn =
cash
> =
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
>=20
>=20
> =
------------------------------------------------------------------------
>=20
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

Re: [sleuthkit-users] Some hyperlinks to directories are missing on newer Sleuthkit/Autopsy

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

Are the directories that are different deleted? Autopsy determines if it=20
should provide a link based on the letter after the slash, which is why=20
it isn't showing you a link.  The question is why a "-" is being given...

brian




Rose, Jerry L SAJ Contractor wrote:
> I am using Sleuthkit version 2.06 and Autopsy version 2.08 on a Linux=20
> x86 box. The image file is NTFS. In Autopsy some of the directories are=
=20
> showing as =93d/-=93 and there is no drill down hyperlink for them. But=
,=20
> when I run Sleuthkit version 2.03 and Autopsy version 2.06 on the same=20
> system and analyze the same image file the older versions show the=20
> =93missing=94 links as normal =93d/d=94. What am I doing wrong?
>=20
>=20
> -----------------------------------------------------------------------=
-
>=20
> -----------------------------------------------------------------------=
--
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share=
 your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
>=20
>=20
> -----------------------------------------------------------------------=
-
>=20
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

[sleuthkit-users] Some hyperlinks to directories are missing on newer Sleuthkit/Autopsy

[Rose, J. L S. C. <Jer...@sa...>]

I am using Sleuthkit version 2.06 and Autopsy version 2.08 on a Linux =
x86
box. The image file is NTFS. In Autopsy some of the directories are =
showing
as "d/-" and there is no drill down hyperlink for them. But, when I run
Sleuthkit version 2.03 and Autopsy version 2.06 on the same system and
analyze the same image file the older versions show the "missing" links =
as
normal "d/d". What am I doing wrong?

Re: [sleuthkit-users] cannot install

[<sec...@hu...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

You need to install the openssl and zlib development packages for
your platform.

I believe the requirements are enumerated in the documentation.

Regards,

Patrick

On Wed, 13 Sep 2006 20:24:26 -0400 car...@gm... wrote:
>Hey...
>
>I'm new at this and i'm trying to install sleuth kit but i get the
>next
>output: (can anyone tell me what to do?)
>
>[root@localhost sleuthkit-2.06]# pwd
>/usr/local/sleuthkit-2.06
>[root@localhost sleuthkit-2.06]# make
>make -C src/auxtools
>make[1]: Entering directory `/usr/local/sleuthkit-
>2.06/src/auxtools'
>make: Entering directory `/usr/local/sleuthkit-2.06/src/auxtools'
>ar rv ../../lib/libtsk.a mymalloc.o strerror.o split_at.o
>tsk_endian.o
>data_buf.o tsk_version.o tsk_error.o tsk_parse.o tsk_unicode.o
>tsk_printf.o
>r - mymalloc.o
>r - strerror.o
>r - split_at.o
>r - tsk_endian.o
>r - data_buf.o
>r - tsk_version.o
>r - tsk_error.o
>r - tsk_parse.o
>r - tsk_unicode.o
>r - tsk_printf.o
>ranlib ../../lib/libtsk.a
>make: Leaving directory `/usr/local/sleuthkit-2.06/src/auxtools'
>make[1]: Leaving directory `/usr/local/sleuthkit-
>2.06/src/auxtools'
>make -C src/afflib/lib AFFLIB="../../../lib/libtsk.a"
>make[1]: Entering directory `/usr/local/sleuthkit-
>2.06/src/afflib/lib'
>g++ -c -g -Wall -I/usr/local/ssl/include -I/usr/sfw/include -I. -
>Ilib   -o
>aff_db.o aff_db.cpp
>In file included from aff_db.cpp:8:
>afflib_i.h:55:18: error: zlib.h: No such file or directory
>afflib_i.h:62:26: error: openssl/rand.h: No such file or directory
>afflib_i.h:63:25: error: openssl/md5.h: No such file or directory
>make[1]: *** [aff_db.o] Error 1
>make[1]: Leaving directory `/usr/local/sleuthkit-
>2.06/src/afflib/lib'
>make: *** [no-perl] Error 2
>
>pd: I already followed the INSTALL.txt directions
>thanks in advance...
-----BEGIN PGP SIGNATURE-----
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 2.5

wkYEARECAAYFAkUJeJUACgkQRBFe1uc9INptCACeM54kuv3qeDaPGE0HmdHSC19DuKIA
oIsyWgD2RR7wbyUMqgyVWtBsHuNt
=nfxB
-----END PGP SIGNATURE-----

[sleuthkit-users] cannot install

[<car...@gm...>]

Hey...

I'm new at this and i'm trying to install sleuth kit but i get the next
output: (can anyone tell me what to do?)

[root@localhost sleuthkit-2.06]# pwd
/usr/local/sleuthkit-2.06
[root@localhost sleuthkit-2.06]# make
make -C src/auxtools
make[1]: Entering directory `/usr/local/sleuthkit-2.06/src/auxtools'
make: Entering directory `/usr/local/sleuthkit-2.06/src/auxtools'
ar rv ../../lib/libtsk.a mymalloc.o strerror.o split_at.o tsk_endian.o
data_buf.o tsk_version.o tsk_error.o tsk_parse.o tsk_unicode.o tsk_printf.o
r - mymalloc.o
r - strerror.o
r - split_at.o
r - tsk_endian.o
r - data_buf.o
r - tsk_version.o
r - tsk_error.o
r - tsk_parse.o
r - tsk_unicode.o
r - tsk_printf.o
ranlib ../../lib/libtsk.a
make: Leaving directory `/usr/local/sleuthkit-2.06/src/auxtools'
make[1]: Leaving directory `/usr/local/sleuthkit-2.06/src/auxtools'
make -C src/afflib/lib AFFLIB="../../../lib/libtsk.a"
make[1]: Entering directory `/usr/local/sleuthkit-2.06/src/afflib/lib'
g++ -c -g -Wall -I/usr/local/ssl/include -I/usr/sfw/include -I. -Ilib   -o
aff_db.o aff_db.cpp
In file included from aff_db.cpp:8:
afflib_i.h:55:18: error: zlib.h: No such file or directory
afflib_i.h:62:26: error: openssl/rand.h: No such file or directory
afflib_i.h:63:25: error: openssl/md5.h: No such file or directory
make[1]: *** [aff_db.o] Error 1
make[1]: Leaving directory `/usr/local/sleuthkit-2.06/src/afflib/lib'
make: *** [no-perl] Error 2

pd: I already followed the INSTALL.txt directions
thanks in advance...

[sleuthkit-users] New Windows Executables Release

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

The Windows executables that were released last week did not run on  
everyones systems.  A second release is out that uses different  
compile options.

http://www.sleuthkit.org/sleuthkit/download.php

brian

[sleuthkit-users] TSK 2.06 and Autopsy 2.08 released

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

New versions are up.

http://www.sleuthkit.org/

Major improvements for TSK are fixes for segfaults that were discussed 
on the mailing list, new versions of libewf and afflib that add support 
for the SMART format and that fix some compile bugs (respectively), and 
... a first pass at a Windows version.

The Windows port is not 100% complete.  Support for EWF and AFF do not 
exist and "globbing" is not supported on the command line. But, it's a 
start. There is a zip file with the executables on the website.  Autopsy 
will not work on Windows though (outside of Cygwin).

The new Autopsy version includes the update that will check if it is 
running on Cygwin and will then set the path to 
'/bin;/usr/bin;/usr/local/bin' (so that the dlls can be found).

brian