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

[sleuthkit-users] Obtain court decision

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

Dear list,

I realize this may be a bit off-topic, but I was wondering if anyone could
give me advice on how to obtain a court decision in the US.

The decision in the case of Pennsylvania vs. Kevin Brian Dowling (see link
below) is interesting because it featured analysis of a video with
timestamps pertaining to (allegedly) a maladjusted clock. 

I was wondering if anyone could give me advice on how to obtain the original
decision in this case, which was made in 1998.

http://www.iippi.org/inmates/pennsylvania/kevinbriandowling.html

Regards,

Svein Willassen
--
Researcher, Norwegian University of Science and Technology

Re: [sleuthkit-users] DD images for sun

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

Good call!

ROBERT C. CIPRIANI
1LT, SC, FLARNG
Operations Officer, A/146TH ESB
"VOICE OF COMMAND"
H:(813) 349-6879
W:(727) 329-2000 x74264
M:(727) 365-1231

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

----- Original Message -----
From: farmer dude <far...@ya...>
Date: Friday, January 26, 2007 3:47 pm
Subject: Re: [sleuthkit-users] DD images for sun

> --- rob...@us... wrote:
> > You might need: -t ufs
> > 
> > Linux *should* support reading UFS without any
> > additional work needed.
> > 
> 
> Depending upon your Linux system you _may_ need to
> pass another option to your 'mount' command, and that
> is of the UFS type.  'mount' defaults to the "old" UFS
> type if you do not specify the type.  'man mount' is
> your friend, and specifically you most likely may pass
> "ufstype=sun" for UFS initialized by SunOS or Solaris
> on the Sparc platform or "ufstype=sunx86" for the same
> but on Intel architecture.  
> 
> 
> > --- Bri...@kp... wrote:
> > > They are straight DD images of each partition of  
> > the
> > drive copied accross 
> > the network. 
> 
> Can you elaborate?  Take each drive and share
> verbosely what you did, and command syntax if you
> remember.  This would allow everyone to help much
> faster and minimize the speculation that results from
> lack of knowledge about variables.
> 
> 
> 
> > I am using autopsy to perform the
> > analysis, but it does not 
> > appear to be able to ascertaing the file system...
> 
> Have you substantiated this with any other forensic
> program, be it SMART, FTK, etc.?
> 
> 
> regards,
> 
> farmerdude
> 
> 
> 
> ____________________________________________________________________________________
> Food fight? Enjoy some healthy debate 
> in the Yahoo! Answers Food & Drink Q&A.
> http://answers.yahoo.com/dir/?link=list&sid=396545367
> 
> -------------------------------------------------------------------
> ------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to 
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
> 

Re: [sleuthkit-users] DD images for sun

[farmer d. <far...@ya...>]

--- rob...@us... wrote:
> You might need: -t ufs
> 
> Linux *should* support reading UFS without any
> additional work needed.
> 

Depending upon your Linux system you _may_ need to
pass another option to your 'mount' command, and that
is of the UFS type.  'mount' defaults to the "old" UFS
type if you do not specify the type.  'man mount' is
your friend, and specifically you most likely may pass
"ufstype=sun" for UFS initialized by SunOS or Solaris
on the Sparc platform or "ufstype=sunx86" for the same
but on Intel architecture.  


> --- Bri...@kp... wrote:
> > They are straight DD images of each partition of  
> the
> drive copied accross 
> the network. 

Can you elaborate?  Take each drive and share
verbosely what you did, and command syntax if you
remember.  This would allow everyone to help much
faster and minimize the speculation that results from
lack of knowledge about variables.



> I am using autopsy to perform the
> analysis, but it does not 
> appear to be able to ascertaing the file system...

Have you substantiated this with any other forensic
program, be it SMART, FTK, etc.?


regards,

farmerdude


 
____________________________________________________________________________________
Food fight? Enjoy some healthy debate 
in the Yahoo! Answers Food & Drink Q&A.
http://answers.yahoo.com/dir/?link=list&sid=396545367

Re: [sleuthkit-users] DD images for sun

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

Have you tried mounting the images (or a safe copy of them!)?

mount -o loop my_image /mymountpoint

You might need: -t ufs

Linux *should* support reading UFS without any additional work needed.

It's possible to mount filesystems from within an entire disk image too, you just have to specify the offset.

I hope this is what you're asking.  mhdd should give some clues too if you're not sure it's UFS.



ROBERT C. CIPRIANI
1LT, SC, FLARNG
Operations Officer, A/146TH ESB
"VOICE OF COMMAND"
H:(813) 349-6879
W:(727) 329-2000 x74264
M:(727) 365-1231

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

