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

[sleuthkit-users] Novice question String Search

[Charlie F. <fr...@ma...>]

Hello, I am performing an investigation and am preparing a report. In 
the images.srch file which is created from a keyword search. What is the 
significance of the second value? For example

Cluster    2nd value     text match found
771098 | 1866              stringresult

This is from a WIndows XP system. Is the second value the INODE?

Thanks

Charlie

[sleuthkit-users] RE: Lame Q?? - Officially stupid

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

OK, I am DUMB...  Got the gcc and make stuff for SUSE
and all is well.... sorry for the random acts of
stupidity...

Thanks to all,
Rich

[sleuthkit-users] Lame install question

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

OK, Lamo question.  I have installed Sleuthkit and
Autopsy on a RH9 machine before ( a couple of
versions) with no problems.  I am now installing the
new releases on a Suse 9 machine and after extracting
the archives, when I run make I ge the error:

bash: make: command not found

WTF did I do????  Any ehlp would be appreciated.

Thanks in advacne,
Rich

[sleuthkit-users] Re: sleuthkit-users digest, Vol 1 #202 - 1 msg

[Devi0s M. <de...@gm...>]

Just FYI: The Maxtor OneTouch external drives are pre-formatted as a
250GB FAT32 partition, and include a bootable cd with software that
allows you to quick-format any large disk with a FAT32.

- Dev


On Mon, 13 Sep 2004 20:52:11 -0700,
sle...@li...
<sle...@li...> wrote:
> Send sleuthkit-users mailing list submissions to
>         sle...@li...
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> or, via email, send a message with subject or body 'help' to
>         sle...@li...
> 
> You can reach the person managing the list at
>         sle...@li...
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of sleuthkit-users digest..."
> 
> Today's Topics:
> 
>    1. Re: Autopsy - FAT32 images problem ? (Angus Marshall)
> 
> --__--__--
> 
> Message: 1
> From: Angus Marshall <an...@n-...>
> Organization: Dis-
> To: Brian Carrier <ca...@sl...>
> Subject: Re: [sleuthkit-users] Autopsy - FAT32 images problem ?
> Date: Mon, 13 Sep 2004 19:55:12 +0100
> Cc: "sleuthkit-users <sle...@li...>" <sle...@li...>
> 
> On Monday 13 September 2004 03:09, Brian Carrier wrote:
> > On Sep 12, 2004, at 10:46 AM, Angus Marshall wrote:
> > > I have a 160Gb partition formatted as FAT32 which has been imaged
> > > using dd.
> > >
> > > I can mount it ro on a loop device on Linux and confirm that is it
> > > FAT32, but
> > > when I try to symlink the image into the case on Autopsy 2.03 it's
> > > reporting
> > > that the images is not FAT32. The autopsy shell window reports :
> > >
> > > "bin/fsstat: FAT Volume too large for analysis"
> > >
> > > so I guess there's a hard limit set somewhere in sleuthkit. Can this be
> > > overcome ?
> >
> > Not until version 2 when I start to use the fixed size variables.  This
> > limit is because FAT directory entries do not have any form of address
> > and therefore I assign them one based on the sector they are located in
> > and their location in the sector.  To keep in a 32-bit inode address,
> > there can only be 2^28 sectors, which is a 128 GB file system.  I had
> > assumed that few people would be using FAT for such a large file
> > system.  In version 2, the internal inode address will be 64-bits and
> > will be able to assign larger addresses.
> >
> > Sorry.  If you want to do keyword searching you can import it as a raw
> > image.
> >
> > brian
> 
> Thanks Brian - it's the first large disk I've encountered where the suspect
> has used FAT32 instead of NTFS. I reckon I can handle it using the loopback
> mount instead. It's only a CD-piracy case, so the evidence is likely to be
> fairly obvious anyway.
> 
> --__--__--
> 
> _______________________________________________
> sleuthkit-users mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> 
> End of sleuthkit-users Digest
>

Re: [sleuthkit-users] Getting cluster from off-set

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

On Sep 16, 2004, at 3:18 PM, Horner, Jonathan J (JH8) wrote:

