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

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

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

On Thu, Jan 06, 2005 at 12:18:53AM -0500, Brian Carrier wrote:
> >  fls -f fat -la -s 0 /path/to/dd/image 2
>=20
> [For future reference, the commands are listed in the execution log in=20
> the evidence locker. :) ]

Oh, how convenient! You've thought of everything. :) My fairly blunt
strace at least showed the same thing the execution log shows.

> Are you sure you have a partition image and not a disk image?  What is=20
> the error message before the usage information is displayed. There=20
> should be one line that explains why it gave an error.

Sadly, there isn't even the one-liner error message. :( I've appended
output near the end.

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

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

> Hmm.  I do not know of anyone that has used them under Debian on an=20
> iBook.  There could be an endian ordering issue with the package.  You=20
> may want to try directly from the source.

"Try directly from the source" -- do you mean try running autopsy and
TSK on my brother's OS X machine? Or compiling TSK from source? I
tried compiling TSK from Debian's source on machine with identical
results. (This shouldn't surprise me. I did it with intentions of being
able to try suggestions that include source modifications. :) I haven't
tried running TSK on my brother's OS X machine simply because I've never
compiled anything on it and didn't want to bother late at night.. :)

Thanks Brian.

ps: now I can't recall if I mentioned that I tried a variety of fat*
filesystem types -- fat12, fat16, fat32, FAT12, FAT16, FAT32, and just
plain fat. (I tried the 12 bit fat out of desparation. No way a gigabyte
SD card uses FAT12 though... :)

The log file includes this:
Wed Jan  5 00:49:30 2005: '/usr/bin/fls' -f fat -la  -s 0 '/home/sarnold/er=
ic_sandisk/ericsandisk/macosx/images/eric_sandisk' 2


Running fls by hand:
$ /usr/bin/fls -f fat -la  -s 0 /home/sarnold/sandisk.dd
usage: /usr/bin/fls [-adDFlpruvV] [-f fstype] [-m dir/] [-z ZONE] [-s secon=
ds] image [inode]
        If [inode] is not given, the root directory is used
        -a: Display "." and ".." entries
        -d: Display deleted entries only
        -D: Display directory entries only
        -F: Display file entries only (NOTE: This was -f in TCTUTILs)
        -l: Display long version (like ls -l)
        -m: Display output in mactime input format with
              dir/ as the actual mount point of the image
        -p: Display full path for each file
        -r: Recurse on directory entries
        -u: Display undeleted entries only
        -v: verbose output to stderr
        -V: Print version
        -z: Time zone of original machine (i.e. EST5EDT or GMT) (only usefu=
l with -l)
        -s seconds: Time skew of original machine (in seconds) (only useful=
 with -l & -m)
        -f fstype: Image file system type
Supported file system types:
        bsdi (BSDi FFS)
        fat (auto-detect FAT)
        fat12 (FAT12)
        fat16 (FAT16)
        fat32 (FAT32)
        freebsd (FreeBSD FFS)
        linux-ext (auto-detect Linux EXTxFS)
        linux-ext2 (Linux EXT2FS)
        linux-ext3 (Linux EXT3FS)
        netbsd (NetBSD FFS)
        ntfs (NTFS)
        openbsd (OpenBSD FFS)
        raw (Raw Data)
        solaris (Solaris FFS)
        swap (Swap Space)
$