Re: [sleuthkit-users] DD images for sun

[<Bri...@kp...>]

They are straight DD images of each partition of the drive copied accross 
the network. I am using autopsy to perform the analysis, but it does not 
appear to be able to ascertaing the file system... just able to keyword 
search, checksums and the like. And no, this is not a critical situation - 
- - just exploratory on some strage events on the server. Just never had 
this happen before. 



NOTICE TO RECIPIENT:  If you are not the intended recipient of this 
e-mail, you are prohibited from sharing, copying, or otherwise using or 
disclosing its contents.  If you have received this e-mail in error, 
please notify the sender immediately by reply e-mail and permanently 
delete this e-mail and any attachments without reading, forwarding or 
saving them.  Thank you.




farmer dude <far...@ya...> 
01/25/2007 06:45 PM

To
Brian Hanson/PO/KAIPERM@Kaiperm, sle...@li...
cc

Subject
Re: [sleuthkit-users] DD images for sun






--- Bri...@kp... wrote:

> I have acquired my DD images from a SUN server...

May we know how you made your acquisition?  Also, are
these physical images (of each disk in the server) or
logical images (of each partition/file system/slice)?



> however I am only able 
> to perform keyword searches... no data analysis. 

Why is this so?  Are you limited by the tool(s) you're
using or you cannot mount the file system to view
logical structure and active files?


> I
> have never performed 
> analysis on Sun - - - so I am kind of at a loss
> here. 

This is not for a real case, or anything important,
then, is it?  ;)


> Anyone know what I 
> can do in order to access the file system, time
> sequencing, etc?

You obviously don't need to mount a file system to
analyze the contents.  Mounting it may make it easier
to view and see things, though.

What is the disk layout and the file system type(s)
for each slice/partition?

You will need to specify the ufs type to Linux mount
command.  You could use SMART for Linux as well. 
Finally, there is my CD, THE FARMER'S BOOT CD.  I know
each of these supports UFS types and enable you to
mount Sun file systems. 

regards,

farmerdude


 
____________________________________________________________________________________
Yahoo! Music Unlimited
Access over 1 million songs.
http://music.yahoo.com/unlimited

Re: [sleuthkit-users] DD images for sun

[farmer d. <far...@ya...>]

--- Bri...@kp... wrote:

> I have acquired my DD images from a SUN server...

May we know how you made your acquisition?  Also, are
these physical images (of each disk in the server) or
logical images (of each partition/file system/slice)?



> however I am only able 
> to perform keyword searches... no data analysis. 

Why is this so?  Are you limited by the tool(s) you're
using or you cannot mount the file system to view
logical structure and active files?


> I
> have never performed 
> analysis on Sun - - - so I am kind of at a loss
> here. 

This is not for a real case, or anything important,
then, is it?  ;)


> Anyone know what I 
> can do in order to access the file system, time
> sequencing, etc?

You obviously don't need to mount a file system to
analyze the contents.  Mounting it may make it easier
to view and see things, though.

What is the disk layout and the file system type(s)
for each slice/partition?

You will need to specify the ufs type to Linux mount
command.  You could use SMART for Linux as well. 
Finally, there is my CD, THE FARMER'S BOOT CD.  I know
each of these supports UFS types and enable you to
mount Sun file systems.  

regards,

farmerdude


 
____________________________________________________________________________________
Yahoo! Music Unlimited
Access over 1 million songs.
http://music.yahoo.com/unlimited

Re: [sleuthkit-users] DD images for sun

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

Do you have dd's of an entire disk or just one filesystem? 

 

  _____  

From: sle...@li...
[mailto:sle...@li...] On Behalf Of
Bri...@kp...
Sent: Wednesday, January 24, 2007 5:10 PM
To: sle...@li...
Subject: [sleuthkit-users] DD images for sun

 


I have acquired my DD images from a SUN server... however I am only able to
perform keyword searches... no data analysis. I have never performed
analysis on Sun - - - so I am kind of at a loss here. Anyone know what I can
do in order to access the file system, time sequencing, etc? Keywords is all
I can get and that is enabled in Autopsy.



NOTICE TO RECIPIENT:  If you are not the intended recipient of this e-mail,
you are prohibited from sharing, copying, or otherwise using or disclosing
its contents.  If you have received this e-mail in error, please notify the
sender immediately by reply e-mail and permanently delete this e-mail and
any attachments without reading, forwarding or saving them.  Thank you.

[sleuthkit-users] DD images for sun