> I know this is probably painfully easy, but I'm crunched for time and
> without ability to form a coherent thought.
>
> Can someone remind me how to get a cluster number when I've got the 
> offset
> of string returned by 'strings --radix=d'?

Divide the byte offset by the cluster size.  You can get the cluster 
size from running 'fsstat' on the image, or using the Image Details 
view in autopsy.  The remainder from dividing is the byte offset into 
the cluster.

brian

[sleuthkit-users] Getting cluster from off-set

[Horner, J. J (JH8) <ho...@y1...>]

I know this is probably painfully easy, but I'm crunched for time and
without ability to form a coherent thought.

Can someone remind me how to get a cluster number when I've got the offset
of string returned by 'strings --radix=d'?


Thanks,

J. J. Horner
NCI Information Systems, Inc
Cyber Security Organization
Y-12 National Security Complex
(865) 576-0585

"Yeah, we had some issues. But make no mistake about it. If you attack us,
we are still capable of kicking your a--," - Jean "John" Burleson, 

Re: [sleuthkit-users] Autopsy - FAT32 images problem ?

[Angus M. <an...@n-...>]

On Monday 13 September 2004 03:09, Brian Carrier wrote:
> On Sep 12, 2004, at 10:46 AM, Angus Marshall wrote:
> > I have a 160Gb partition formatted as FAT32 which has been imaged
> > using dd.
> >
> > I can mount it ro on a loop device on Linux and confirm that is it
> > FAT32, but
> > when I try to symlink the image into the case on Autopsy 2.03 it's
> > reporting
> > that the images is not FAT32. The autopsy shell window reports :
> >
> > "bin/fsstat: FAT Volume too large for analysis"
> >
> > so I guess there's a hard limit set somewhere in sleuthkit. Can this be
> > overcome ?
>
> Not until version 2 when I start to use the fixed size variables.  This
> limit is because FAT directory entries do not have any form of address
> and therefore I assign them one based on the sector they are located in
> and their location in the sector.  To keep in a 32-bit inode address,
> there can only be 2^28 sectors, which is a 128 GB file system.  I had
> assumed that few people would be using FAT for such a large file
> system.  In version 2, the internal inode address will be 64-bits and
> will be able to assign larger addresses.
>
> Sorry.  If you want to do keyword searching you can import it as a raw
> image.
>
> brian

Thanks Brian - it's the first large disk I've encountered where the suspect 
has used FAT32 instead of NTFS. I reckon I can handle it using the loopback 
mount instead. It's only a CD-piracy case, so the evidence is likely to be 
fairly obvious anyway.

Re: [sleuthkit-users] Autopsy - FAT32 images problem ?

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

On Sep 12, 2004, at 10:46 AM, Angus Marshall wrote:

> I have a 160Gb partition formatted as FAT32 which has been imaged 
> using dd.
>
> I can mount it ro on a loop device on Linux and confirm that is it 
> FAT32, but
> when I try to symlink the image into the case on Autopsy 2.03 it's 
> reporting
> that the images is not FAT32. The autopsy shell window reports :
>
> "bin/fsstat: FAT Volume too large for analysis"
>
> so I guess there's a hard limit set somewhere in sleuthkit. Can this be
> overcome ?

Not until version 2 when I start to use the fixed size variables.  This 
limit is because FAT directory entries do not have any form of address 
and therefore I assign them one based on the sector they are located in 
and their location in the sector.  To keep in a 32-bit inode address, 
there can only be 2^28 sectors, which is a 128 GB file system.  I had 
assumed that few people would be using FAT for such a large file 
system.  In version 2, the internal inode address will be 64-bits and 
will be able to assign larger addresses.

Sorry.  If you want to do keyword searching you can import it as a raw 
image.

brian

[sleuthkit-users] Autopsy - FAT32 images problem ?

[Angus M. <an...@n-...>]

I have a 160Gb partition formatted as FAT32 which has been imaged using dd.

I can mount it ro on a loop device on Linux and confirm that is it FAT32, but 
when I try to symlink the image into the case on Autopsy 2.03 it's reporting 
that the images is not FAT32. The autopsy shell window reports : 

"bin/fsstat: FAT Volume too large for analysis"