Running fls under ltrace:
$ cat /tmp/fls.out
__libc_start_main(7, 0x7ffffd14, 0x7ffffd34, 0x7ffffd7c, 0x3000bee4 <unfini=
shed ...>
getopt(7, 0x7ffffd14, "adDf:Fm:lprs:uvVz:")                                =
    =3D 102
getopt(7, 0x7ffffd14, "adDf:Fm:lprs:uvVz:")                                =
    =3D 108
getopt(7, 0x7ffffd14, "adDf:Fm:lprs:uvVz:")                                =
    =3D 97
getopt(7, 0x7ffffd14, "adDf:Fm:lprs:uvVz:")                                =
    =3D 115
__strtol_internal("0", NULL, 10)                                           =
    =3D 0
getopt(7, 0x7ffffd14, "adDf:Fm:lprs:uvVz:")                                =
    =3D -1
printf("usage: %s [-adDFlpruvV] [-f fsty"..., "/usr/bin/fls")              =
    =3D 93
puts("\tIf [inode] is not given, the ro"...)                               =
    =3D 53
puts("\t-a: Display "." and ".." entrie"...)                               =
    =3D 34
=2E...

And, a bit of the start of the partition image:
$ od /tmp/fivetwelve | head
0000000 165476 110120 073562 051550 067564 020000 001040 000400
0000020 001000 001000 000370 172400 037400 020000 037400 000000
0000040 140603 017000 100000 024710 060736 066105 047523 057504
0000060 044507 044524 040514 043101 052061 033040 020040 031777
0000100 107337 137000 076215 116344 000616 043402 176271 000002
0000120 171644 143407 054000 177457 106310 175216 150274 000006
0000140 175613 166203 166026 142466 074000 104566 173214 057370
0000160 106576 165271 005400 053763 122137 107331 137170 000211
0000200 036214 042002 007037 143105 002022 143105 004417 131000
0000220 110715 011640 014000 173046 015000 104506 175203 037352
$ hexdump /tmp/fivetwelve | head
0000000 eb3e 9050 7772 5368 6f74 2000 0220 0100
0000010 0200 0200 00f8 f500 3f00 2000 3f00 0000
0000020 c183 1e00 8000 29c8 61de 6c45 4f53 5f44
0000030 4947 4954 414c 4641 5431 3620 2020 33ff
0000040 8edf be00 7c8d 9ce4 018e 4702 fcb9 0002
0000050 f3a4 c707 5800 ff2f 8cc8 fa8e d0bc 0006
0000060 fb8b ec83 ec16 c536 7800 8976 f68c 5ef8
0000070 8d7e eab9 0b00 57f3 a45f 8ed9 be78 0089
0000080 3c8c 4402 0e1f c645 0412 c645 090f b200
0000090 91cd 13a0 1800 f626 1a00 8946 fa83 3eea

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

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

On Jan 5, 2005, at 6:04 PM, Seth Arnold wrote:

> Hello,
>
> I've been trying to use autopsy's interface to the sleuthkit tools to
> try to recover information from my brother's sandisk CF card. (_Very_
> impressive-looking tools! Job well done on the interface.)
>
> However, I'm stopped very early on by a failing 'fls' command. 
> Autopsy's
> file/directory listing interface is clearly not prepared to handle the
> usage() output from fls. I used 'strace' to find the arguments to the
> fls command, which (as I recall from memory..) looked like this:
>
>   fls -f fat -la -s 0 /path/to/dd/image 2

[For future reference, the commands are listed in the execution log in 
the evidence locker. :) ]

Are you sure you have a partition image and not a disk image?  What is 
the error message before the usage information is displayed. There 
should be one line that explains why it gave an error.

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

Hmm.  I do not know of anyone that has used them under Debian on an 
iBook.  There could be an endian ordering issue with the package.  You 
may want to try directly from the source.

brian

[sleuthkit-users] fls simply reports usage information?

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

Hello,

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

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

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

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

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

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

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

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

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

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

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

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

Every single attempt _always_ reported the usage statement. :(

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

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

Does anyone have suggestions what to do next? :)

Thanks!

RE: [sleuthkit-users] Using splitted images in autopsy

[Altheide, C. B. (IARC) <Alt...@nv...>]

> -----Original Message-----
> From: sle...@li... 
> [mailto:sle...@li...] On 
> Behalf Of David Collett
> Sent: Wednesday, December 15, 2004 6:25 PM
> To: sle...@li...
> Cc: Benjamin J. Weiss
> Subject: Re: [sleuthkit-users] Using splitted images in autopsy
> 
> 
> I've just rejoined this list, so I missed the original post. 
> Assuming the filesystems etc are ok, you have a few options.
> 
> I noticed while helping someone use another linux-based 
> forensics tool that it uses the linux kernel 'raid' 
> infastructure to achieve this, basic summary is:
> 
> 1. create a loop device for each segment containing parts of 
> the desired partition, possible providing an offset if 
> required into the first section to make it start at the start 
> of the filesystem. 2. put them all together with a 'linear' 
> raid array using the linux kernels 'md' raid subsystem.
> 
> Then I presume you could point sk at the raid device (eg. 
> /dev/md0) which would represent the desired partition.

This does work - I outlined it on the linux_forensics yahoo list a few
months back.  Here's that post for anyone who missed it:

I haven't had to do this for a while, but the procedure is something like
so:

1) Create loop devices associated with your raw *volume* (not disk) chunks.

2) Create an /etc/raidtab file with something along the lines of the
following ($x indicates a variable you must supply):

raiddev /dev/md0 
    raid-level                linear 
    nr-raid-disks             $N #N being the number of chunks you've got.
    persistent-superblock   	0
    chunk-size                X # Not used for this level of RAID, so any
value is fine.

    device                    /dev/loop0 
    raid-disk                 0 
    device                    /dev/loop1
    raid-disk                 1 
    ...(snip)...
    device				/dev/loopN-1
    raid-disk			N-1

3) Initialize the raid device

root@yourbox # mkraid /dev/md0

4) If you cat /proc/mdstat you should see stats on your new raid.

5) Mount /dev/md0 @ /FORENSICS/MOUNTPOINT - read-only, of course! ;)

Again, this is pretty hazy, but I can verify and do a more complete HOWTO if
there's interest.  Disk image chunks won't work unless there is only one
volume of interest and you apply an offset when creating your loop devices
to point to the beginning of that volume.  If there are other volumes on
partitions after that one, "physical" searches of the /dev/md0 will return
data from these spaces as well.  I haven't tested against different sized
chunks and don't know enough about the innards of software raid to determine
whether it'll cause problems or not, but I'll test that as part of the
HOWTO, again, if there's interest.

-------------------------------

This was confirmed by Andy Rosen and is (I believe) more or less the method
used by SMART to perform this function, who added this:

=======================================================
> You are correct and that is (as usual) a great answer.
> I have found that the chunks must be integral
> exponents of 1024 byte blocks AND that it helps if
> loop.o is a module (as opposed to in kernel).  I use
> 
> rmmod loop
> insmod loop max_loop=255
> 
> in my init script (rc.local) to insure that I have
> plenty of available loopback devices.
> 
> Also, loop is 32 bit clean, but beyond that, the
> offset to loop appears to be 31 bits.
=======================================================

> BIG DISCLAIMER:
> I havent done this personally, it may be more complicated 
> than I just described, In particular I would think that a 
> signature of some kind might be written to the segments when 
> you create the array, this is probably an option, so be very 
> careful you know what you are doing if you choose this 
> approach. Futhermore, I personally think its a bit of a 
> dangerous choice for a forensics tool to be doing all this 
> stuff as root using the OS kernel.

Could you explain why you think this is "dangerous," absolutely or
comparatively? 

> Which leads me to another approach. pyFLAG (pyflag.sf.net) 
> uses an IO Subsystem abstraction to deal with split images 
> (as well as RAID, Encase, and other file formats). An 
> exciting new tool in flag is called 'iowrapper', it works by 
> using LD_PRELOAD to load its own file operations (read, seek, 
> etc) before libc, thus overriding them and applying the IO 
> Subsystem abstraction. It therefore allows you to use any 
> unmodified binary program on your 'reconstructed' virtual 
> image transparently. More details can be found in the pyflag 
> source, but here's an example of how might use it with 'fls':
> 
> export LD_PRELOAD=./libs/libio_hooker.so
> ./bin/iowrapper -i advanced -o 
> offset=32256,file=part1.dd,file=part2.dd,file=part3.dd 
> ./bin/fls -r foo.dd

Very very interesting stuff, I definitely be playing with this.  I haven't
had the opportunity to use PyFLAG as much as I'd like, but I really like the
direction this is going. :)

Do you feel that there are any security/other implications with overriding
the standard libc operations in this manner?  Why is this more desirable
than using preexisting kernel capabilities on a dedicated forensics station
to perform the equivalent end result?

> This is pretty new code and I cannot guarantee it will work 
> for you, if you wish to try you will need the latest pyflag 
> sources from the 'darcs' repository, details for grabing it 
> are at pyflag.sf.net. This tool is not in any actual release 
> versions of pyflag, but will be in the next release.
> 
> hope this helps,
> Dave
> 
> On Wed, 15 Dec 2004 18:57:41 -0500, Brian Carrier 
> <ca...@sl...> wrote:
> > 
> > On Dec 15, 2004, at 10:24 AM, Benjamin J. Weiss wrote:
> > > I'm working on a disk image now with damaged partition/file 
> > > allocation tables.  Any idea when the disk-image Autopsy will be 
> > > ready? :)
> > 
> > If the partition table and file system are damaged, then v2 of TSK 
> > will not help.  It only processes that data that exists.
> > 
> > brian
> > 
> > 
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real 
> > users. Discover which products truly live up to the hype. Start 
> > reading now. http://productguide.itmanagersjournal.com/
> > _______________________________________________
> > sleuthkit-users mailing list 
> > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> > http://www.sleuthkit.org
> >
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from 
> real users. Discover which products truly live up to the 
> hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> sleuthkit-users mailing list 
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
> 