[<Bri...@kp...>]

I have acquired my DD images from a SUN server... however I am only able 
to perform keyword searches... no data analysis. I have never performed 
analysis on Sun - - - so I am kind of at a loss here. Anyone know what I 
can do in order to access the file system, time sequencing, etc? Keywords 
is all I can get and that is enabled in Autopsy.



NOTICE TO RECIPIENT:  If you are not the intended recipient of this 
e-mail, you are prohibited from sharing, copying, or otherwise using or 
disclosing its contents.  If you have received this e-mail in error, 
please notify the sender immediately by reply e-mail and permanently 
delete this e-mail and any attachments without reading, forwarding or 
saving them.  Thank you.

Re: [sleuthkit-users] autopsy opens socket with INADDR_ANY

[Dr. M. W. <wa...@gm...>]

Hello Tim,



> My personal preference is in line with Dr. Waldeck's.  It would be

> nice if the default was to listen only on localhost.



Fine!



> > +  bind(Server, sockaddr_in($port, $binary))

> 

> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> However, I think you might want to check the return value of this bind()

> call, just in case the localhost port is already taken.



Sorry, copy and WASTE!



I checked the patch and decided to avoid code duplication.



--- autopsy	2007-01-24 09:44:26.000000000 +0100

+++ autopsy_patched	2007-01-24 09:44:12.000000000 +0100

@@ -334,7 +334,12 @@

 setsockopt(Server, SOL_SOCKET, SO_KEEPALIVE, 1)

   or die "Error setting network socket options (keep alive): $!";

 

-bind(Server, sockaddr_in($port, INADDR_ANY))

+my $bindaddr = INADDR_ANY;

+

+if ($rema eq "localhost") {

+  $bindaddr = inet_aton('127.0.0.1');

+}

+bind(Server, sockaddr_in($port, $bindaddr))

   or die "Error binding to port $port (is Autopsy already running?): $!";

 

 listen(Server, SOMAXCONN)



Thanks



Dr. Markus Waldeck



-- 

"Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ...
Jetzt GMX ProMail testen: http://www.gmx.net/de/go/promail

Re: [sleuthkit-users] autopsy opens socket with INADDR_ANY

[Tim <tim...@se...>]

Hello,

> due to the missing SSL support I use autopsy only on the localhost.
>
> I notived that even in this case port 9999 is opened on every
interface.
>
> I wrote a small patch for autopsy 2.08 to fix this behavior if no
remote address is specified.


My personal preference is in line with Dr. Waldeck's.  It would be
nice if the default was to listen only on localhost.



> --- autopsy     2007-01-23 16:07:09.000000000 +0100
> +++ autopsy_patched     2007-01-23 16:06:21.000000000 +0100
> @@ -334,8 +334,15 @@
>  setsockopt(Server, SOL_SOCKET, SO_KEEPALIVE, 1)
>    or die "Error setting network socket options (keep alive): $!";
>
> -bind(Server, sockaddr_in($port, INADDR_ANY))
> -  or die "Error binding to port $port (is Autopsy already running?): $!";
> +if ($rema eq "localhost") {
> +  my $ip = '127.0.0.1';
> +  my $binary = inet_aton($ip);
> +  bind(Server, sockaddr_in($port, $binary))

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
However, I think you might want to check the return value of this bind()
call, just in case the localhost port is already taken.



> +}
> +else {
> +  bind(Server, sockaddr_in($port, INADDR_ANY))
> +    or die "Error binding to port $port (is Autopsy already running?): $!";
> +}



tim

[sleuthkit-users] autopsy opens socket with INADDR_ANY

[Dr. M. W. <wa...@gm...>]

Hi,

due to the missing SSL support I use autopsy only on the localhost.

I notived that even in this case port 9999 is opened on every interface.

I wrote a small patch for autopsy 2.08 to fix this behavior if no remote address is specified.

--- autopsy     2007-01-23 16:07:09.000000000 +0100
+++ autopsy_patched     2007-01-23 16:06:21.000000000 +0100
@@ -334,8 +334,15 @@
 setsockopt(Server, SOL_SOCKET, SO_KEEPALIVE, 1)
   or die "Error setting network socket options (keep alive): $!";
 
-bind(Server, sockaddr_in($port, INADDR_ANY))
-  or die "Error binding to port $port (is Autopsy already running?): $!";
+if ($rema eq "localhost") {
+  my $ip = '127.0.0.1';
+  my $binary = inet_aton($ip);
+  bind(Server, sockaddr_in($port, $binary))
+}
+else {
+  bind(Server, sockaddr_in($port, INADDR_ANY))
+    or die "Error binding to port $port (is Autopsy already running?): $!";
+}
 
 listen(Server, SOMAXCONN)
   or die "Error listening to socket for connections: $!";