so I guess there's a hard limit set somewhere in sleuthkit. Can this be 
overcome ?

Angus Marshall

[sleuthkit-users] NTFS compressed files

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

I have gotten several e-mails recently about NTFS compressed files and 
wanted to make everyone aware of it.

NTFS supports file system-level compression.  Version 1.71 of TSK 
started to recognize compressed files, but TSK does not yet uncompress 
them.  Therefore, instead of having 'icat' output compressed junk I 
have made it generate an error to the effect of "TSK does not support 
NTFS compressed files".

So, if you see that message than that is what happened.  You can try 
Linux loopback or other tools to see if they can uncompress the file.  
The first block of a compressed file typically has some ASCII or 
Unicode strings that you can read, so you can try and view that for a 
few basic clues.

brian

[sleuthkit-users] TSK 1.72 / Autopsy 2.03 Release

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

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

New versions are available.

TSK fixes the FAT error message about a recursive directory and a 
couple of NTFS errors.  All users should upgrade.   TSK also includes 
new EXTxFS features such as extended attributes and POSIX ACL 
information in istat.  ALSO, there is a new tool called sstrings, which 
is basically just the strings program from GNU binutils.  This means 
that all OSes have a strings that can handle  Unicode and it works on 
large files (which some Linux distros currently don't).  A new version 
of 'file' is also included that appears to fix the Cygwin issue.

http://www.sleuthkit.org/sleuthkit/
MD5 Value: 152fda4cc80696a9f6be9d7ce619ef31

Autopsy now allows Unicode searching, has some documentation updates, 
and includes other minor updates.

http://www.sleuthkit.org/autopsy/
MD5 Value: 51b056624cc81ca1bdf281e2e23a160d

brian


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFBPkd7OK1gLsdFTIsRAhflAJ434NpyzG+hLoFBa15Zfyvz6aAUngCeKmmU
HURpo6vWF0DEVFDdfxEox4k=
=v2wH
-----END PGP SIGNATURE-----

Re: [sleuthkit-users] fls Error

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

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


On Aug 28, 2004, at 7:47 AM, Patrick Roussel wrote:

>  On a Red Hat Fedora system, when running a recursive fls command on a 
> 3.2 Gb FAT32 image, i receive the following message:
>
>  /usr/local/src/sleuthkit-1.71/bin/fls: fatfs_dent_walk g_curdirptr is 
> set ! recursive ?
>

That is a known bug that was recently introduced.  The problem is that 
it was trying to analyze a deleted directory and it wasn't cleaning up 
after itself when it had to abort because of corrupt data.  Download 
the fatfs_dent.c file from the link below, replace the one in 
src/fstools with it and recompile.

http://www.sleuthkit.org/sleuthkit/fatfs_dent.c

brian

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFBMKN2OK1gLsdFTIsRAgtoAKCAgKttbwWGgCKBKszSAYNr7iBSowCfba25
7c3m0GcptfFP9KMDLcVZVYE=
=1beG
-----END PGP SIGNATURE-----

[sleuthkit-users] fls Error

[Patrick R. <ro...@ju...>]

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.729 / Virus Database: 484 - Release Date: 27/07/2004

[sleuthkit-users] "Invalid MFT File Reference" Error

[Kucenski, M. A. <Mat...@di...>]

I was originally getting a core dump when trying to run fls on a NTFS
partition.  Then I tried running ils on the same partition and received this
error:

Invalid MFT file reference (1933667429) in the attribute list of MFT 54940.

I then tried to run istat on 54940 and received the same error.  Is this a
bug in Sleuthkit or is there an error in my partition?  If it is an error in
the partition, is there anything that can be done besides copying the
partition to a disk and letting windows repair it?

Thanks,
-Matt

Matt Kucenski
U.S. Department of Defense
Voice: (202) 231-1847

Re: [sleuthkit-users] Imaging a formatted CDRW for direct drives

[Enda C. <en...@co...>]

Presumably the imaging process is not completing, or at least not doing so
cleanly. If you are using dd try adding the conv=noerror option. Check man
dd for details.

HTH,

 -Enda.

----- Original Message -----
From: <sec...@hu...>
To: <sle...@li...>
Sent: Wednesday, August 11, 2004 3:57 AM
Subject: [sleuthkit-users] Imaging a formatted CDRW for direct drives


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Here's a problem...
>
> I have some CDRW's that were used/formatted for direct drives on Windows.
> The software to read/write was either Adaptec Direct CD Wizard 3.01X
> or Roxio. You probably get the picture.
>
> I need to image them to find what data was on them before.
>
> I am resigned to the fact that due to possible corruption (a fact I have
> not proven yet) that I might end up looking at the image in a hexeditor.
>
> Here's the problem...
>
> Two discs have now been subsequently formatted as a ISO-9660 CDR data
> disk (the discs are all Imation CD-RW discs). One of them only has a
> 14 MB image now except I know there was more data there on previous
formattings.
>
> Attempting to image the disk with dd on linux fails to grab anything
> other than the current 14 MB ISO-9660 image.
>
> [1.] Is there a way with dd to image any other data on the disk(s)?
>
> Secondly, some of the discs now appear unformatted although they had
> previously been used as CDRW/CDR discs.
>
> [2.] Is there a way to image these discs to extract any data that once
> resided on them?
>
> Please tell me my only option is *NOT* an electron microscope.
>
> Thanks list.
> -----BEGIN PGP SIGNATURE-----
> Note: This signature can be verified at https://www.hushtools.com/verify
> Version: Hush 2.4
>
> wkYEARECAAYFAkEZitYACgkQRBFe1uc9INre3QCgtpuB0/j00izcTCjwCCsii4H4hZsA
> oLnxCd8UIF+KWwgFQQZm10Jhvm07
> =7wVO
> -----END PGP SIGNATURE-----
>
>
>
>
> Concerned about your privacy? Follow this link to get
> secure FREE email: http://www.hushmail.com/?l=2
>
> Free, ultra-private instant messaging with Hush Messenger
> http://www.hushmail.com/services-messenger?l=434
>
> Promote security and make money with the Hushmail Affiliate Program:
> http://www.hushmail.com/about-affiliate?l=427
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>

[sleuthkit-users] Imaging a formatted CDRW for direct drives

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

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

Here's a problem...

I have some CDRW's that were used/formatted for direct drives on Windows.
The software to read/write was either Adaptec Direct CD Wizard 3.01X
or Roxio. You probably get the picture.

I need to image them to find what data was on them before.

I am resigned to the fact that due to possible corruption (a fact I have
not proven yet) that I might end up looking at the image in a hexeditor.

Here's the problem...

Two discs have now been subsequently formatted as a ISO-9660 CDR data
disk (the discs are all Imation CD-RW discs). One of them only has a
14 MB image now except I know there was more data there on previous formattings.

Attempting to image the disk with dd on linux fails to grab anything
other than the current 14 MB ISO-9660 image.

[1.] Is there a way with dd to image any other data on the disk(s)?

Secondly, some of the discs now appear unformatted although they had
previously been used as CDRW/CDR discs.

[2.] Is there a way to image these discs to extract any data that once
resided on them?

Please tell me my only option is *NOT* an electron microscope.

Thanks list.
-----BEGIN PGP SIGNATURE-----
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 2.4

wkYEARECAAYFAkEZitYACgkQRBFe1uc9INre3QCgtpuB0/j00izcTCjwCCsii4H4hZsA
oLnxCd8UIF+KWwgFQQZm10Jhvm07
=7wVO
-----END PGP SIGNATURE-----




Concerned about your privacy? Follow this link to get
secure FREE email: http://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
http://www.hushmail.com/services-messenger?l=434

Promote security and make money with the Hushmail Affiliate Program: 
http://www.hushmail.com/about-affiliate?l=427

Re: [sleuthkit-users] Using Autopsy with a mount point rather than an image

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

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

If the hard drive in question had multiple partitions, then yes. In this
case it was a basic Windows install. I use a hard disk enclosure that
I can insert a hard drive into and mount/image/etc.

So it was as simple as 'mount -t fat /dev/hdc /mnt/image'.

It would no doubt been different if there were multiple partitions on
the HD.


On Tue, 10 Aug 2004 11:37:06 -0700 Angus Marshall <an...@n-...>
wrote:
>On Tuesday 10 August 2004 18:36, sec...@hu... wrote:
>> Thanks to all. I will follow the unanimous advice of the list
>to point
>> Autopsy to the physical device (in this case /dev/hdd).
>
>Not wishing to appear picky - but shouldn't this be the PARTITION
>on the
>device ? (e.g. /dev/hdd1 ) Unless Autopsy & Sleuthkit have changed
>a lot
>since I last used them (last night) ;-)
>
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank
>Media
>100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
>Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
>http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
>_______________________________________________
>sleuthkit-users mailing list
>https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>http://www.sleuthkit.org
-----BEGIN PGP SIGNATURE-----
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 2.4