Re: [sleuthkit-users] Using splitted images in autopsy

[David C. <dav...@gm...>]

looks like the website doesnt have 'darcs' instructions afterall,
email me directly if you want to know how to get it.

Re: [sleuthkit-users] Using splitted images in autopsy

[David C. <dav...@gm...>]

I've just rejoined this list, so I missed the original post. 
Assuming the filesystems etc are ok, you have a few options.

I noticed while helping someone use another linux-based forensics tool
that it uses the linux kernel 'raid' infastructure to achieve this,
basic summary is:

1. create a loop device for each segment containing parts of the
desired partition, possible providing an offset if required into the
first section to make it start at the start of the filesystem.
2. put them all together with a 'linear' raid array using the linux
kernels 'md' raid subsystem.

Then I presume you could point sk at the raid device (eg. /dev/md0)
which would represent the desired partition.

BIG DISCLAIMER:
I havent done this personally, it may be more complicated than I just
described, In particular I would think that a signature of some kind
might be written to the segments when you create the array, this is
probably an option, so be very careful you know what you are doing if
you choose this approach. Futhermore, I personally think its a bit of
a dangerous choice for a forensics tool to be doing all this stuff as
root using the OS kernel.

Which leads me to another approach. pyFLAG (pyflag.sf.net) uses an IO
Subsystem abstraction to deal with split images (as well as RAID,
Encase, and other file formats). An exciting new tool in flag is
called 'iowrapper', it works by using LD_PRELOAD to load its own file
operations (read, seek, etc) before libc, thus overriding them and
applying the IO Subsystem abstraction. It therefore allows you to use
any unmodified binary program on your 'reconstructed' virtual image
transparently. More details can be found in the pyflag source, but
here's an example of how might use it with 'fls':

export LD_PRELOAD=./libs/libio_hooker.so
./bin/iowrapper -i advanced -o
offset=32256,file=part1.dd,file=part2.dd,file=part3.dd ./bin/fls -r
foo.dd

This is pretty new code and I cannot guarantee it will work for you,
if you wish to try you will need the latest pyflag sources from the
'darcs' repository, details for grabing it are at pyflag.sf.net. This
tool is not in any actual release versions of pyflag, but will be in
the next release.

hope this helps,
Dave

On Wed, 15 Dec 2004 18:57:41 -0500, Brian Carrier <ca...@sl...> wrote:
> 
> On Dec 15, 2004, at 10:24 AM, Benjamin J. Weiss wrote:
> > I'm working on a disk image now with damaged partition/file allocation
> > tables.  Any idea when the disk-image Autopsy will be ready? :)
> 
> If the partition table and file system are damaged, then v2 of TSK will
> not help.  It only processes that data that exists.
> 
> brian
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>

Re: [sleuthkit-users] Using splitted images in autopsy

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

On Dec 15, 2004, at 10:24 AM, Benjamin J. Weiss wrote:
> I'm working on a disk image now with damaged partition/file allocation
> tables.  Any idea when the disk-image Autopsy will be ready? :)

If the partition table and file system are damaged, then v2 of TSK will 
not help.  It only processes that data that exists.

brian
  
  

Re: [sleuthkit-users] Using splitted images in autopsy

[Benjamin J. W. <ben...@bi...>]

On Mon, 13 Dec 2004, Brian Carrier wrote:

> 
> On Dec 13, 2004, at 3:46 AM, LERTI - David Billard wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Dear all,
> >
> > I have some disks (up to 80Go) to acquire. I'm using dd and my images 
> > are
> > splitted into 700MB files. Is there a way to use these splitted images 
> > in
> > Autopsy?
> 
> Autopsy does not yet support split images, although that and disk 
> images are tops on the list for the next major addition (which will be 
> soon).  I think pyFlag may support them though...
> 
> http://pyflag.sourceforge.net/
> 
I'm working on a disk image now with damaged partition/file allocation 
tables.  Any idea when the disk-image Autopsy will be ready? :)