Thanks!

Dr. Markus Waldeck

-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

[sleuthkit-users] Undelete

[Zach A. <and...@gm...>]

I'm not quite sure if I'm reading the description pages correctly or not, so
I thought I'd post a question here.  I've committed a cardinal sin by
somehow accidentally running a rm -r on our entire repository running on a
Solaris 8 Blade server.  I have isolated the disk and have tried running a
couple of recovery programs with not much luck.  It's on a ufs partition and
we have loaded tct on another partition and have successfully retrieved a
"unrm" dump.  Now my question is, can SleuthKit and Autopsy help me to
retrieve and undelete these source files and more importantly the version
history ,the ",v" files?   I think I've finally learned my lesson and from
this moment forward in my career, it's backup, backup, backup no matter how
small or large.

Thanks,

Zach

[sleuthkit-users] AFFLIB 2.0a23 released

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

I'm pleased to announce that AFFLIB 2.0a23 is now released. The big 
difference between this version of AFFLIB and previous versions is that I'm 
checking for more functions and #include files in the "autoconf" script, so 
AFFLIB and all of the AFF tools now properly compile under Cygwin.

Re: [sleuthkit-users] afflib problems

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

Hi, Jason. Sorry that you are continuing to have problems.  
Maintaining software that compiles on the 1000-or-so different  
versions of Linux out there, including the versions of Linux that are  
hosted under Windows, is proving to be quite a challenge.

It appears that your Cygwin installation includes a definition for  
err.h, even though many versions do not. It is a flaw in the  
configuration script that we are not picking this up. In the  
meantime, you might try commenting out the definition of errx and err  
on line  137 and 138 of afflib_i.h. Please send your response to me  
directly and not to the list. In the meantime, I will prepare a new  
version of afflib that deals with this.

-Simson


On Jan 11, 2007, at 11:41 AM, DePriest, Jason R. wrote:

> On 1/11/07, Simson Garfinkel  wrote:
>> Hi, Jason.
>>
>> The newest version of AFFLIB handles this problem. The problem, of
>> course, is that warn() isn't present in Cygwin because they are
>> modeling the Linux environment, rather than the FreeBSD environment
>> on which AFFLIB was developed.
>>
>> You can simply add this define:
>>
>> #define warn printf
>>
>> Alternatively, you should just comment out the offending lines, since
>> the warnings are just error messages for afconvert, which you won't
>> be using.
>>
>> The Configure script should have picked this up. I'm sorry that it
>> didn't. I'll need to set up a Cygwin machine to do better validation
>> on that platform for the next release.
>>
>> -Simson
>>
>>
>
> Thanks!  That worked for those errors, but now I get this:
>
> $ make all
> make  all-recursive
> make[1]: Entering directory `/cygdrive/c/Documents and
> Settings/USER/afflib-2.0a15'
> Making all in lib
> make[2]: Entering directory `/cygdrive/c/Documents and
> Settings/USER/afflib-2.0a15/lib'
> make[2]: Nothing to be done for `all'.
> make[2]: Leaving directory `/cygdrive/c/Documents and
> Settings/USER/afflib-2.0a15/lib'
> Making all in tools
> make[2]: Entering directory `/cygdrive/c/Documents and
> Settings/USER/afflib-2.0a15/tools'
> if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../lib/    -g -O2 -MT afinfo.o
> -MD -MP -MF ".deps/afinfo.Tpo" -c -o afinfo.o afinfo.cpp; \
>        then mv -f ".deps/afinfo.Tpo" ".deps/afinfo.Po"; else rm -f
> ".deps/afinfo.Tpo"; exit 1; fi
> if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../lib/    -g -O2 -MT quads.o
> -MD -MP -MF ".deps/quads.Tpo" -c -o quads.o quads.cpp; \
>        then mv -f ".deps/quads.Tpo" ".deps/quads.Po"; else rm -f
> ".deps/quads.Tpo"; exit 1; fi
> g++  -g -O2  -L/usr/lib -lcurl -L/usr/lib -lssl -lcrypto -lz  -o
> afinfo.exe  afinfo.o quads.o ../lib/libafflib.a -lexpat -lcurl
> -lcrypto -lssl -lz -lncurses -lreadline
> if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../lib/    -g -O2 -MT
> afsegment.o -MD -MP -MF ".deps/afsegment.Tpo" -c -o afsegment.o
> afsegment.cpp; \
>        then mv -f ".deps/afsegment.Tpo" ".deps/afsegment.Po"; else rm
> -f ".deps/afsegment.Tpo"; exit 1; fi
> In file included from afsegment.cpp:55:
> ../lib/afflib_i.h:137: error: previous declaration of `void err(int,
> const char*, ...)' with C++ linkage
> /usr/include/err.h:22: error: conflicts with new declaration with C  
> linkage
> ../lib/afflib_i.h:138: error: previous declaration of `void errx(int,
> const char*, ...)' with C++ linkage
> /usr/include/err.h:23: error: conflicts with new declaration with C  
> linkage
> make[2]: *** [afsegment.o] Error 1
> make[2]: Leaving directory `/cygdrive/c/Documents and
> Settings/USER/afflib-2.0a15/tools'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/cygdrive/c/Documents and
> Settings/USER/afflib-2.0a15'
> make: *** [all] Error 2
>