wkYEARECAAYFAkEZiKcACgkQRBFe1uc9INr/0gCcCIDMZS2un+zZ0ilyMvi2z4le/j8A
n1Um8H/ns0Gz0q77hcRKOOKx6W/O
=nRS5
-----END PGP SIGNATURE-----




Concerned about your privacy? Follow this link to get
secure FREE email: http://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
http://www.hushmail.com/services-messenger?l=434

Promote security and make money with the Hushmail Affiliate Program: 
http://www.hushmail.com/about-affiliate?l=427

Re: [sleuthkit-users] Using Autopsy with a mount point rather than an image

[Angus M. <an...@n-...>]

On Tuesday 10 August 2004 18:36, sec...@hu... wrote:
> Thanks to all. I will follow the unanimous advice of the list to point
> Autopsy to the physical device (in this case /dev/hdd).

Not wishing to appear picky - but shouldn't this be the PARTITION on the 
device ? (e.g. /dev/hdd1 ) Unless Autopsy & Sleuthkit have changed a lot 
since I last used them (last night) ;-) 

Re: [sleuthkit-users] Using Autopsy with a mount point rather than an image

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

Thanks to all. I will follow the unanimous advice of the list to point
Autopsy to the physical device (in this case /dev/hdd).

Regards.

On Sat, 07 Aug 2004 12:34:31 -0700 sec...@hu... wrote:
>Hello list,
>
>Is it possible to use autopsy with a harddrive that is mounted read
>only
>to a mount point rather than an image?
>
>I have a second hard drive that I want to examine that is currently
>too
>big to image on my forensics machine. I can mount the hard drive
>read-
>only to a mount point (e.g. /mnt/drive) but when I try to use the
>Autopsy
>gui to examine it it says that /mnt/drive is a directory and cannot
>use
>that location as the target.
>
>Is there a way around this with Autopsy? I can use the sleuthkit
>tools
>against a mounted hard drive jus the same.
>
>Thanks.
>