Ben

Re: [sleuthkit-users] Using splitted images in autopsy

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

On Dec 13, 2004, at 3:46 AM, LERTI - David Billard wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dear all,
>
> I have some disks (up to 80Go) to acquire. I'm using dd and my images 
> are
> splitted into 700MB files. Is there a way to use these splitted images 
> in
> Autopsy?

Autopsy does not yet support split images, although that and disk 
images are tops on the list for the next major addition (which will be 
soon).  I think pyFlag may support them though...

http://pyflag.sourceforge.net/

brian 
  

[sleuthkit-users] Using splitted images in autopsy

[LERTI - D. B. <Dav...@le...>]

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

Dear all,

I have some disks (up to 80Go) to acquire. I'm using dd and my images are
splitted into 700MB files. Is there a way to use these splitted images in
Autopsy?

Thanks,

David.
- --
LERTI - Laboratoire d'Expertise et de
Recherche de Traces Informatiques
http://www.lerti.fr |  mobile : +41 79 746 7305
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBvVbKv6mUNUu+e+URAoxVAJ9GCWNI7LwtepTOdRB7OYnkK9Ih6gCglhfH
HQSpr98Ld44rIisscDAkbYs=
=o740
-----END PGP SIGNATURE-----

Re: [sleuthkit-users] dcalc - Block too large

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

On Dec 9, 2004, at 4:29 PM, Dan Jones wrote:

> I recently received a "Block too large" error from dcalc while trying 
> to execute
>     dcalc -s 21187952 -f ntfs image.dd
>
> image.dd is  approximately 20 GB.
> The 'dls -s' output  from which the target fragment was determined 
> resulted in a 15 GB slack space image..

Are you sure you used the '-s' with 'dls' to get only the slack space?  
15 GB seems huge for slack space.

That message appears when it did not find the equivalent block in the 
original image.   What is the cluster size in the original image?  Do 
you also get an error if you run it with '-u NUM', which you would use 
for the unallocated address?

brian

[sleuthkit-users] dcalc - Block too large

[<dj...@mi...>]

I recently received a "Block too large" error from dcalc while trying to 
execute
     dcalc -s 21187952 -f ntfs image.dd

image.dd is  approximately 20 GB.  

The 'dls -s' output  from which the target fragment was determined 
resulted in a 15 GB slack space image..

These image sizes don't seem all that excessive, although the slack 
space is a pretty sizable portion of total image size.  (It seems like 
the OS had been recently re-installed.)

What are the size limitations for dcalc?

Thanks

Dan Jones

Re: [sleuthkit-users] Moving case locker, files, etc...

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

On Nov 22, 2004, at 8:30 PM, Rich Thompson wrote:

> I am upgrading Linux distros, and will need to
> preserve some case locker files, etc...  can I just
> burn the entire case locker to a disk, re-install
> Linux, re-install the Sleuthkit and Autopsy, then copy
> back the case locker???  I might need to work more on
> these cases, and I want to pick up where I left off (I
> really don;t want to do all that work again...)


Yea.  The evidence locker is very flexible.  It has no full paths 
inside of it.  The only potential issue is if you imported your 
partition images with a symbolic link then the image must exist in the 
same location in your new system or you need to manually delete the 
link and make a new one to the new location.

Check out the Informer #2 for more details:
http://www.sleuthkit.org/informer/sleuthkit-informer-2.html

brian
  

Re: [sleuthkit-users] Which tools to use?

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

On Nov 19, 2004, at 3:43 PM, Benjamin J. Weiss wrote:
....

> I'm guessing that the partition table's been wiped, and 
> possibly/probably
> the file allocation table.
>
> I've yanked the drive out of the enclosure and am about to plug it 
> into my
> desktop system running CentOS (a red-hat EL 3 re-compile distro).  I've
> purchased a 200GB SATA drive and put it my system.
>
> 1) I'm assuming that I'm going to have to make a disk-image of his 
> drive?
> 2) Is there a way to get the files off of the drive or image?
> 3) If so, what tools should I look at?

Check out gpart/TestDisk to recover partitions (if any of the original 
file system data exists) and 'foremost' to recover file content of 
known file types.

brian

[sleuthkit-users] Moving case locker, files, etc...

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

Howdy,