Re: [sleuthkit-users] afflib problems

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

On 1/11/07, Simson Garfinkel  wrote:
> Hi, Jason.
>
> The newest version of AFFLIB handles this problem. The problem, of
> course, is that warn() isn't present in Cygwin because they are
> modeling the Linux environment, rather than the FreeBSD environment
> on which AFFLIB was developed.
>
> You can simply add this define:
>
> #define warn printf
>
> Alternatively, you should just comment out the offending lines, since
> the warnings are just error messages for afconvert, which you won't
> be using.
>
> The Configure script should have picked this up. I'm sorry that it
> didn't. I'll need to set up a Cygwin machine to do better validation
> on that platform for the next release.
>
> -Simson
>
>

Thanks!  That worked for those errors, but now I get this:

$ make all
make  all-recursive
make[1]: Entering directory `/cygdrive/c/Documents and
Settings/USER/afflib-2.0a15'
Making all in lib
make[2]: Entering directory `/cygdrive/c/Documents and
Settings/USER/afflib-2.0a15/lib'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/cygdrive/c/Documents and
Settings/USER/afflib-2.0a15/lib'
Making all in tools
make[2]: Entering directory `/cygdrive/c/Documents and
Settings/USER/afflib-2.0a15/tools'
if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../lib/    -g -O2 -MT afinfo.o
-MD -MP -MF ".deps/afinfo.Tpo" -c -o afinfo.o afinfo.cpp; \
        then mv -f ".deps/afinfo.Tpo" ".deps/afinfo.Po"; else rm -f
".deps/afinfo.Tpo"; exit 1; fi
if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../lib/    -g -O2 -MT quads.o
-MD -MP -MF ".deps/quads.Tpo" -c -o quads.o quads.cpp; \
        then mv -f ".deps/quads.Tpo" ".deps/quads.Po"; else rm -f
".deps/quads.Tpo"; exit 1; fi
g++  -g -O2  -L/usr/lib -lcurl -L/usr/lib -lssl -lcrypto -lz  -o
afinfo.exe  afinfo.o quads.o ../lib/libafflib.a -lexpat -lcurl
-lcrypto -lssl -lz -lncurses -lreadline
if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../lib/    -g -O2 -MT
afsegment.o -MD -MP -MF ".deps/afsegment.Tpo" -c -o afsegment.o
afsegment.cpp; \
        then mv -f ".deps/afsegment.Tpo" ".deps/afsegment.Po"; else rm
-f ".deps/afsegment.Tpo"; exit 1; fi
In file included from afsegment.cpp:55:
../lib/afflib_i.h:137: error: previous declaration of `void err(int,
const char*, ...)' with C++ linkage
/usr/include/err.h:22: error: conflicts with new declaration with C linkage
../lib/afflib_i.h:138: error: previous declaration of `void errx(int,
const char*, ...)' with C++ linkage
/usr/include/err.h:23: error: conflicts with new declaration with C linkage
make[2]: *** [afsegment.o] Error 1
make[2]: Leaving directory `/cygdrive/c/Documents and
Settings/USER/afflib-2.0a15/tools'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/cygdrive/c/Documents and
Settings/USER/afflib-2.0a15'
make: *** [all] Error 2

Re: [sleuthkit-users] afflib problems

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

Hi, Jason.

The newest version of AFFLIB handles this problem. The problem, of  
course, is that warn() isn't present in Cygwin because they are  
modeling the Linux environment, rather than the FreeBSD environment  
on which AFFLIB was developed.

You can simply add this define:

#define warn printf