Concerned about your privacy? Follow this link to get
secure FREE email: http://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
http://www.hushmail.com/services-messenger?l=434

Promote security and make money with the Hushmail Affiliate Program: 
http://www.hushmail.com/about-affiliate?l=427

Re: [sleuthkit-users] Using Autopsy with a mount point rather than an image

[Enda C. <en...@co...>]

Correct.

Linux presents devices as files in the filesystem, so you can treat any disk
/ partition as a file. So it is equally valid to point any disk tool at an
image file or a device mount point, or a partition mount point.

You can operate on disks as if they were files, try cat /dev/hda etc. You
can operate on files as if they were disks, try fdisk'ing a dd image file.

The only time you treat them differently is when you mount them, disk image
files need to be mounted on a loopback device, and it points you at this if
you don't.

HTH,

 -Enda.

----- Original Message -----
From: Fra...@ps...
To: Enda Cronnolly
Sent: Monday, August 09, 2004 2:31 PM
Subject: Re: [sleuthkit-users] Using Autopsy with a mount point rather than
an image



When you say 'Point Autopsy' to the device do you mean in the 'add new
image' as in

1. Location: The full path (starting with /) to the raw file system image.
    /dev/hdc

Frank Kenisky IV, CISSP, CISA, CISM
Information Technical Security Specialist
(210) 301-6433 or (210) 887-6985


"Enda Cronnolly" <en...@co...>
Sent by: sle...@li...
08/07/2004 03:02 PM To<sle...@li...>
cc
SubjectRe: [sleuthkit-users] Using Autopsy with a mount point rather than an
image