I am upgrading Linux distros, and will need to
preserve some case locker files, etc...  can I just
burn the entire case locker to a disk, re-install
Linux, re-install the Sleuthkit and Autopsy, then copy
back the case locker???  I might need to work more on
these cases, and I want to pick up where I left off (I
really don;t want to do all that work again...)

So will it work?

Thanks,
Rich

[sleuthkit-users] Which tools to use?

[Benjamin J. W. <ben...@bi...>]

All,

I'm hoping that somebody can point me in the direction of the appropriate 
tools to learn to resolve a problem I've got.

A friend of mine has a Seagate 160GB USB drive that he's put a *bunch* of 
stuff on.  Apparently he hooked it up to a Mac, and said that it went 
nuts, at which time he yanked the cable.  He says that he thinks that it 
was originally set up as a single NTFS partition, but now it looks to me 
like a 32GB FAT32 partition with no files.

I'm guessing that the partition table's been wiped, and possibly/probably 
the file allocation table.

I've yanked the drive out of the enclosure and am about to plug it into my 
desktop system running CentOS (a red-hat EL 3 re-compile distro).  I've 
purchased a 200GB SATA drive and put it my system.

1) I'm assuming that I'm going to have to make a disk-image of his drive?
2) Is there a way to get the files off of the drive or image?
3) If so, what tools should I look at?

Thanks much!

Ben Weiss

[sleuthkit-users] ECCE 2005 reminder

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

Just a quick reminder that you only have a few days to book a place at the 
discounted rate for the e-crime and computer evidence conference to be held 
on March 29th & 30th March.

Papers to be presented cover procedural issues relating to evidence recovery & 
interpretation (including detection of "anti-forensic" methods), legal issues 
from around the world (including viruses) and network investigations 
(including use of honeypots and remote forensic tools)

We also plan workshops on network investigation (led by Warren Kruse) and 
International Standards for education and training.

Full details are at http://www.ecce-conference.com/

Re: [sleuthkit-users] freebsd and icat bug

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

There is a bug in the Ext2/3 and UFS1 code with FreeBSD 5.0, which 
neutrino reported.  FreeBSD 5 changes the default size of a disk 
address to 64-bits and TSK used to assume that it would be 32-bits, so 
processing the indirect block pointers was a problems (it skipped over 
half of the addresses).

You can get the latest versions of src/fstools/ext2fs.c and 
src/fstools/ffs.c here:

http://sleuthkit.sourceforge.net/sleuthkit/ext2fs.c
http://sleuthkit.sourceforge.net/sleuthkit/ffs.c

brian

[sleuthkit-users] Importing IBM AIX5.2 rootvg from physicaldrive to> linuxbox

[Sucharkiewicz, J. <Jak...@t-...>]

hi@ll!

we have some problems with AIX5.2 rootvg. maybe someone can help us.
for analysing an incident we have to attach some physicaldrives from a 
IBM RS/6000 Server. We have access to the rawdevice but on the linux-box
we haven't any access to the volume group rootvg or even to the logical-volumes.
did anyone have done something similiar? How it could be possible to start a lvm 
an import such rootvg from the physicaldrive to start a grave-robber?
help would be apreciated!

thx!
momurder

[sleuthkit-users] problem recovering data on ext3

[Justin S. <jms...@gm...>]

my name is justin and i ran into a big problem tonight i deleted my ~/
by accident and i need to recover it all.  its an ext3 partition and i
was trying to use sleuth kit and autopsy but im so frazzeled because
of the possible loss of all my data that i cant think .   is there any
way you could help me out with this problem?   email me here or you
can reach me on aim  screen name sunsejm. im going to post this to the
list so maybe i can get some help

Re: [sleuthkit-users] problem to image

[philippe J. <ph....@ab...>]

Brian Carrier wrote:
> 
> On Nov 12, 2004, at 7:57 AM, philippe Jarlov wrote:
> 
>> Michel Roukine wrote:
>>
>>> hi Philippe,
>>> Maybe you have to unmount your usb key. As I did below :
> 
> 
>> Thank you very much Michel, it is working well now with this umount.
> 
> 
> Alternatively, you can use the raw device instead of unmounting it (i.e. 
> /dev/rdiskX).  Unmounting it is better though because it ensures that 
> the file system is in a clean state.

Thank you Brian.