Alternatively, you should just comment out the offending lines, since  
the warnings are just error messages for afconvert, which you won't  
be using.

The Configure script should have picked this up. I'm sorry that it  
didn't. I'll need to set up a Cygwin machine to do better validation  
on that platform for the next release.

-Simson


On Jan 10, 2007, at 7:29 PM, DePriest, Jason R. wrote:

> I know this isn't a newsgroup for afflib, but I figured someone here
> would have an answer.
>
> I run Sleuthkit on Cygwin on a Windows 2003 Server.
>
> The afflib bits that are included with TSK compiled after I changed a
> valloc reference to malloc.
>
> I downloaded the source code for afflib separately because I wanted to
> get at the tools to convert dd images to aff images.
>
> I cannot get the thing to finish compiling.
>
> I had to make the same valloc to malloc change (I am using the  
> 2.0a15 release).
>
> The configure script runs fine, but make fails when it gets to
> afconvert with this:
>
> USER@hostname ~/afflib-2.0a15
> $ make
> make  all-recursive
> make[1]: Entering directory `/cygdrive/c/Documents and
> Settings/USER/afflib-2.0a15'
> Making all in lib
> make[2]: Entering directory `/cygdrive/c/Documents and
> Settings/USER/afflib-2.0a15/lib'
> make[2]: Nothing to be done for `all'.
> make[2]: Leaving directory `/cygdrive/c/Documents and
> Settings/USER/afflib-2.0a15/lib'
> Making all in tools
> make[2]: Entering directory `/cygdrive/c/Documents and
> Settings/USER/afflib-2.0a15/tools'
> if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../lib/    -g -O2 -MT
> afconvert.o -MD -MP -MF ".deps/afconvert.Tpo" -c -o afconvert.o
> afconvert.cpp; \
>         then mv -f ".deps/afconvert.Tpo" ".deps/afconvert.Po"; else rm
> -f ".deps/afconvert.Tpo"; exit 1; fi
> afconvert.cpp: In function `int convert(const char*, char*)':
> afconvert.cpp:386: error: `warn' undeclared (first use this function)
> afconvert.cpp:386: error: (Each undeclared identifier is reported only
> once for each function it appears in.)
> make[2]: *** [afconvert.o] Error 1
> make[2]: Leaving directory `/cygdrive/c/Documents and
> Settings/USER/afflib-2.0a15/tools'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/cygdrive/c/Documents and
> Settings/USER/afflib-2.0a15'
> make: *** [all] Error 2
>
> Any fantastic ideas?
>
> -Jason
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>

[sleuthkit-users] afflib problems

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

I know this isn't a newsgroup for afflib, but I figured someone here
would have an answer.

I run Sleuthkit on Cygwin on a Windows 2003 Server.

The afflib bits that are included with TSK compiled after I changed a
valloc reference to malloc.

I downloaded the source code for afflib separately because I wanted to
get at the tools to convert dd images to aff images.

I cannot get the thing to finish compiling.

I had to make the same valloc to malloc change (I am using the 2.0a15 release).

The configure script runs fine, but make fails when it gets to
afconvert with this:

USER@hostname ~/afflib-2.0a15
$ make
make  all-recursive
make[1]: Entering directory `/cygdrive/c/Documents and
Settings/USER/afflib-2.0a15'
Making all in lib
make[2]: Entering directory `/cygdrive/c/Documents and
Settings/USER/afflib-2.0a15/lib'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/cygdrive/c/Documents and
Settings/USER/afflib-2.0a15/lib'
Making all in tools
make[2]: Entering directory `/cygdrive/c/Documents and
Settings/USER/afflib-2.0a15/tools'
if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../lib/    -g -O2 -MT
afconvert.o -MD -MP -MF ".deps/afconvert.Tpo" -c -o afconvert.o
afconvert.cpp; \
        then mv -f ".deps/afconvert.Tpo" ".deps/afconvert.Po"; else rm
-f ".deps/afconvert.Tpo"; exit 1; fi
afconvert.cpp: In function `int convert(const char*, char*)':
afconvert.cpp:386: error: `warn' undeclared (first use this function)
afconvert.cpp:386: error: (Each undeclared identifier is reported only
once for each function it appears in.)
make[2]: *** [afconvert.o] Error 1
make[2]: Leaving directory `/cygdrive/c/Documents and
Settings/USER/afflib-2.0a15/tools'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/cygdrive/c/Documents and
Settings/USER/afflib-2.0a15'
make: *** [all] Error 2

Any fantastic ideas?

-Jason

