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

[sleuthkit-users] mmls and FAT12 partition question

[js <fo...@em...>]

Hi list,

I have a dd image of a floppy.

when examining this floppy with the disktype command I get:

> disktype floppy1.001
>
> --- floppy1.001
> Regular file, size 1.406 MiB (1474560 bytes)
> FAT12 file system (hints score 5 of 5)
>   Volume size 1.390 MiB (1457664 bytes, 2847 clusters of 512 bytes)

When I want to list the partitions on this image i do:

> mmls floppy1.001
> DOS Partition Table
> Sector: 0
> Units are in 512-byte sectors
>
>      Slot    Start        End          Length       Description
> 00:  -----   0000000000   0000000000   0000000001   Primary Table (#0)
> 01:  -----   0000000001   1112359496   1112359496   Unallocated
> 02:  00:01   1112359497   1651347857   0538988361   Novell Netware (0x65)
> 03:  00:02   1126178899   1126198689   0000019791   Win LVM / Secure 
> FS (0x42)
> 04:  -----   1126198690   1869562399   0743363710   Unallocated
> 05:  00:00   1869562400   3503645331   1634082932   GoBack (0x44)

When I want some extra info about this FAT12 disk I do:
This also confirms its a FAT12.
> dosfsck -v floppy1.001
> dosfsck 2.11 (12 Mar 2005)
> dosfsck 2.11, 12 Mar 2005, FAT32, LFN
> Checking we can access the last sector of the filesystem
> Boot sector contents:
> System ID "IBM  3.3"
> Media byte 0xf0 (5.25" or 3.5" HD floppy)
>        512 bytes per logical sector
>        512 bytes per cluster
>          1 reserved sector
> First FAT starts at byte 512 (sector 1)
>          2 FATs, 12 bit entries
>       4608 bytes per FAT (= 9 sectors)
> Root directory starts at byte 9728 (sector 19)
>        224 root directory entries
> Data area starts at byte 16896 (sector 33)
>       2847 data clusters (1457664 bytes)
> 18 sectors/track, 2 heads
>          0 hidden sectors
>       2880 sectors total
> Checking for unused clusters.
> floppy1.001: 1 files, 0/2847 clusters


When I check how many space there is left on the disk I get :

> df -h
> Filesystem            Size  Used Avail Use% Mounted on
> /dev/floppy/0         1.4M   51K  1.4M   4% /mnt/floppy

I can list the contents of this disk, no problem.


Where does the information that mmls produces come from?
Why can I read the disk without any problems on my linux box and windows 
box?
How can the OS handle this disk since the partition layout is completely 
wrong?


Thanks in advance list,

Js.

Re: [sleuthkit-users] sleuthkit on Ubuntu

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

The problem is that AFFLIB (for the AFF image format) requires zlib and=20
openssl, both of which do not seem to be included with Ubuntu by=20
default.  You will need to install those packages and libraries. Most=20
systems come with those libraries, but Ubuntu does not seem to (I went=20
through the same pain a couple of months ago setting a system up).

Also, someone else had issues compiling Kubuntu with the version of=20
AFFLIB that was included in tsk 2.04, so you should probably update the=20
AFFLIB with the latest version:

1.  Download version 1.6.26
http://www.afflib.org/downloads/afflib-1.6.26.tar.gz

2.  Untar it.

3.  Remove the src/afflib directory from TSK.

4.  Move the afflib-1.6.26 directory to src/afflib (be sure you name it=20
afflib and not afflib-1.6.26).

5. Compile TSK as normal.


Now that TSK requires external libraries, I may need to start using=20
autoconf so that these dependencies can be sorted out before compiling...=
.

brian




Sorrelle Michael W Ctr AFOSI/DOZI wrote:
> Hello,
>=20
> =20
>=20
> I just joined this list, so if my question is in a FAQ, my apologies;=20
> just point me to that.
>=20
> =20
>=20
> Has anyone tried to build/install sleuthkit on Ubuntu Linux?
>=20
> I have a completely fresh/clean installation of Ubuntu (+ development=20
> tools), but TSK won=92t build.  I get the following errors:
>=20
> =93In file included from aff_db.cpp:8:
>=20
>  afflib_i.h:53:18: error: zlib.h: No such file or directory
>=20
>  afflib_i.h:60:26: error: openssl/rand.h: No such file or directory
>=20
>  make: *** [aff_db.o] Error 1
>=20
>  make: *** [no-perl] Error 2=94
>=20
> =20
>=20
> FYI, perl IS installed: version 5.8.7
>=20
> =20
>=20
> Any hints/tips will be appreciated.
>=20
> =20
>=20
> *- -*
>=20
> *Mike Sorrelle*
>=20
> /Sr. Software Engineer/
>=20
> /FPMI Solutions, Inc./

Re: [sleuthkit-users] sleuthkit on Ubuntu

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

I apologize for asking such basic questions.  However, your email did
not include this information and just assuming that you have already
answered these questions would slow down any sort of helpful response
this list may provide.

Do the openssl.h and zlib.h files exist on your system?

If so, did you use the expected procedure to get the package that
contains them installed?

If not, can you alter your 'configure' command to include their locations?

-Jason

On 5/30/06, Sorrelle Michael W Ctr AFOSI/DOZI <l> wrote:
>
>
>
>
> Hello,
>
>
>
> I just joined this list, so if my question is in a FAQ, my apologies; just
> point me to that.
>
>
>
> Has anyone tried to build/install sleuthkit on Ubuntu Linux?
>
> I have a completely fresh/clean installation of Ubuntu (+ development
> tools), but TSK won't build.  I get the following errors:
>
> "In file included from aff_db.cpp:8:
>
>  afflib_i.h:53:18: error: zlib.h: No such file or directory
>
>  afflib_i.h:60:26: error: openssl/rand.h: No such file or directory
>
>  make: *** [aff_db.o] Error 1
>
>  make: *** [no-perl] Error 2"
>
>
>
> FYI, perl IS installed: version 5.8.7
>
>
>
> Any hints/tips will be appreciated.
>
>
>
> - -
>
> Mike Sorrelle
>
> Sr. Software Engineer
>
> FPMI Solutions, Inc.
>
>
>
>

[sleuthkit-users] sleuthkit on Ubuntu

[Sorrelle M. W C. AFOSI/D. <mic...@og...>]

Hello,

 

I just joined this list, so if my question is in a FAQ, my apologies; just
point me to that.

 

Has anyone tried to build/install sleuthkit on Ubuntu Linux?

I have a completely fresh/clean installation of Ubuntu (+ development
tools), but TSK won't build.  I get the following errors:

"In file included from aff_db.cpp:8:

 afflib_i.h:53:18: error: zlib.h: No such file or directory

 afflib_i.h:60:26: error: openssl/rand.h: No such file or directory

 make: *** [aff_db.o] Error 1

 make: *** [no-perl] Error 2"

 

FYI, perl IS installed: version 5.8.7

 

Any hints/tips will be appreciated.

 

- -

Mike Sorrelle

Sr. Software Engineer

FPMI Solutions, Inc.

 

 

Re: [sleuthkit-users] sleuthkit-2.04 compilation errors

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

Let's try this again. For CYGWIN users who had problems with the updated 
AFFLIB, try version 1.6.25.  Same instructions, but download:

http://www.afflib.org/downloads/afflib-1.6.25.tar.gz

brian


Brian Carrier wrote:
> Ok, the latest version of AFFLIB compiles under CYGWIN. I'm going to 
> wait a week or so before I release a new TSK, but you can easily drop in 
> the new AFFLIB and compile.  Here's how you do it:
> 
> 1.  Download version 1.6.24
> http://www.afflib.org/downloads/afflib-1.6.24.tar.gz
> 
> 2.  Untar it.
> 
> 3.  Remove the src/afflib directory from TSK.
> 
> 4.  Move the afflib-1.6.24 directory to src/afflib (be sure you name it 
> afflib and not afflib-1.6.24).
> 
> 5. Compile TSK as normal.
> 
> You'll get some more CYGWIN warnings in various tools that I have fixed. 
> They are not critical.
> 
> brian
> 
> 
> Brian Carrier wrote:
>> I'll fix the warnings in auxtools.  Those are in the new error 
>> handling code.
>>
>> The errors though are in AFFlib, which was not included in version 
>> 2.03.   We'll get the Cygwin compile errors fixed in that.
>>
>> brian
>>
>> DePriest, Jason R. wrote:
>>> When I run 'make' it goes to src/auxtools and finishes that with some
>>> non-critical errors:
>>> cd src/auxtools; make "CC=gcc" MAKELEVEL=
>>> gcc -DCYGWIN -DVER=\"2.04\" -O -Wall -g   -c -o mymalloc.o mymalloc.c
>>> gcc -DCYGWIN -DVER=\"2.04\" -O -Wall -g   -c -o strerror.o strerror.c
>>> gcc -DCYGWIN -DVER=\"2.04\" -O -Wall -g   -c -o split_at.o split_at.c
>>> gcc -DCYGWIN -DVER=\"2.04\" -O -Wall -g   -c -o tsk_endian.o 
>>> tsk_endian.c
>>> gcc -DCYGWIN -DVER=\"2.04\" -O -Wall -g   -c -o unicode.o unicode.c
>>> gcc -DCYGWIN -DVER=\"2.04\" -O -Wall -g   -c -o data_buf.o data_buf.c
>>> gcc -DCYGWIN -DVER=\"2.04\" -O -Wall -g   -c -o tsk_version.o 
>>> tsk_version.c
>>> gcc -DCYGWIN -DVER=\"2.04\" -O -Wall -g   -c -o tsk_error.o tsk_error.c
>>> tsk_error.c: In function `tsk_error_print':
>>> tsk_error.c:99: warning: int format, long unsigned int arg (arg 3)
>>> tsk_error.c:106: warning: int format, long unsigned int arg (arg 3)
>>> tsk_error.c:112: warning: int format, long unsigned int arg (arg 3)
>>> tsk_error.c:118: warning: int format, long unsigned int arg (arg 3)
>>> tsk_error.c:121: warning: int format, uint32_t arg (arg 3)
>>> gcc -DCYGWIN -DVER=\"2.04\" -O -Wall -g   -c -o tsk_parse.o tsk_parse.c
>>> ar rv ../../lib/libauxtools.a mymalloc.o strerror.o split_at.o
>>> tsk_endian.o unicode.o data_buf.o tsk_version.o tsk_error.o
>>> tsk_parse.o
>>> ar: creating ../../lib/libauxtools.a
>>> a - mymalloc.o
>>> a - strerror.o
>>> a - split_at.o
>>> a - tsk_endian.o
>>> a - unicode.o
>>> a - data_buf.o
>>> a - tsk_version.o
>>> a - tsk_error.o
>>> a - tsk_parse.o
>>> ranlib ../../lib/libauxtools.a
>>>
>>> However, after it cds to src/afflib/lib, it get an error an exits:
>>> cd src/auxtools; make "CC=gcc" MAKELEVEL=
>>> make: Nothing to be done for `all'.
>>> cd src/afflib/lib; make "CC=gcc" MAKELEVEL=
>>> g++ -c -g -Wall -I/usr/local/ssl/include -I/usr/sfw/include -I. -Ilib
>>> -o afflib.o afflib.cpp
>>> afflib.cpp: In function `AFFILE* af_open_with(const char*, int, int,
>>> af_vnode*)':
>>> afflib.cpp:152: error: `warnx' undeclared (first use this function)
>>> afflib.cpp:152: error: (Each undeclared identifier is reported only
>>> once for each function it appears in.)
>>> make: *** [afflib.o] Error 1
>>> make: *** [no-perl] Error 2
>>>
>>> Any idea what I am missing?  I swear I was able to compile version
>>> 2.03 on the same system.
> 
> 
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and Risk!
> Fully trained technicians. The highest number of Red Hat certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

Re: [sleuthkit-users] dls rawfs_block_walk errors

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

Yea, the image size is not a multiple of 512 and the file system code 
makes that assumption.  So, the error occurred because it could not read 
a full 512 bytes from the final sector.  I'll look into changing it so 
that it better handles this situation.

brian


Mark K. Murdock wrote:
> The image size is 30005826468 bytes.  I imported it as a raw drive 
> image.  It was previously NTFS, but was formatted and then a small (2 
> GB) FAT32 filesystem was created and a new operating system was 
> installed in it. 
> 
> So, in the "Select a volume to analyze or add a new image file" screen I 
> see:
> 
> disk    image-QWUF12CCHU-copy.dd-disk   raw     details
> C:/     image-QWUF12CCHU-copy.dd-63-4160834     fat32   details
> 
> Mark
> 
> 
> -----Original Message-----
> From: Brian Carrier [mailto:ca...@sl...]
> Sent: Thu 5/25/2006 7:46 AM
> To: Mark K. Murdock
> Cc: sle...@li...
> Subject: Re: [sleuthkit-users] dls rawfs_block_walk errors
> 
> What is the size (in bytes) of the file  you are reading?  I guess 
> this error could occur if your file is not a multiple of 512-bytes.  
> Did you import the file image as a rawfs?
> 
> brian
> 
> 
> 
> On May 25, 2006, at 12:08 AM, Mark K. Murdock wrote:
> 
>  > Hi all,
>  >
>  > I'm using Sleuthkit 2.03 and Autopsy 2.06 on Debian Linux (Sarge).  
>  > While extracting Unicode strings from an image, dls threw the 
>  > following error:
>  >
>  > /usr/local/sleuthkit/bin/dls: rawfs_block_walk: Error reading block 
>  > at 58605129: Success
>  >
>  > It did the same thing during an ASCII string extraction, but I 
>  > didn't note the exact error.  I checked the source (rawfs.c) and it 
>  > looks like that error occurs when (surprise) there's a problem 
>  > reading a block while iterating the blocks of the image.  I'm not 
>  > sure exactly what the problem was, because I didn't rerun the dls 
>  > command with the verbose option specified (I'm planning to, but 
>  > it's time consuming and I haven't gotten to that yet).
>  >
>  > My questions are:  When it comes to extracting strings, is it 
>  > important that a block read error be a fatal error?  Currently it 
>  > stops the string extraction (because dls quits).  I was thinking of 
>  > making a small change to the source to keep iterating the blocks 
>  > past a read error based on a command argument (an "ignore read 
>  > errors" type switch).  Am I just getting myself into trouble here, 
>  > or does doing something like this make sense?
>  >
>  > Thanks,
>  > Mark
>  >
> 
> 

RE: [sleuthkit-users] dls rawfs_block_walk errors

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

Oh, well wait ... I just noticed that the block reported in the error =
(58605129) is the last block of my raw disk image.  So I'm no longer =
concerned it's missing information in the string extraction. ;)


-----Original Message-----
From: Brian Carrier [mailto:ca...@sl...]
Sent: Thu 5/25/2006 7:46 AM
To: Mark K. Murdock
Cc: sle...@li...
Subject: Re: [sleuthkit-users] dls rawfs_block_walk errors
=20
What is the size (in bytes) of the file  you are reading?  I guess =20
this error could occur if your file is not a multiple of 512-bytes.  =20
Did you import the file image as a rawfs?

brian



On May 25, 2006, at 12:08 AM, Mark K. Murdock wrote:

> Hi all,
>
> I'm using Sleuthkit 2.03 and Autopsy 2.06 on Debian Linux (Sarge).  =20
> While extracting Unicode strings from an image, dls threw the =20
> following error:
>
> /usr/local/sleuthkit/bin/dls: rawfs_block_walk: Error reading block =20
> at 58605129: Success
>
> It did the same thing during an ASCII string extraction, but I =20
> didn't note the exact error.  I checked the source (rawfs.c) and it =20
> looks like that error occurs when (surprise) there's a problem =20
> reading a block while iterating the blocks of the image.  I'm not =20
> sure exactly what the problem was, because I didn't rerun the dls =20
> command with the verbose option specified (I'm planning to, but =20
> it's time consuming and I haven't gotten to that yet).
>
> My questions are:  When it comes to extracting strings, is it =20
> important that a block read error be a fatal error?  Currently it =20
> stops the string extraction (because dls quits).  I was thinking of =20
> making a small change to the source to keep iterating the blocks =20
> past a read error based on a command argument (an "ignore read =20
> errors" type switch).  Am I just getting myself into trouble here, =20
> or does doing something like this make sense?
>
> Thanks,
> Mark
>

RE: [sleuthkit-users] dls rawfs_block_walk errors

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

The image size is 30005826468 bytes.  I imported it as a raw drive =
image.  It was previously NTFS, but was formatted and then a small (2 =
GB) FAT32 filesystem was created and a new operating system was =
installed in it. =20

So, in the "Select a volume to analyze or add a new image file" screen I =
see:

disk	image-QWUF12CCHU-copy.dd-disk	raw	details
C:/	image-QWUF12CCHU-copy.dd-63-4160834	fat32	details

Mark


-----Original Message-----
From: Brian Carrier [mailto:ca...@sl...]
Sent: Thu 5/25/2006 7:46 AM
To: Mark K. Murdock
Cc: sle...@li...
Subject: Re: [sleuthkit-users] dls rawfs_block_walk errors
=20
What is the size (in bytes) of the file  you are reading?  I guess =20
this error could occur if your file is not a multiple of 512-bytes.  =20
Did you import the file image as a rawfs?

brian



On May 25, 2006, at 12:08 AM, Mark K. Murdock wrote:

> Hi all,
>
> I'm using Sleuthkit 2.03 and Autopsy 2.06 on Debian Linux (Sarge).  =20
> While extracting Unicode strings from an image, dls threw the =20
> following error:
>
> /usr/local/sleuthkit/bin/dls: rawfs_block_walk: Error reading block =20
> at 58605129: Success
>
> It did the same thing during an ASCII string extraction, but I =20
> didn't note the exact error.  I checked the source (rawfs.c) and it =20
> looks like that error occurs when (surprise) there's a problem =20
> reading a block while iterating the blocks of the image.  I'm not =20
> sure exactly what the problem was, because I didn't rerun the dls =20
> command with the verbose option specified (I'm planning to, but =20
> it's time consuming and I haven't gotten to that yet).
>
> My questions are:  When it comes to extracting strings, is it =20
> important that a block read error be a fatal error?  Currently it =20
> stops the string extraction (because dls quits).  I was thinking of =20
> making a small change to the source to keep iterating the blocks =20
> past a read error based on a command argument (an "ignore read =20
> errors" type switch).  Am I just getting myself into trouble here, =20
> or does doing something like this make sense?
>
> Thanks,
> Mark
>

Re: [sleuthkit-users] dls rawfs_block_walk errors

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

What is the size (in bytes) of the file  you are reading?  I guess  
this error could occur if your file is not a multiple of 512-bytes.   
Did you import the file image as a rawfs?

brian



On May 25, 2006, at 12:08 AM, Mark K. Murdock wrote:

> Hi all,
>
> I'm using Sleuthkit 2.03 and Autopsy 2.06 on Debian Linux (Sarge).   
> While extracting Unicode strings from an image, dls threw the  
> following error:
>
> /usr/local/sleuthkit/bin/dls: rawfs_block_walk: Error reading block  
> at 58605129: Success
>
> It did the same thing during an ASCII string extraction, but I  
> didn't note the exact error.  I checked the source (rawfs.c) and it  
> looks like that error occurs when (surprise) there's a problem  
> reading a block while iterating the blocks of the image.  I'm not  
> sure exactly what the problem was, because I didn't rerun the dls  
> command with the verbose option specified (I'm planning to, but  
> it's time consuming and I haven't gotten to that yet).
>
> My questions are:  When it comes to extracting strings, is it  
> important that a block read error be a fatal error?  Currently it  
> stops the string extraction (because dls quits).  I was thinking of  
> making a small change to the source to keep iterating the blocks  
> past a read error based on a command argument (an "ignore read  
> errors" type switch).  Am I just getting myself into trouble here,  
> or does doing something like this make sense?
>
> Thanks,
> Mark
>

[sleuthkit-users] dls rawfs_block_walk errors

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

Hi all,

I'm using Sleuthkit 2.03 and Autopsy 2.06 on Debian Linux (Sarge).  =
While extracting Unicode strings from an image, dls threw the following =
error:

/usr/local/sleuthkit/bin/dls: rawfs_block_walk: Error reading block at =
58605129: Success

It did the same thing during an ASCII string extraction, but I didn't =
note the exact error.  I checked the source (rawfs.c) and it looks like =
that error occurs when (surprise) there's a problem reading a block =
while iterating the blocks of the image.  I'm not sure exactly what the =
problem was, because I didn't rerun the dls command with the verbose =
option specified (I'm planning to, but it's time consuming and I haven't =
gotten to that yet).

My questions are:  When it comes to extracting strings, is it important =
that a block read error be a fatal error?  Currently it stops the string =
extraction (because dls quits).  I was thinking of making a small change =
to the source to keep iterating the blocks past a read error based on a =
command argument (an "ignore read errors" type switch).  Am I just =
getting myself into trouble here, or does doing something like this make =
sense?

Thanks,
Mark

Re: [sleuthkit-users] sleuthkit-2.04 compilation errors

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

I still get errors.  I even have a gigantic strace of the make session
if anyone wants it.

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-
cd src/afflib/lib; make "CC=3Dgcc" MAKELEVEL=3D
g++ -c -g -Wall -I/usr/local/ssl/include -I/usr/sfw/include -I. -Ilib
 -o aff_db.o aff_db.cpp
g++ -c -g -Wall -I/usr/local/ssl/include -I/usr/sfw/include -I. -Ilib
 -o aff_toc.o aff_toc.cpp
g++ -c -g -Wall -I/usr/local/ssl/include -I/usr/sfw/include -I. -Ilib
 -o afflib.o afflib.cpp
afflib.cpp: In function `AFFILE* af_open_with(const char*, int, int,
af_vnode*)':
afflib.cpp:152: error: `warnx' undeclared (first use this function)
afflib.cpp:152: error: (Each undeclared identifier is reported only
once for each function it appears in.)
make: *** [afflib.o] Error 1
make: *** [no-perl] Error 2
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-

On 5/23/06, Brian Carrier <> wrote:
> Ok, the latest version of AFFLIB compiles under CYGWIN. I'm going to
> wait a week or so before I release a new TSK, but you can easily drop in
> the new AFFLIB and compile.  Here's how you do it:
>
> 1.  Download version 1.6.24
> http://www.afflib.org/downloads/afflib-1.6.24.tar.gz
>
> 2.  Untar it.
>
> 3.  Remove the src/afflib directory from TSK.
>
> 4.  Move the afflib-1.6.24 directory to src/afflib (be sure you name it
> afflib and not afflib-1.6.24).
>
> 5. Compile TSK as normal.
>
> You'll get some more CYGWIN warnings in various tools that I have fixed.
> They are not critical.
>
> brian
>
>
> Brian Carrier wrote:
> > I'll fix the warnings in auxtools.  Those are in the new error handling
> > code.
> >
> > The errors though are in AFFlib, which was not included in version 2.03=
.
> >   We'll get the Cygwin compile errors fixed in that.
> >
> > brian
> >
> > DePriest, Jason R. wrote:
> >> When I run 'make' it goes to src/auxtools and finishes that with some
> >> non-critical errors:
> >> cd src/auxtools; make "CC=3Dgcc" MAKELEVEL=3D
> >> gcc -DCYGWIN -DVER=3D\"2.04\" -O -Wall -g   -c -o mymalloc.o mymalloc.=
c
> >> gcc -DCYGWIN -DVER=3D\"2.04\" -O -Wall -g   -c -o strerror.o strerror.=
c
> >> gcc -DCYGWIN -DVER=3D\"2.04\" -O -Wall -g   -c -o split_at.o split_at.=
c
> >> gcc -DCYGWIN -DVER=3D\"2.04\" -O -Wall -g   -c -o tsk_endian.o tsk_end=
ian.c
> >> gcc -DCYGWIN -DVER=3D\"2.04\" -O -Wall -g   -c -o unicode.o unicode.c
> >> gcc -DCYGWIN -DVER=3D\"2.04\" -O -Wall -g   -c -o data_buf.o data_buf.=
c
> >> gcc -DCYGWIN -DVER=3D\"2.04\" -O -Wall -g   -c -o tsk_version.o
> >> tsk_version.c
> >> gcc -DCYGWIN -DVER=3D\"2.04\" -O -Wall -g   -c -o tsk_error.o tsk_erro=
r.c
> >> tsk_error.c: In function `tsk_error_print':
> >> tsk_error.c:99: warning: int format, long unsigned int arg (arg 3)
> >> tsk_error.c:106: warning: int format, long unsigned int arg (arg 3)
> >> tsk_error.c:112: warning: int format, long unsigned int arg (arg 3)
> >> tsk_error.c:118: warning: int format, long unsigned int arg (arg 3)
> >> tsk_error.c:121: warning: int format, uint32_t arg (arg 3)
> >> gcc -DCYGWIN -DVER=3D\"2.04\" -O -Wall -g   -c -o tsk_parse.o tsk_pars=
e.c
> >> ar rv ../../lib/libauxtools.a mymalloc.o strerror.o split_at.o
> >> tsk_endian.o unicode.o data_buf.o tsk_version.o tsk_error.o
> >> tsk_parse.o
> >> ar: creating ../../lib/libauxtools.a
> >> a - mymalloc.o
> >> a - strerror.o
> >> a - split_at.o
> >> a - tsk_endian.o
> >> a - unicode.o
> >> a - data_buf.o
> >> a - tsk_version.o
> >> a - tsk_error.o
> >> a - tsk_parse.o
> >> ranlib ../../lib/libauxtools.a
> >>
> >> However, after it cds to src/afflib/lib, it get an error an exits:
> >> cd src/auxtools; make "CC=3Dgcc" MAKELEVEL=3D
> >> make: Nothing to be done for `all'.
> >> cd src/afflib/lib; make "CC=3Dgcc" MAKELEVEL=3D
> >> g++ -c -g -Wall -I/usr/local/ssl/include -I/usr/sfw/include -I. -Ilib
> >> -o afflib.o afflib.cpp
> >> afflib.cpp: In function `AFFILE* af_open_with(const char*, int, int,
> >> af_vnode*)':
> >> afflib.cpp:152: error: `warnx' undeclared (first use this function)
> >> afflib.cpp:152: error: (Each undeclared identifier is reported only
> >> once for each function it appears in.)
> >> make: *** [afflib.o] Error 1
> >> make: *** [no-perl] Error 2
> >>
> >> Any idea what I am missing?  I swear I was able to compile version
> >> 2.03 on the same system.
>

Re: [sleuthkit-users] sleuthkit-2.04 compilation errors

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

Ok, the latest version of AFFLIB compiles under CYGWIN. I'm going to 
wait a week or so before I release a new TSK, but you can easily drop in 
the new AFFLIB and compile.  Here's how you do it:

1.  Download version 1.6.24
http://www.afflib.org/downloads/afflib-1.6.24.tar.gz

2.  Untar it.

3.  Remove the src/afflib directory from TSK.

4.  Move the afflib-1.6.24 directory to src/afflib (be sure you name it 
afflib and not afflib-1.6.24).

5. Compile TSK as normal.

You'll get some more CYGWIN warnings in various tools that I have fixed. 
They are not critical.

brian


Brian Carrier wrote:
> I'll fix the warnings in auxtools.  Those are in the new error handling 
> code.
> 
> The errors though are in AFFlib, which was not included in version 2.03. 
>   We'll get the Cygwin compile errors fixed in that.
> 
> brian
> 
> DePriest, Jason R. wrote:
>> When I run 'make' it goes to src/auxtools and finishes that with some
>> non-critical errors:
>> cd src/auxtools; make "CC=gcc" MAKELEVEL=
>> gcc -DCYGWIN -DVER=\"2.04\" -O -Wall -g   -c -o mymalloc.o mymalloc.c
>> gcc -DCYGWIN -DVER=\"2.04\" -O -Wall -g   -c -o strerror.o strerror.c
>> gcc -DCYGWIN -DVER=\"2.04\" -O -Wall -g   -c -o split_at.o split_at.c
>> gcc -DCYGWIN -DVER=\"2.04\" -O -Wall -g   -c -o tsk_endian.o tsk_endian.c
>> gcc -DCYGWIN -DVER=\"2.04\" -O -Wall -g   -c -o unicode.o unicode.c
>> gcc -DCYGWIN -DVER=\"2.04\" -O -Wall -g   -c -o data_buf.o data_buf.c
>> gcc -DCYGWIN -DVER=\"2.04\" -O -Wall -g   -c -o tsk_version.o 
>> tsk_version.c
>> gcc -DCYGWIN -DVER=\"2.04\" -O -Wall -g   -c -o tsk_error.o tsk_error.c
>> tsk_error.c: In function `tsk_error_print':
>> tsk_error.c:99: warning: int format, long unsigned int arg (arg 3)
>> tsk_error.c:106: warning: int format, long unsigned int arg (arg 3)
>> tsk_error.c:112: warning: int format, long unsigned int arg (arg 3)
>> tsk_error.c:118: warning: int format, long unsigned int arg (arg 3)
>> tsk_error.c:121: warning: int format, uint32_t arg (arg 3)
>> gcc -DCYGWIN -DVER=\"2.04\" -O -Wall -g   -c -o tsk_parse.o tsk_parse.c
>> ar rv ../../lib/libauxtools.a mymalloc.o strerror.o split_at.o
>> tsk_endian.o unicode.o data_buf.o tsk_version.o tsk_error.o
>> tsk_parse.o
>> ar: creating ../../lib/libauxtools.a
>> a - mymalloc.o
>> a - strerror.o
>> a - split_at.o
>> a - tsk_endian.o
>> a - unicode.o
>> a - data_buf.o
>> a - tsk_version.o
>> a - tsk_error.o
>> a - tsk_parse.o
>> ranlib ../../lib/libauxtools.a
>>
>> However, after it cds to src/afflib/lib, it get an error an exits:
>> cd src/auxtools; make "CC=gcc" MAKELEVEL=
>> make: Nothing to be done for `all'.
>> cd src/afflib/lib; make "CC=gcc" MAKELEVEL=
>> g++ -c -g -Wall -I/usr/local/ssl/include -I/usr/sfw/include -I. -Ilib
>> -o afflib.o afflib.cpp
>> afflib.cpp: In function `AFFILE* af_open_with(const char*, int, int,
>> af_vnode*)':
>> afflib.cpp:152: error: `warnx' undeclared (first use this function)
>> afflib.cpp:152: error: (Each undeclared identifier is reported only
>> once for each function it appears in.)
>> make: *** [afflib.o] Error 1
>> make: *** [no-perl] Error 2
>>
>> Any idea what I am missing?  I swear I was able to compile version
>> 2.03 on the same system.

[sleuthkit-users] Idea on Tivo issue- not open source, though

[Jennifer S. <g33...@li...>]

As much as I hesitate to suggest this on this message board, when I did a g=
oogle search, I did notice that v5 of Encase Forensic edition is supposed t=
o include "expanded file system support" to incude both Tivo Series1 and Se=
ries2 (http://www.digitalintelligence.com/software/guidancesoftware/encase/)

I know it isn't a sleuthkit answer, but maybe it'll help...

-gg

--=20
_______________________________________________
Check out the latest SMS services @ http://www.linuxmail.org
This allows you to send and receive SMS through your mailbox.

Powered by Outblaze

Re: [sleuthkit-users] Processing a Tivo

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

On 5/19/06, Detective David Vitkus <> wrote:
> I'm looking for info / advice on processing a TIVO.  It's a child abuse
> case and there's an allegation that the suspect showed the victim a
> pornographic movie prior to / during the assault(s).
>
> Have a good weekend all,
> Have a good weekend all,
>
> --
>
> David Vitkus
> Detective
> Northampton Police Department
> 29 Center St.
> Northampton, MA 01060
> 413-587-1133 (voice)
> 413-587-1137 (fax)
>
> Note: Recently our e-mail servers have been equipped with very aggressive=
 spam filters.  Consequently, valid messages may be inadvertently purged.  =
If you expect a response from me and don't get one, please call.

As for relevance to this site, these are following "facts" that seem
most promising (from http://cbbrowne.com/info/othervars.html):
<quote>
This is a TV "recorder" consisting of:
* Some form of display controller, used to display system messages and
menus as well as TV broadcasts,
* A disk drive, which can record, in "low quality" mode, 1h/GB, which
is used to "record/buffer" programs,
* A modem, used daily to connect to a server at Tivo to download
broadcast schedule information, and
* A PPC CPU, used to control all of the above.

It isn't particularly visible, but the TiVo runs Linux .

Various people have taken interest in trying to expand the
capabilities of their TiVo recorders, particularly to allow additional
storage.
... To do interesting things like upgrading the hard drive, run other
software on the unit, or such...

Interesting properties:
* Tivo units use PPC, not IA-32;
* The partition tables on hard disks use modified Macintosh-style
partition tables;
* The units load a special kernel module in that read/write the
special "Tivo" filesystem;
* Drives are byteswapped.
* With some hacking around, you can mount some of the partitions as
ext2 filesystems, and look at the contents of /var as well as root
partitions.
* Apparently they have figured out how to "bless" a drive so that it
can be used to augment the space available.
</quote>

Re: [sleuthkit-users] Processing a Tivo

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

On 5/19/06, Detective David Vitkus <> wrote:
> I'm looking for info / advice on processing a TIVO.  It's a child abuse
> case and there's an allegation that the suspect showed the victim a
> pornographic movie prior to / during the assault(s).
>
> Have a good weekend all,
> Have a good weekend all,
>
> --
>
> David Vitkus
> Detective
> Northampton Police Department
> 29 Center St.
> Northampton, MA 01060
> 413-587-1133 (voice)
> 413-587-1137 (fax)
>
> Note: Recently our e-mail servers have been equipped with very aggressive=
 spam filters.  Consequently, valid messages may be inadvertently purged.  =
If you expect a response from me and don't get one, please call.

I did a few Google searches and found some things that might help you out.

This one details mounting a TiVo hard disk drive direct-connected to a
PC and has some stuff about decrypting as well.  It mentions some
tools and scripts that you can track down.
http://www.dealdatabase.com/forum/showthread.php?t=3D23192&page=3D4

This just lists some facts about TiVo (such as "it runs Linux")
http://cbbrowne.com/info/othervars.html

This is a SourceForge site called TiVo Enhancement.  It has a 'pdisk'
tool patched to work with TiVo partition tables.
http://tivohack.sourceforge.net/

You could also try searching TiVo's own forum archives, I saw some
interesting things there.
http://www.tivocommunity.com/

-Jason

[sleuthkit-users] Processing a Tivo

[Detective D. V. <dv...@no...>]

I'm looking for info / advice on processing a TIVO.  It's a child abuse 
case and there's an allegation that the suspect showed the victim a 
pornographic movie prior to / during the assault(s).

Have a good weekend all,
Have a good weekend all,

-- 

David Vitkus
Detective
Northampton Police Department
29 Center St.
Northampton, MA 01060
413-587-1133 (voice)
413-587-1137 (fax)

Note: Recently our e-mail servers have been equipped with very aggressive spam filters.  Consequently, valid messages may be inadvertently purged.  If you expect a response from me and don't get one, please call.

Re: [sleuthkit-users] HD Passwords

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

I seem to recall sporadic success with the Rockbox=2Eorg tools (built for=

removing the password on the Archos mp3 hard drive)=2E

http=3A//www=2Erockbox=2Eorg/lock=2Ehtml

Good Luck!

M Shannon

----- Original Message -----
From=3A LERTI - David Billard =3CDavid=2EBillard=40lerti=2Efr=3E
Date=3A Thursday=2C May 18=2C 2006 3=3A44 pm
Subject=3A Re=3A =5Bsleuthkit-users=5D HD Passwords
To=3A J B =3Cjessopb=40adelphia=2Enet=3E
Cc=3A sleuthkit-users=40lists=2Esourceforge=2Enet

=3E -----BEGIN PGP SIGNED MESSAGE-----
=3E Hash=3A SHA1
=3E =

=3E Dear JB=2C
=3E =

=3E There is a long thread on the forensic focus forum =

=3E (http=3A//www=2Eforensicfocus=2Ecom/ got to forum Hardware-=3EForensi=
c =

=3E Recovery and ATA-3 =27Secure Mode=27=2C possible=3F)=2E
=3E Some people stated that you can use a particular manufacturer =

=3E interface to recover the ATA password=2E I=27m not entirely convinced=
 =

=3E but one never knows with undocumented features=2E
=3E I suggested a way of bypassing the password=2C using a second similar=
 =

=3E drive and hotswapping the data/command cable=2C but this solution has=
 =

=3E been rejected by people with more knowledge than myself=2E
=3E =

=3E I wish you good luck=2C
=3E =

=3E David=2E
=3E J B a =E9crit =3A
=3E =3E This is off topic=2C though it does pertain to forensic =

=3E recovery=2E=2E=2Esorry=2E=2E=2E=3E  =

=3E =3E I was about to post a question about the best reference on =

=3E cracking ata
=3E =3E hd passwords=3B The best reference is google pointing to caches o=
f
=3E =3E experts-exchange threads mentioning loads of possibilities=2C but=
 =

=3E only a
=3E =3E couple certainties=2E  A company called vogon has a product=3B ru=
mour =

=3E has it
=3E =3E it=27s 30=2E000 pounds=2C =2450=2C000=3F =

=3E =3E  =

=3E =3E http=3A//www=2Evogon-forensic-hardware=2Eco=2Euk/forensic-hardwar=
e/data-
=3E capture/password-cracker-pod=2Ehtm
=3E =3E  =

=3E =3E And the spec for ata3=2E
=3E =3E  =

=3E =3E http=3A//www=2Eseagate=2Ecom/support/disc/manuals/ata/d1153r17=2E=
pdf
=3E =3E  =

=3E =3E Some suggested swapping the pcb from the disk with another =

=3E similar=2E =

=3E =3E Since the drive security info is stored on a certain =22track =

=3E description=3E area=22 cylinder rather than on the board (only)=2C th=
e =

=3E board would just
=3E =3E read that cylinder and continue securing the drive=2C no=3F=2E  =

=3E Instead=2C I
=3E =3E would propose using a pre-ata3 board=2E  I would guess that the =

=3E problem is
=3E =3E that it may not understand the new language of the track descript=
ion
=3E =3E area=2E  Consequently=2C the solution to the problem lies in =

=3E replacing the
=3E =3E pcb with a custom pcb which can control the heads and understands=
 =

=3E the=3E track description language of the (even proprietary) drive=2E =
I =

=3E don=27t=3E pretend this is an original idea=2C but I would be interes=
ted =

=3E in knowing
=3E =3E what I=27m missing - In short=2C going back to programatic contro=
l of =

=3E the=3E heads=2E  Even if it=27s not fast=2C it would be faster and ch=
eaper =

=3E than the
=3E =3E electron microscope method and less invasive than any kind of cus=
tom
=3E =3E spindle/heads rig=2E  From what I=27ve seen=2C there are no chips=
 =

=3E =27after=27 the
=3E =3E ribon cable entering the housing=2E  If you control the heads (an=
d =

=3E spindle=3E motor)=2C do you not control the drive=3F
=3E =3E  =

=3E =3E BTW=2C any idea how these guys operate=3F =

=3E =3E http=3A//a-ff=2Ecom/products/rrs/
=3E =3E  =

=3E =3E thanks=2E
=3E =3E -JB
=3E =

=3E - --
=3E LERTI - Laboratoire d=27Expertise et de
=3E Recherche de Traces Informatiques
=3E http=3A//www=2Elerti=2Efr =7C  mobile =3A +41 79 746 7305
=3E -----BEGIN PGP SIGNATURE-----
=3E Version=3A GnuPG v1=2E4=2E2 (MingW32)
=3E Comment=3A Using GnuPG with Mozilla - http=3A//enigmail=2Emozdev=2Eor=
g
=3E =

=3E iD8DBQFEbM5Dv6mUNUu+e+URAtn2AJ9dBUXQiLAs8913TW1YwzZD+IeXzgCeMoaP
=3E tsi11p00JIaIInWFCmOB7yA=3D
=3E =3D1fg6
=3E -----END PGP SIGNATURE-----
=3E =

=3E =

=3E =

=3E -------------------------------------------------------
=3E Using Tomcat but need to do more=3F Need to support web services=2C =

=3E security=3FGet stuff done quickly with pre-integrated technology to =

=3E make your job easier
=3E Download IBM WebSphere Application Server v=2E1=2E0=2E1 based on Apac=
he =

=3E Geronimohttp=3A//sel=2Eas-
=3E
us=2Efalkag=2Enet/sel=3Fcmdgk=26kid=120709=26bid=263057=26dat=121642=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
=3E sleuthkit-users mailing list
=3E https=3A//lists=2Esourceforge=2Enet/lists/listinfo/sleuthkit-users
=3E http=3A//www=2Esleuthkit=2Eorg
=3E 

Re: [sleuthkit-users] HD Passwords

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

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

Dear JB,

There is a long thread on the forensic focus forum (http://www.forens=
icfocus.com/ got to forum Hardware->Forensic Recovery and ATA-3 'Secu=
re Mode', possible?).
Some people stated that you can use a particular manufacturer interfa=
ce to recover the ATA password. I'm not entirely convinced but one ne=
ver knows with undocumented features.
I suggested a way of bypassing the password, using a second similar d=
rive and hotswapping the data/command cable, but this solution has be=
en rejected by people with more knowledge than myself.

I wish you good luck,

David.
J B a =E9crit :
> This is off topic, though it does pertain to forensic recovery...so=
rry...
> =20
> I was about to post a question about the best reference on cracking=
 ata
> hd passwords; The best reference is google pointing to caches of
> experts-exchange threads mentioning loads of possibilities, but onl=
y a
> couple certainties.  A company called vogon has a product; rumour h=
as it
> it's 30.000 pounds, $50,000?=20
> =20
> http://www.vogon-forensic-hardware.co.uk/forensic-hardware/data-cap=
ture/password-cracker-pod.htm
> =20
> And the spec for ata3.
> =20
> http://www.seagate.com/support/disc/manuals/ata/d1153r17.pdf
> =20
> Some suggested swapping the pcb from the disk with another similar.=
=20
> Since the drive security info is stored on a certain "track descrip=
tion
> area" cylinder rather than on the board (only), the board would jus=
t
> read that cylinder and continue securing the drive, no?.  Instead, =
I
> would propose using a pre-ata3 board.  I would guess that the probl=
em is
> that it may not understand the new language of the track descriptio=
n
> area.  Consequently, the solution to the problem lies in replacing =
the
> pcb with a custom pcb which can control the heads and understands t=
he
> track description language of the (even proprietary) drive. I don't
> pretend this is an original idea, but I would be interested in know=
ing
> what I'm missing - In short, going back to programatic control of t=
he
> heads.  Even if it's not fast, it would be faster and cheaper than =
the
> electron microscope method and less invasive than any kind of custo=
m
> spindle/heads rig.  From what I've seen, there are no chips 'after'=
 the
> ribon cable entering the housing.  If you control the heads (and sp=
indle
> motor), do you not control the drive?
> =20
> BTW, any idea how these guys operate?=20
> http://a-ff.com/products/rrs/
> =20
> thanks.
> -JB

- --
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.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEbM5Dv6mUNUu+e+URAtn2AJ9dBUXQiLAs8913TW1YwzZD+IeXzgCeMoaP
tsi11p00JIaIInWFCmOB7yA=3D
=3D1fg6
-----END PGP SIGNATURE-----

[sleuthkit-users] HD Passwords

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

This is off topic, though it does pertain to forensic =
recovery...sorry...

I was about to post a question about the best reference on cracking ata =
hd passwords; The best reference is google pointing to caches of =
experts-exchange threads mentioning loads of possibilities, but only a =
couple certainties.  A company called vogon has a product; rumour has it =
it's 30.000 pounds, $50,000? =20

http://www.vogon-forensic-hardware.co.uk/forensic-hardware/data-capture/p=
assword-cracker-pod.htm

And the spec for ata3.

http://www.seagate.com/support/disc/manuals/ata/d1153r17.pdf

Some suggested swapping the pcb from the disk with another similar.  =
Since the drive security info is stored on a certain "track description =
area" cylinder rather than on the board (only), the board would just =
read that cylinder and continue securing the drive, no?.  Instead, I =
would propose using a pre-ata3 board.  I would guess that the problem is =
that it may not understand the new language of the track description =
area.  Consequently, the solution to the problem lies in replacing the =
pcb with a custom pcb which can control the heads and understands the =
track description language of the (even proprietary) drive. I don't =
pretend this is an original idea, but I would be interested in knowing =
what I'm missing - In short, going back to programatic control of the =
heads.  Even if it's not fast, it would be faster and cheaper than the =
electron microscope method and less invasive than any kind of custom =
spindle/heads rig.  From what I've seen, there are no chips 'after' the =
ribon cable entering the housing.  If you control the heads (and spindle =
motor), do you not control the drive?

BTW, any idea how these guys operate? =20
http://a-ff.com/products/rrs/

thanks.
-JB

Re: [sleuthkit-users] sleuthkit-2.04 compilation errors

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

I'll fix the warnings in auxtools.  Those are in the new error handling 
code.

The errors though are in AFFlib, which was not included in version 2.03. 
   We'll get the Cygwin compile errors fixed in that.

brian

DePriest, Jason R. wrote:
> When I run 'make' it goes to src/auxtools and finishes that with some
> non-critical errors:
> cd src/auxtools; make "CC=gcc" MAKELEVEL=
> gcc -DCYGWIN -DVER=\"2.04\" -O -Wall -g   -c -o mymalloc.o mymalloc.c
> gcc -DCYGWIN -DVER=\"2.04\" -O -Wall -g   -c -o strerror.o strerror.c
> gcc -DCYGWIN -DVER=\"2.04\" -O -Wall -g   -c -o split_at.o split_at.c
> gcc -DCYGWIN -DVER=\"2.04\" -O -Wall -g   -c -o tsk_endian.o tsk_endian.c
> gcc -DCYGWIN -DVER=\"2.04\" -O -Wall -g   -c -o unicode.o unicode.c
> gcc -DCYGWIN -DVER=\"2.04\" -O -Wall -g   -c -o data_buf.o data_buf.c
> gcc -DCYGWIN -DVER=\"2.04\" -O -Wall -g   -c -o tsk_version.o tsk_version.c
> gcc -DCYGWIN -DVER=\"2.04\" -O -Wall -g   -c -o tsk_error.o tsk_error.c
> tsk_error.c: In function `tsk_error_print':
> tsk_error.c:99: warning: int format, long unsigned int arg (arg 3)
> tsk_error.c:106: warning: int format, long unsigned int arg (arg 3)
> tsk_error.c:112: warning: int format, long unsigned int arg (arg 3)
> tsk_error.c:118: warning: int format, long unsigned int arg (arg 3)
> tsk_error.c:121: warning: int format, uint32_t arg (arg 3)
> gcc -DCYGWIN -DVER=\"2.04\" -O -Wall -g   -c -o tsk_parse.o tsk_parse.c
> ar rv ../../lib/libauxtools.a mymalloc.o strerror.o split_at.o
> tsk_endian.o unicode.o data_buf.o tsk_version.o tsk_error.o
> tsk_parse.o
> ar: creating ../../lib/libauxtools.a
> a - mymalloc.o
> a - strerror.o
> a - split_at.o
> a - tsk_endian.o
> a - unicode.o
> a - data_buf.o
> a - tsk_version.o
> a - tsk_error.o
> a - tsk_parse.o
> ranlib ../../lib/libauxtools.a
> 
> However, after it cds to src/afflib/lib, it get an error an exits:
> cd src/auxtools; make "CC=gcc" MAKELEVEL=
> make: Nothing to be done for `all'.
> cd src/afflib/lib; make "CC=gcc" MAKELEVEL=
> g++ -c -g -Wall -I/usr/local/ssl/include -I/usr/sfw/include -I. -Ilib
> -o afflib.o afflib.cpp
> afflib.cpp: In function `AFFILE* af_open_with(const char*, int, int,
> af_vnode*)':
> afflib.cpp:152: error: `warnx' undeclared (first use this function)
> afflib.cpp:152: error: (Each undeclared identifier is reported only
> once for each function it appears in.)
> make: *** [afflib.o] Error 1
> make: *** [no-perl] Error 2
> 
> Any idea what I am missing?  I swear I was able to compile version
> 2.03 on the same system.
> 
> Thanks!
> 
> -Jason

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

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

Reminder - the final deadline for submissions for ECCE2006 is Monday 22nd May.

Full details of the Call for Papers & Venue are at the conference website : 
http://www.ecce-conference.com/

General topic areas include : forensic techniques, legal issues, 
criminological issues, evidence presentation.

[sleuthkit-users] sleuthkit-2.04 compilation errors

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

When I run 'make' it goes to src/auxtools and finishes that with some
non-critical errors:
cd src/auxtools; make "CC=3Dgcc" MAKELEVEL=3D
gcc -DCYGWIN -DVER=3D\"2.04\" -O -Wall -g   -c -o mymalloc.o mymalloc.c
gcc -DCYGWIN -DVER=3D\"2.04\" -O -Wall -g   -c -o strerror.o strerror.c
gcc -DCYGWIN -DVER=3D\"2.04\" -O -Wall -g   -c -o split_at.o split_at.c
gcc -DCYGWIN -DVER=3D\"2.04\" -O -Wall -g   -c -o tsk_endian.o tsk_endian.c
gcc -DCYGWIN -DVER=3D\"2.04\" -O -Wall -g   -c -o unicode.o unicode.c
gcc -DCYGWIN -DVER=3D\"2.04\" -O -Wall -g   -c -o data_buf.o data_buf.c
gcc -DCYGWIN -DVER=3D\"2.04\" -O -Wall -g   -c -o tsk_version.o tsk_version=
.c
gcc -DCYGWIN -DVER=3D\"2.04\" -O -Wall -g   -c -o tsk_error.o tsk_error.c
tsk_error.c: In function `tsk_error_print':
tsk_error.c:99: warning: int format, long unsigned int arg (arg 3)
tsk_error.c:106: warning: int format, long unsigned int arg (arg 3)
tsk_error.c:112: warning: int format, long unsigned int arg (arg 3)
tsk_error.c:118: warning: int format, long unsigned int arg (arg 3)
tsk_error.c:121: warning: int format, uint32_t arg (arg 3)
gcc -DCYGWIN -DVER=3D\"2.04\" -O -Wall -g   -c -o tsk_parse.o tsk_parse.c
ar rv ../../lib/libauxtools.a mymalloc.o strerror.o split_at.o
tsk_endian.o unicode.o data_buf.o tsk_version.o tsk_error.o
tsk_parse.o
ar: creating ../../lib/libauxtools.a
a - mymalloc.o
a - strerror.o
a - split_at.o
a - tsk_endian.o
a - unicode.o
a - data_buf.o
a - tsk_version.o
a - tsk_error.o
a - tsk_parse.o
ranlib ../../lib/libauxtools.a

However, after it cds to src/afflib/lib, it get an error an exits:
cd src/auxtools; make "CC=3Dgcc" MAKELEVEL=3D
make: Nothing to be done for `all'.
cd src/afflib/lib; make "CC=3Dgcc" MAKELEVEL=3D
g++ -c -g -Wall -I/usr/local/ssl/include -I/usr/sfw/include -I. -Ilib
 -o afflib.o afflib.cpp
afflib.cpp: In function `AFFILE* af_open_with(const char*, int, int,
af_vnode*)':
afflib.cpp:152: error: `warnx' undeclared (first use this function)
afflib.cpp:152: error: (Each undeclared identifier is reported only
once for each function it appears in.)
make: *** [afflib.o] Error 1
make: *** [no-perl] Error 2

Any idea what I am missing?  I swear I was able to compile version
2.03 on the same system.

Thanks!

Re: [sleuthkit-users] Error when running 2.04

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

They aren't critical errors and I will fix it so that they are not =20
displayed.  I changed the error handling in 2.04, which resulted in =20
new error messages and reporting.  That message is displayed when a =20
deleted file is found that can't be recovered.

thanks,
brian


On May 12, 2006, at 2:54 PM, Jennifer Smith wrote:

> When I run sorter in sleuthkit 2.04 on a FAT32 image, I am =20
> receiving odd errors that I didn't get when I ran the exact same =20
> command in v. 2.03 (from the 2.03 folder) - can someone help me =20
> figure out what I need to fix?  I looked through the change notes =20
> and the website, but I didn't see anything resembling this problem =20
> (sorry if it's there and I missed it - some of the notes are above =20
> my level of knowledge.)
>
> I am running the following command (in /path/sleuthkit-2.04/):
>
> ./bin/sorter -d /localdata/practice/TEST_G/sorterG -f fat -o 63 -x /=20=

> localdata/NSRL/known_good/goodfiles.txt -s /localdata/=20
> forensic_tools/images/fat32image.dd\
>
> and I receive the following output:
>
> Analyzing  "/localdata/forensic_tools/images/fat32image.dd"
>   Loading Allocated File Listing
>   Processing 34 Allocated Files and Directories
>   General file system error (Starting cluster of deleted file is =20
> allocated)
> General file system error (Starting cluster of deleted file is =20
> allocated)
> General file system error (Starting cluster of deleted file is =20
> allocated)
> General file system error (Starting cluster of deleted file is =20
> allocated)
> General file system error (Starting cluster of deleted file is =20
> allocated)
> General file system error (Starting cluster of deleted file is =20
> allocated)
> General file system error (Starting cluster of deleted file is =20
> allocated)
> 100%
>
>   Loading Unallocated File Listing
>   Processing 11 Unallocated meta-data structures
>   General file system error (Starting cluster of deleted file is =20
> allocated)
> General file system error (Starting cluster of deleted file is =20
> allocated)
> General file system error (Starting cluster of deleted file is =20
> allocated)
> General file system error (Starting cluster of deleted file is =20
> allocated)
> General file system error (Starting cluster of deleted file is =20
> allocated)
> General file system error (Starting cluster of deleted file is =20
> allocated)
> 100%
>
> All files have been saved to: /localdata/practice/TEST_G/sorterG
>
> Thanks in advance for any help you can give...
>
> -gg
>
>
> --=20
> _______________________________________________
> Check out the latest SMS services @ http://www.linuxmail.org
> This allows you to send and receive SMS through your mailbox.
>
> Powered by Outblaze
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, =20
> security?
> Get stuff done quickly with pre-integrated technology to make your =20
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache =20
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=120709&bid&3057&dat=121642=

> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

[sleuthkit-users] sleuthkit-2.04 compilation errors

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

When I run 'make' it goes to src/auxtools and finishes that with some
non-critical errors:
cd src/auxtools; make "CC=3Dgcc" MAKELEVEL=3D
gcc -DCYGWIN -DVER=3D\"2.04\" -O -Wall -g   -c -o mymalloc.o mymalloc.c
gcc -DCYGWIN -DVER=3D\"2.04\" -O -Wall -g   -c -o strerror.o strerror.c
gcc -DCYGWIN -DVER=3D\"2.04\" -O -Wall -g   -c -o split_at.o split_at.c
gcc -DCYGWIN -DVER=3D\"2.04\" -O -Wall -g   -c -o tsk_endian.o tsk_endian.c
gcc -DCYGWIN -DVER=3D\"2.04\" -O -Wall -g   -c -o unicode.o unicode.c
gcc -DCYGWIN -DVER=3D\"2.04\" -O -Wall -g   -c -o data_buf.o data_buf.c
gcc -DCYGWIN -DVER=3D\"2.04\" -O -Wall -g   -c -o tsk_version.o tsk_version=
.c
gcc -DCYGWIN -DVER=3D\"2.04\" -O -Wall -g   -c -o tsk_error.o tsk_error.c
tsk_error.c: In function `tsk_error_print':
tsk_error.c:99: warning: int format, long unsigned int arg (arg 3)
tsk_error.c:106: warning: int format, long unsigned int arg (arg 3)
tsk_error.c:112: warning: int format, long unsigned int arg (arg 3)
tsk_error.c:118: warning: int format, long unsigned int arg (arg 3)
tsk_error.c:121: warning: int format, uint32_t arg (arg 3)
gcc -DCYGWIN -DVER=3D\"2.04\" -O -Wall -g   -c -o tsk_parse.o tsk_parse.c
ar rv ../../lib/libauxtools.a mymalloc.o strerror.o split_at.o
tsk_endian.o unicode.o data_buf.o tsk_version.o tsk_error.o
tsk_parse.o
ar: creating ../../lib/libauxtools.a
a - mymalloc.o
a - strerror.o
a - split_at.o
a - tsk_endian.o
a - unicode.o
a - data_buf.o
a - tsk_version.o
a - tsk_error.o
a - tsk_parse.o
ranlib ../../lib/libauxtools.a

However, after it cds to src/afflib/lib, it get an error an exits:
cd src/auxtools; make "CC=3Dgcc" MAKELEVEL=3D
make: Nothing to be done for `all'.
cd src/afflib/lib; make "CC=3Dgcc" MAKELEVEL=3D
g++ -c -g -Wall -I/usr/local/ssl/include -I/usr/sfw/include -I. -Ilib
 -o afflib.o afflib.cpp
afflib.cpp: In function `AFFILE* af_open_with(const char*, int, int,
af_vnode*)':
afflib.cpp:152: error: `warnx' undeclared (first use this function)
afflib.cpp:152: error: (Each undeclared identifier is reported only
once for each function it appears in.)
make: *** [afflib.o] Error 1
make: *** [no-perl] Error 2

Any idea what I am missing?  I swear I was able to compile version
2.03 on the same system.

Thanks!

-Jason

[sleuthkit-users] Error when running 2.04

[Jennifer S. <g33...@li...>]

When I run sorter in sleuthkit 2.04 on a FAT32 image, I am receiving odd er=
rors that I didn't get when I ran the exact same command in v. 2.03 (from t=
he 2.03 folder) - can someone help me figure out what I need to fix?  I loo=
ked through the change notes and the website, but I didn't see anything res=
embling this problem (sorry if it's there and I missed it - some of the not=
es are above my level of knowledge.)

I am running the following command (in /path/sleuthkit-2.04/):

./bin/sorter -d /localdata/practice/TEST_G/sorterG -f fat -o 63 -x /localda=
ta/NSRL/known_good/goodfiles.txt -s /localdata/forensic_tools/images/fat32i=
mage.dd\

and I receive the following output:

Analyzing  "/localdata/forensic_tools/images/fat32image.dd"
  Loading Allocated File Listing
  Processing 34 Allocated Files and Directories
  General file system error (Starting cluster of deleted file is allocated)
General file system error (Starting cluster of deleted file is allocated)
General file system error (Starting cluster of deleted file is allocated)
General file system error (Starting cluster of deleted file is allocated)
General file system error (Starting cluster of deleted file is allocated)
General file system error (Starting cluster of deleted file is allocated)
General file system error (Starting cluster of deleted file is allocated)
100%

  Loading Unallocated File Listing
  Processing 11 Unallocated meta-data structures
  General file system error (Starting cluster of deleted file is allocated)
General file system error (Starting cluster of deleted file is allocated)
General file system error (Starting cluster of deleted file is allocated)
General file system error (Starting cluster of deleted file is allocated)
General file system error (Starting cluster of deleted file is allocated)
General file system error (Starting cluster of deleted file is allocated)
100%

All files have been saved to: /localdata/practice/TEST_G/sorterG

Thanks in advance for any help you can give...

-gg


--=20
_______________________________________________
Check out the latest SMS services @ http://www.linuxmail.org
This allows you to send and receive SMS through your mailbox.

Powered by Outblaze