I use the usb key for testing. Of course it's better to shutdown 
automount in real case or use a drive lock on hard drive.


> 
> Nothing special is needed as long as you have the latest versions of 
> Autopsy and TSK.  OS X used to need a special version of 'strings', but 
> no longer.
> 

Yes, it is working well, and I have de latest version. So I enjoy now to
work to on mac os x if I need :-)

Thank you Brian for your work !!

Philippe Jarlov

Re: [sleuthkit-users] problem to image

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

On Nov 12, 2004, at 7:57 AM, philippe Jarlov wrote:

> Michel Roukine wrote:
>
>> hi Philippe,
>> Maybe you have to unmount your usb key. As I did below :

> Thank you very much Michel, it is working well now with this umount.

Alternatively, you can use the raw device instead of unmounting it 
(i.e. /dev/rdiskX).  Unmounting it is better though because it ensures 
that the file system is in a clean state.

> Could you tell me what kind of options I must use to use this .img 
> with autopsy now, or is there a documentation on how to use autopsy 
> with Mac OS X ?

Nothing special is needed as long as you have the latest versions of 
Autopsy and TSK.  OS X used to need a special version of 'strings', but 
no longer.

brian

Re: [sleuthkit-users] problem to image

[Michel R. <mi...@ro...>]

> Thank you very much Michel, it is working well now with this umount.
>
> Could you tell me what kind of options I must use to use this .img 
> with autopsy now, or is there a documentation on how to use autopsy 
> with Mac OS X ?

If it is an usb key, I think its file system is FAT, so you just have to 
specify "fat" as file system type in the "add a new image" page.

But I do not know if there is a specific documentation for Autopsy under 
MacOS X.

hth

Michel (à la prochaine :^)

> Philippe (and I hope that's all ;-)
>

Re: [sleuthkit-users] problem to image

[philippe J. <ph....@ab...>]

Michel Roukine wrote:

> 
> 
> hi Philippe,
> 
> Maybe you have to unmount your usb key. As I did below :
> 
> bonite:~ root# df
> Filesystem              512-blocks     Used     Avail Capacity  Mounted on
> .
> .
> .
> /dev/disk1s1                127176    86932     40244    68%    
> /Volumes/NO NAME
> bonite:~ root# dd if=/dev/disk1s1 of=~kato/image_clefusb.img
> dd: /dev/disk1s1: Device busy
> bonite:~ root# umount /Volumes/NO\ NAME/
> bonite:~ root# dd if=/dev/disk1s1 of=~kato/image_clefusb.img
> 127456+0 records in
> 127456+0 records out
> 65257472 bytes transferred in 123.628805 secs (527850 bytes/sec)
> bonite:~ root#

Thank you very much Michel, it is working well now with this umount.

Could you tell me what kind of options I must use to use this .img with 
autopsy now, or is there a documentation on how to use autopsy with Mac 
OS X ?

Philippe (and I hope that's all ;-)

Re: [sleuthkit-users] problem to image

[Michel R. <mi...@ro...>]

philippe Jarlov wrote:

> Hello,
>
> I'm coming back into this list after a year :-)
>
> And I have a question. I'm trying to imaging on Mac OS X
> to use autopsy. Autopsy is working well but
>
> - I can't image a usb drive :
> Ordinateur-de-moi:/Volumes/PHIL_USB moi$ dd if=/dev/disk2s1 
> of=/Users/moi/image_clefusb/image_clefusb.img
> dd: /dev/disk2s1: Device busy
>
> How can I change this ?

hi Philippe,

Maybe you have to unmount your usb key. As I did below :

bonite:~ root# df
Filesystem              512-blocks     Used     Avail Capacity  Mounted on
.
.
.
/dev/disk1s1                127176    86932     40244    68%    
/Volumes/NO NAME
bonite:~ root# dd if=/dev/disk1s1 of=~kato/image_clefusb.img
dd: /dev/disk1s1: Device busy
bonite:~ root# umount /Volumes/NO\ NAME/
bonite:~ root# dd if=/dev/disk1s1 of=~kato/image_clefusb.img
127456+0 records in
127456+0 records out
65257472 bytes transferred in 123.628805 secs (527850 bytes/sec)
bonite:~ root#

>
> Thank you very much, I use usualy autopsy on Linux system, and
> I'm discovering Mac OS X...hum some change...
>
> Philippe Jarlov
> France
>
Michel Roukine