Re: [sleuthkit-users] analyze compressed image

[Gargac. J. <jg...@ma...>]

Jean-Francois,

You hit the nail on the head.  Thanks for the helpful information. =20

Jeff=20

-----Original Message-----
From: jfb fccu [mailto:jfb...@gm...]=20
Sent: Monday, January 08, 2007 12:18 AM
To: Gargac. Jeff
Cc: sle...@li...
Subject: Re: [sleuthkit-users] analyze compressed image

Hi Jeff,

> I'm looking for information to see if Sleuthkit/Autopsy can analyze a=20
> dd image that has been compressed with either tar or gzip.  I've=20
> attempted this with a floppy disk and Autopsy was unable to import the

> image.  Am I doing something wrong?  I've searched the mailing list=20
> archive, but haven't found any messages concerning this.

It's not possible to use dd.gz or tar images with sleuthkit/autopsy.
You need to work with a RAW non-compressed image.

> Secondly, is there a different way to
> compress the image so that Sleuthkit/Autopsy can interpret it but=20
> still use a raw or open format?  Thanks,

You can work with AFF images. It will compress the images and it's
supported by Sleuthkit/Autopsy. The format is open and the image
structure is described on the AFF website - http://www.afflib.org . At
this time, Sleuthkit is the only forensic software supporting this image
format.

Aff tools allow you to acquire a image from a device or convert a 'raw
image' to a aff one. The image is compressed and contain meta-data such
as md5, sha1, ...

Sleuthkit/Autopsy also support EnCase (E01) images with the use of
LibEWF. This format is not open. The images are also compressed and
contain meta-data. LibEWF provide tools to acquire image from a device
or convert a 'raw' one. This format is normally recognized by commercial
softwares.

Regards.
--
Jean-Francois BECKERS

Re: [sleuthkit-users] analyze compressed image

[jfb f. <jfb...@gm...>]

Hi Jeff,

> I'm looking for information to see if Sleuthkit/Autopsy can analyze a dd
> image that has been compressed with either tar or gzip.  I've attempted this
> with a floppy disk and Autopsy was unable to import the image.  Am I doing
> something wrong?  I've searched the mailing list archive, but haven't found
> any messages concerning this.

It's not possible to use dd.gz or tar images with sleuthkit/autopsy.
You need to work with a RAW non-compressed image.

> Secondly, is there a different way to
> compress the image so that Sleuthkit/Autopsy can interpret it but still use
> a raw or open format?  Thanks,

You can work with AFF images. It will compress the images and it's
supported by Sleuthkit/Autopsy. The format is open and the image
structure is described on the AFF
website - http://www.afflib.org . At this time, Sleuthkit is the only
forensic software supporting this image format.

Aff tools allow you to acquire a image from a device or convert a 'raw
image' to a aff one. The image is compressed and contain meta-data
such as md5, sha1, ...

Sleuthkit/Autopsy also support EnCase (E01) images with the use of
LibEWF. This format is not open. The images are also compressed and
contain meta-data. LibEWF provide tools to acquire image from a device
or convert a 'raw' one. This format is normally recognized by
commercial softwares.

Regards.
-- 
Jean-Francois BECKERS

[sleuthkit-users] analyze compressed image

[Gargac. J. <jg...@ma...>]

Hi all,
=20
I'm looking for information to see if Sleuthkit/Autopsy can analyze a dd
image that has been compressed with either tar or gzip.  I've attempted
this with a floppy disk and Autopsy was unable to import the image.  Am
I doing something wrong?  I've searched the mailing list archive, but
haven't found any messages concerning this.  Secondly, is there a
different way to compress the image so that Sleuthkit/Autopsy can
interpret it but still use a raw or open format?  Thanks,
=20
Jeff

[sleuthkit-users] restoring a mac osx hd

[vattini g. <ha...@ya...>]

hi there,i had some problem with my powerbook at the boot time,being in warrenty i send it back to the factory saying to not touch the hd cause i had many thing inside  that i would like to keep,pwd program and info.Having back the laptop they said to me that they installed back MACOSX what a damm....
i had to buy an external disk of 250gb firewire.I made an image of the hd of the powerbook,to the external hd.What do i have to do now on?which steps do i need to do to restore most of my old 40gb before reinstallation?thanks very much for helping me

 __________________________________________________
Do You Yahoo!?
Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi 
http://mail.yahoo.it 

Re: [sleuthkit-users] Identifying Encrypted Files

[Wyman M. <wm...@co...>]

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