> I have a second hard drive that I want to examine that is currently too
> big to image on my forensics machine. I can mount the hard drive read-
> only to a mount point (e.g. /mnt/drive) but when I try to use the Autopsy
> gui to examine it it says that /mnt/drive is a directory and cannot use
> that location as the target.

Point autopsy at the device, eg /dev/hdc or whatever device label you use
when you mount the drive.

> Is there a way around this with Autopsy? I can use the sleuthkit tools
> against a mounted hard drive jus the same.

You don't need the drive to be mounted at all.

HTH,

-Enda.

> Thanks.
> -----BEGIN PGP SIGNATURE-----
> Note: This signature can be verified at https://www.hushtools.com/verify
> Version: Hush 2.4
>
> wkYEARECAAYFAkEVLscACgkQRBFe1uc9INqveACcC9fP0dacgifm0nVHumey1WN9i80A
> niyvbCH4lydhuB7RVjBKCv2VH55u
> =BW9B
> -----END PGP SIGNATURE-----
>
>
>
>
> Concerned about your privacy? Follow this link to get
> secure FREE email: http://www.hushmail.com/?l=2
>
> Free, ultra-private instant messaging with Hush Messenger
> http://www.hushmail.com/services-messenger?l=434
>
> Promote security and make money with the Hushmail Affiliate Program:
> http://www.hushmail.com/about-affiliate?l=427
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
sleuthkit-users mailing list
https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
http://www.sleuthkit.org

Re: [sleuthkit-users] Using Autopsy with a mount point rather than an image

[Enda C. <en...@co...>]

> I have a second hard drive that I want to examine that is currently too
> big to image on my forensics machine. I can mount the hard drive read-
> only to a mount point (e.g. /mnt/drive) but when I try to use the Autopsy
> gui to examine it it says that /mnt/drive is a directory and cannot use
> that location as the target.

Point autopsy at the device, eg /dev/hdc or whatever device label you use
when you mount the drive.

> Is there a way around this with Autopsy? I can use the sleuthkit tools
> against a mounted hard drive jus the same.

You don't need the drive to be mounted at all.

HTH,

 -Enda.

> Thanks.
> -----BEGIN PGP SIGNATURE-----
> Note: This signature can be verified at https://www.hushtools.com/verify
> Version: Hush 2.4
>
> wkYEARECAAYFAkEVLscACgkQRBFe1uc9INqveACcC9fP0dacgifm0nVHumey1WN9i80A
> niyvbCH4lydhuB7RVjBKCv2VH55u
> =BW9B
> -----END PGP SIGNATURE-----
>
>
>
>
> Concerned about your privacy? Follow this link to get
> secure FREE email: http://www.hushmail.com/?l=2
>
> Free, ultra-private instant messaging with Hush Messenger
> http://www.hushmail.com/services-messenger?l=434
>
> Promote security and make money with the Hushmail Affiliate Program:
> http://www.hushmail.com/about-affiliate?l=427
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>

[sleuthkit-users] Using Autopsy with a mount point rather than an image

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

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

Hello list,

Is it possible to use autopsy with a harddrive that is mounted read only
to a mount point rather than an image?

I have a second hard drive that I want to examine that is currently too
big to image on my forensics machine. I can mount the hard drive read-
only to a mount point (e.g. /mnt/drive) but when I try to use the Autopsy
gui to examine it it says that /mnt/drive is a directory and cannot use
that location as the target.

Is there a way around this with Autopsy? I can use the sleuthkit tools
against a mounted hard drive jus the same.

Thanks.
-----BEGIN PGP SIGNATURE-----
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 2.4

wkYEARECAAYFAkEVLscACgkQRBFe1uc9INqveACcC9fP0dacgifm0nVHumey1WN9i80A
niyvbCH4lydhuB7RVjBKCv2VH55u
=BW9B
-----END PGP SIGNATURE-----




Concerned about your privacy? Follow this link to get
secure FREE email: http://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
http://www.hushmail.com/services-messenger?l=434

Promote security and make money with the Hushmail Affiliate Program: 
http://www.hushmail.com/about-affiliate?l=427