I've been struggling with this for a while.  NTFS encrypted files bear that 
attribute, as do encrypted files on certain other filesystems.

Virtually everything else is an internal tag.

Certain encrypted volume tools like Truecrypt studiously avoid any 
indication of their purpose, so you'd be left looking at a large block of 
data.

I've written a few things to perform tests of randomness of arbitrary 
files, on the assumption that anything strongly encrypted is going to be 
extremely random -- even more so than compressed data.  It's slow going and 
not generally useful, though.

- --On Tuesday, December 19, 2006 12:54 PM -0500 Craig Slusher 
<cs...@gm...> wrote:

> Hello, I am a new user of the Sleuthkit and am very pleased so far
> with the results. I am curious though, are there ways to identify if a
> file is encrypted or password protected? I don't necessarily need to
> do anything other than identify that it has been encrypted. Any help
> would be greaty appreciated. Thank you!
>
> --
> Craig Slusher
> cs...@gm...
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your opinions on IT & business topics through brief surveys - and earn
> cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org



Wyman Miles
Senior Security Engineer
Cornell University, Ithaca, NY
(607) 255-8421
-----BEGIN PGP SIGNATURE-----
Version: Mulberry PGP Plugin v3.0
Comment: processed by Mulberry PGP Plugin

iQA/AwUBRYgqXsRE6QfTb3V0EQKtDwCdGxhAvHx5qzN7c3WspC7uaDe+bCYAoN3h
X0TU8rGb7QDX9tSKcXyH0Rs9
=7IkV
-----END PGP SIGNATURE-----

[sleuthkit-users] Identifying Encrypted Files

[Craig S. <cs...@gm...>]

Hello, I am a new user of the Sleuthkit and am very pleased so far
with the results. I am curious though, are there ways to identify if a
file is encrypted or password protected? I don't necessarily need to
do anything other than identify that it has been encrypted. Any help
would be greaty appreciated. Thank you!

-- 
Craig Slusher
cs...@gm...

Re: [sleuthkit-users] problem compiling sleuthkit 2.07 on cygwin

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

On 12/18/06, Brian Carrier wrote:
> This was my fault.  The system I built the release file from did not
> have the afflib directory synced up with the lastest version.
>
> You can download the latest AFFLIB, open it, rename the directory to
> 'afflib', replace the existing src/afflib directory with it, and compile
> again.
>
> I'll do a new release at the end of the week.
>
> brian
>
> Simson Garfinkel wrote:
> > Hi. Cygwin is sometimes a problem. Here, in particular, the problem
> > is that valloc() is not part of cygwin, but it is part of most modern
> > Unix distributions.
> >
> > You can simply change "valloc" to "malloc" in line 542 of
> > afflib_pages.cpp to fix the problem.
> >
> > The new release of AFFLIB also fixes this problem. You can download
> > that from afflib.org.
> >
> > -Simson
> >

I did both.  I downloaded the new release and changed valloc to malloc.

It worked fine after that.

Thanks!

-Jason

Re: [sleuthkit-users] problem compiling sleuthkit 2.07 on cygwin

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

This was my fault.  The system I built the release file from did not 
have the afflib directory synced up with the lastest version.

You can download the latest AFFLIB, open it, rename the directory to 
'afflib', replace the existing src/afflib directory with it, and compile 
again.

I'll do a new release at the end of the week.

brian

Simson Garfinkel wrote:
> Hi. Cygwin is sometimes a problem. Here, in particular, the problem  
> is that valloc() is not part of cygwin, but it is part of most modern  
> Unix distributions.
> 
> You can simply change "valloc" to "malloc" in line 542 of  
> afflib_pages.cpp to fix the problem.
> 
> The new release of AFFLIB also fixes this problem. You can download  
> that from afflib.org.
> 
> -Simson
> 
> 
> 
> -Simson
> On Dec 17, 2006, at 4:17 AM, DePriest, Jason R. wrote:
> 
>> On 12/17/06, DePriest, Jason R.  wrote:
>>> I have been successfully running 2.06 on cygwin.
>>>
>>> I downloaded the source code for 2.07 and it will not compile.
>>>
>> Source code compiles just fine on a Debian GNU/Linux system.  Just
>> breaks on cygwin.
>>
>> Any other cygwin users having the same problem?
>>
>> -Jason
>>
>> ---------------------------------------------------------------------- 
>> ---
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to  
>> share your
>> opinions on IT & business topics through brief surveys - and earn cash
>> http://www.techsay.com/default.php? 
>> page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> sleuthkit-users mailing list
>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>> http://www.sleuthkit.org
>>
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org