[sleuthkit-users] e-crime and computer evidence conference 2005

[Angus M. <an...@n-...>]

Just a quick reminder that the Call for Papers for the e-crime and computer 
evidence conference 2005 (Monaco, March 29th & 30th) closes on 27th August 
2004.

We have had a number of interesting submissions, including a workshop proposal 
from Warren Kruse, but still have room for more papers. 

Further details at http://www.ecce-conference.com/

[sleuthkit-users] Third release of Searchtools (Indexed searching) for Sleuthkit/Autopsy

[Paul B. <p.j...@br...>]

Hello everyone,

The work on Searchtools was halted a bit when my hard drive crashed in =
february, just when
I had done a major rewrite during a holiday... Because I never have =
gotten any feedback on the
usage of the indexed searching patches, I did not get the urge to redo =
all those changes again....

Then 2 weeks ago, I got an e-mail from somebody who was using the =
patches and requested
updated patches for the newer versions of Sleuthkit and Autopsy.... This =
e-mail has resulted in
this new third release.

Not all the features that I had wanted in the third release have made it =
due to the crash, but still
a lot of improvements have been made:
 * Generalized the internal structure to support multiple index types.
 * Added extra index type in addition to the already existing raw =
indexes: raw fragments indexes.
   These indexes contain all the strings that exist within files on the =
image but are stored in two
   non adjecent disk fragments.
 * Much improved/optimized file format, resulting in more index data =
stored in less disk space.
 * Improved memory model and handling of the index tree resulting in =
more index data fitting in
   the memory during the indexing.
 * Reading of images now uses the fstools library (from sleuthkit) in =
order to not remake the
   filesystem understanding knowledge.
 * Better organized index files/directories
 * Higher stability of the tools
 * Added extra tools for validating files/printing data from the indexes
 * Better integration within Autopsy

The patches can be downloaded from the usual place: =
http://www.brainspark.nl/?show=3Dtools_sleuthkit=20
This link can also be found on the Download page on =
http://www.sleuthkit.org=20

The patches have been tested on both Autopsy 2.01 and 2.02 and on both =
Sleuthkit 1.70 and 1.71.
Other versions may or may not work.

If the patches do not work on a platform, or if you have questions or =
suggestions regarding these
patches, please feel free to e-mail me.

Paul Bakker

[sleuthkit-users] Third release of Searchtools (Indexed searching) for Sleuthkit/Autopsy

[<p.j...@br...>]

Hello everyone,
 
The work on Searchtools was halted a bit when my hard drive crashed in february, just when
I had done a major rewrite during a holiday... Because I never have gotten any feedback on the
usage of the indexed searching patches, I did not get the urge to redo all those changes again....
 
Then 2 weeks ago, I got an e-mail from somebody who was using the patches and requested
updated patches for the newer versions of Sleuthkit and Autopsy.... This e-mail has resulted in
this new third release.
 
Not all the features that I had wanted in the third release have made it due to the crash, but still
a lot of improvements have been made:
 * Generalized the internal structure to support multiple index types.
 * Added extra index type in addition to the already existing raw indexes: raw fragments indexes.
   These indexes contain all the strings that exist within files on the image but are stored in two
   non adjecent disk fragments.
 * Much improved/optimized file format, resulting in more index data stored in less disk space.
 * Improved memory model and handling of the index tree resulting in more index data fitting in
   the memory during the indexing.
 * Reading of images now uses the fstools library (from sleuthkit) in order to not remake the
   filesystem understanding knowledge.
 * Better organized index files/directories
 * Higher stability of the tools
 * Added extra tools for validating files/printing data from the indexes
 * Better integration within Autopsy
 
The patches can be downloaded from the usual place: http://www.brainspark.nl/?show=tools_sleuthkit 
This link can also be found on the Download page on http://www.sleuthkit.org 
 
The patches have been tested on both Autopsy 2.01 and 2.02 and on both Sleuthkit 1.70 and 1.71.
Other versions may or may not work.
 
If the patches do not work on a platform, or if you have questions or suggestions regarding these
patches, please feel free to e-mail me.
 
Paul Bakker