sleuthkit-developers — A list to discuss development of new features of The Sleuth Kit and Autopsy

[sleuthkit-developers] small patch for 2.07

[David C. <da...@in...>]

Hi Brian,
Below is a small patch for 2.07. Without it fs_ifind_path will fail to
set result when looking up '/'. I'm not sure if this affects the normal
operation of sleuthkit/autopsy, but I hit it in pyflag!

diff -ruN sleuthkit-2.07/src/fstools/ifind_lib.c sleuthkit-2.07-dave/src/fstools/ifind_lib.c
--- sleuthkit-2.07/src/fstools/ifind_lib.c      2006-12-16 05:40:12.000000000 +1100
+++ sleuthkit-2.07-dave/src/fstools/ifind_lib.c 2006-12-18 01:02:07.691884250 +1100
@@ -303,6 +303,7 @@
 #ifdef TSK_WIN32
        free(cpath);
 #endif
+       *result = fs->root_inum;
        return 0;
     }

Thanks,
Dave

[sleuthkit-developers] Change in _walk flags

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

A note to developers that use the library and the _walk functions.  I  
changed the way that flags are handled in 2.07 so that the library  
does more sanity checking than it used to.  Previously, ils and such  
would make sure that one or both of _ALLOC and _UNALLOC were set.   
Now, the _walk functions will set both if neither are set.

There is also a new fs_read_file function that gives a read()  
interface to reading a file (instead of relying on file_walk).  It  
uses file_walk though and therefore is not as efficient as file_walk.

brian

Re: [sleuthkit-developers] ifind issue and library stuff.

[David C. <da...@in...>]

On Tue, Nov 28, 2006 at 09:13:36AM -0500, Brian Carrier wrote:
> >On the topic of fs_ifind_path, I wanted to use this funtionallity in
> >pyflag, but unfortunately if is very library unfriendly as it printf's
> >the inode rather than returning it. What I did was rename this  
> >function,
> >modify it to return the matched inum, and then wrote a small wrapper
> >version of fs_ifind_path which used the new function and printed the
> >result in order to maintain the API. I think there are other places
> >where this technique will be useful to me as I am writing a python
> >sleuthkit module (for pyflag) and wish to employ sk in a library
> >context. Would you me interested in patches for these changes? There
> >have already been some great changes to help lib'ise sk (for example
> >tsk_error stuff) I'd like to continue this effort.
> 
> Would it be easier if there was a callback design?

Forgot to answer this last time...

On the one hand a callback seems overkill, but on the other hand it's
the only way to return multiple records, so I guess that could be
useful.

Having said that, do we ever actually want to return multiple records? 

A given path can only have one directory entry on most filesystems
(either allocated or deleted/unused), or two on NTFS where the second is
an artifact of b-tree balancing and is 'unused'. (is this correct?)

So the function should work as follows I think:
1. if an allocated dent is found, return its inode
2. if a deleted/unused dent is found, keep looking for an allocated dent
with the same name (which can occur in NTFS as described above). If
found, return that, otherwise return the (former) inode or 0 (filesystem
dependant) from the deleted/unused dent.

There is little value in returning both inodes in the second case as
this only occurs in NTFS (AFAIK), and the inode number is always 0 for
the 'unused' entry anyway.

Does that make sense?

Dave

Re: [sleuthkit-developers] NTFS Compression bug solution

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

On Nov 29, 2006, at 2:28 AM, David Collett wrote:

> Hi Brian,
> I think I have tracked this down to the loop on line 1051 in ntfs.c.
> There is no bounds checking, and in my problem case it overflows the
> comp->uncomp_buf buffer. It does not abort immediately, but rather  
> when
> uncomp_buf is free'd, presumably because we have trashed malloc's
> metadata which I believe lives after the malloc'd buffer.
>
> Adding a check fixes this for me.


Interesting.  I previously added that check and added some more  
checks, but the result was that it would get into an infinite loop  
somewhere.  I'll recheck the other changes that I made to see if  
those are incorrect and causing the infinite loop problem.

thanks,
brian

Re: [sleuthkit-developers] NTFS Compression bug solution

[David C. <da...@in...>]

I meant to mention that I used valgrind to help track this down.

On Wed, Nov 29, 2006 at 06:28:20PM +1100, David Collett wrote:
> Hi Brian,
> I think I have tracked this down to the loop on line 1051 in ntfs.c.
> There is no bounds checking, and in my problem case it overflows the
> comp->uncomp_buf buffer. It does not abort immediately, but rather when
> uncomp_buf is free'd, presumably because we have trashed malloc's
> metadata which I believe lives after the malloc'd buffer.
> 
> Adding a check fixes this for me.
> 
> Hope this helps,
> Dave
> 
> -------------------------------------------------------------------------
> 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-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers

[sleuthkit-developers] NTFS Compression bug solution

[David C. <da...@in...>]

Hi Brian,
I think I have tracked this down to the loop on line 1051 in ntfs.c.
There is no bounds checking, and in my problem case it overflows the
comp->uncomp_buf buffer. It does not abort immediately, but rather when
uncomp_buf is free'd, presumably because we have trashed malloc's
metadata which I believe lives after the malloc'd buffer.

Adding a check fixes this for me.

Hope this helps,
Dave

Re: [sleuthkit-developers] ifind issue and library stuff.

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

On Nov 28, 2006, at 6:34 AM, David Collett wrote:

> Hi Brian,
>
> I've attached a patch to check for a null pointer before free in
> fs_inode.c.  Michael Cohen added this. He can't remember if it
> definitely caused a crash or was just added while debugging something,
> nevertheless it doesnt hurt.

Thanks.  I'll add that in.

> The main reason for this email was to discuss an issue I found in  
> ifind.
>
> I have found an issue wherby if you have a file which has an allocated
> and an unallocated dent, ifind will often find the unallocated entry
> first and print '0' for the inode and return, even though there is an
> allocated inode with that filename, which is almost certainly what you
> want to see in this situation.
>
> This happens because fs_ifind_path issues a dent walk with ALLOC and
> UNALLOC flags set and the callback (ifind_path_act) stops walking as
> soon as it finds a name match, even if it is a realloc'd dent.
>
> A solution which seems to work is that when you find a name match,  
> check
> if you are alloc or unalloc (e.g. fs_inode->fsi == NULL seems to
> indicate unalloc), if unalloc, set found=1, record the inode (is it
> always 0?) but return WALK_CONT. This gives you another chance to
> find the real (alloc) file. If you then get to the end of the
> function without finding another one, you can print the details you
> have recorded (i.e. the unalloc entry). Does that make sense?

Yea. I'll make that change.
> On the topic of fs_ifind_path, I wanted to use this funtionallity in
> pyflag, but unfortunately if is very library unfriendly as it printf's
> the inode rather than returning it. What I did was rename this  
> function,
> modify it to return the matched inum, and then wrote a small wrapper
> version of fs_ifind_path which used the new function and printed the
> result in order to maintain the API. I think there are other places
> where this technique will be useful to me as I am writing a python
> sleuthkit module (for pyflag) and wish to employ sk in a library
> context. Would you me interested in patches for these changes? There
> have already been some great changes to help lib'ise sk (for example
> tsk_error stuff) I'd like to continue this effort.

Would it be easier if there was a callback design?

> Finally, I have unfortunately not had time to revisit the NTFS
> compression bug which I encountered as I have been mostly out of the
> office. I hope to look at it again later this week. Have you made any
> progress with it?

No.  I was waiting for someone to run a special version with verbose  
text output, but have not heard back.

thanks,
brian

[sleuthkit-developers] ifind issue and library stuff.

[David C. <da...@in...>]

Hi Brian,

I've attached a patch to check for a null pointer before free in
fs_inode.c.  Michael Cohen added this. He can't remember if it
definitely caused a crash or was just added while debugging something,
nevertheless it doesnt hurt.

The main reason for this email was to discuss an issue I found in ifind.

I have found an issue wherby if you have a file which has an allocated
and an unallocated dent, ifind will often find the unallocated entry
first and print '0' for the inode and return, even though there is an
allocated inode with that filename, which is almost certainly what you
want to see in this situation.

This happens because fs_ifind_path issues a dent walk with ALLOC and
UNALLOC flags set and the callback (ifind_path_act) stops walking as
soon as it finds a name match, even if it is a realloc'd dent.

A solution which seems to work is that when you find a name match, check
if you are alloc or unalloc (e.g. fs_inode->fsi == NULL seems to
indicate unalloc), if unalloc, set found=1, record the inode (is it
always 0?) but return WALK_CONT. This gives you another chance to
find the real (alloc) file. If you then get to the end of the
function without finding another one, you can print the details you
have recorded (i.e. the unalloc entry). Does that make sense?

On the topic of fs_ifind_path, I wanted to use this funtionallity in
pyflag, but unfortunately if is very library unfriendly as it printf's
the inode rather than returning it. What I did was rename this function,
modify it to return the matched inum, and then wrote a small wrapper
version of fs_ifind_path which used the new function and printed the
result in order to maintain the API. I think there are other places
where this technique will be useful to me as I am writing a python
sleuthkit module (for pyflag) and wish to employ sk in a library
context. Would you me interested in patches for these changes? There
have already been some great changes to help lib'ise sk (for example
tsk_error stuff) I'd like to continue this effort.

Finally, I have unfortunately not had time to revisit the NTFS
compression bug which I encountered as I have been mostly out of the
office. I hope to look at it again later this week. Have you made any
progress with it?

Thanks,

Dave

Re: [sleuthkit-developers] sleuthkit bug in fs_data.c

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

David Collett wrote:
> Hi Brian,
> 
> On Fri, Nov 17, 2006 at 05:13:28PM -0500, Brian Carrier wrote:
>> Indeed you are correct.  I just fixed it (the next version will 
>> hopefully be out next week once I track down an elusive NTFS compression 
>> bug).
> 
> I think I've seen this too, on friday afternoon, I didnt get much time
> to look into it. glibc detecting a double free in ntfs_uncompress_done??
> 
> Let me know this week if you want me to test your solution.

My initial fix for this problem turned into an infinite loop.  It 
appears to happen when the file is unallocated and the clusters 
allocated to the file have been reused.  The new data screws up the 
compression algorithm somehow...  If you have a file that causes that 
message though, I could use your help debugging this.


>> Where else did you see this issue?  I think fs_data is the only 
>> structure that is reused.
> 
> If you grep the sources in src/fstools for FS_DATA_INUSE, you will see a few
> more while loops with the same structure e.g.:
> 
> ...
> dcalc_lib.c:151:        while ((fs_data) && (fs_data->flags & FS_DATA_INUSE)) {
> dls_lib.c:178:  while ((fs_data) && (fs_data->flags & FS_DATA_INUSE)) {
> fls_lib.c:137:      while ((fs_data) && (fs_data->flags & FS_DATA_INUSE)) {
> ...
> (there are more)

Oh, I get it now.  I thought you meant there were other structures that 
had a similar design problem.  I think I will both update the loops and 
update the _alloc methods so that the used attributes are moved to the 
head of the list.

thanks,
brian

Re: [sleuthkit-developers] sleuthkit bug in fs_data.c

[David C. <da...@in...>]

Hi Brian,

On Fri, Nov 17, 2006 at 05:13:28PM -0500, Brian Carrier wrote:
> Indeed you are correct.  I just fixed it (the next version will 
> hopefully be out next week once I track down an elusive NTFS compression 
> bug).

I think I've seen this too, on friday afternoon, I didnt get much time
to look into it. glibc detecting a double free in ntfs_uncompress_done??

Let me know this week if you want me to test your solution.

> Where else did you see this issue?  I think fs_data is the only 
> structure that is reused.

If you grep the sources in src/fstools for FS_DATA_INUSE, you will see a few
more while loops with the same structure e.g.:

...
dcalc_lib.c:151:        while ((fs_data) && (fs_data->flags & FS_DATA_INUSE)) {
dls_lib.c:178:  while ((fs_data) && (fs_data->flags & FS_DATA_INUSE)) {
fls_lib.c:137:      while ((fs_data) && (fs_data->flags & FS_DATA_INUSE)) {
...
(there are more)

These loops will also quit early if they see a hole right? If your
solution was to change fs_data_getnew_attr, then they dont matter, but
if you used my patch, these loops will have to be fixed too.

Thanks,
Dave

> David Collett wrote:
> >G'Day Brian,
> >
> >I believe I have found a bug in sleuthkit.
> >
> >in fs_data.c:
> >
> >fs_data_getnew_attr can create unused 'holes' in attr lists. At least
> >two functions, fs_data_lookup and fs_data_lookup_noid do not jump the
> >holes which can cause them to return early without finding the correct
> >FS_DATA element to return.
> > 
> >This does not seem to effect sleuthkit (though I havent done much
> >testing), but it does effect pyflag. Probably because we live for longer
> >and perform more walks etc than the sk tools. As such there is more
> >opportunities for structure reuse and hence more chances to hit this
> >bug.
> > 
> >My solution for now is to change the loops in fs_data_lookup and
> >fs_data_lookup_noid to jump the holes (patch attached), though another
> >possibility is to modify fs_data_getnew_attr so that it does not create
> >holes in the first place. This may be more complicated and undesirable
> >though.
> >
> >My patch *only* fixes the loops in fs_data. A quick grep through the
> >code reveals several more similar loops which could cause trouble
> >(though through luck, they probably dont!).
> >
> >Let me know what you think or if you need a better description of the
> >problem, I can fix up the rest for you and send another patch if you
> >like.
> >
> >Thanks,
> >David Collett
> >
> >
> >------------------------------------------------------------------------
> >
> >diff -ruN sleuthkit-2.06/src/fstools/fs_data.c 
> >sleuthkit-2.06-dave/src/fstools/fs_data.c
> >--- sleuthkit-2.06/src/fstools/fs_data.c	2006-09-02 
> >02:09:15.000000000 +1000
> >+++ sleuthkit-2.06-dave/src/fstools/fs_data.c	2006-11-17 
> >18:10:59.615647500 +1100
> >@@ -242,9 +242,11 @@
> > 	return NULL;
> >     }
> > 
> >-    while ((fs_data) && (fs_data->flags & FS_DATA_INUSE) &&
> >-	((fs_data->type != type) || (fs_data->id != id)))
> >-	fs_data = fs_data->next;
> >+    while (fs_data) {
> >+        if((fs_data->flags & FS_DATA_INUSE) && (fs_data->type == type) && 
> >(fs_data->id == id))
> >+            break;
> >+        fs_data = fs_data->next;
> >+    }
> > 
> >     if ((!fs_data) || (fs_data->type != type) || (fs_data->id != id)) {
> > 	return NULL;
> >@@ -280,8 +282,8 @@
> >      * lowest id of the given type (if more than one exists) 
> >      */
> > 
> >-    while ((fs_data) && (fs_data->flags & FS_DATA_INUSE)) {
> >-	if (fs_data->type == type) {
> >+    while (fs_data) {
> >+	if ((fs_data->flags & FS_DATA_INUSE) && fs_data->type == type) {
> > 
> > 	    /* replace existing if new is lower */
> > 	    if ((!fs_data_ret) || (fs_data_ret->id > fs_data->id))
> >
> >
> >------------------------------------------------------------------------
> >
> >-------------------------------------------------------------------------
> >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-developers mailing list
> >sle...@li...
> >https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers

Re: [sleuthkit-developers] sleuthkit bug in fs_data.c

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

Indeed you are correct.  I just fixed it (the next version will 
hopefully be out next week once I track down an elusive NTFS compression 
bug).

Where else did you see this issue?  I think fs_data is the only 
structure that is reused.

thanks,
brian

David Collett wrote:
> G'Day Brian,
> 
> I believe I have found a bug in sleuthkit.
> 
> in fs_data.c:
> 
> fs_data_getnew_attr can create unused 'holes' in attr lists. At least
> two functions, fs_data_lookup and fs_data_lookup_noid do not jump the
> holes which can cause them to return early without finding the correct
> FS_DATA element to return.
>  
> This does not seem to effect sleuthkit (though I havent done much
> testing), but it does effect pyflag. Probably because we live for longer
> and perform more walks etc than the sk tools. As such there is more
> opportunities for structure reuse and hence more chances to hit this
> bug.
>  
> My solution for now is to change the loops in fs_data_lookup and
> fs_data_lookup_noid to jump the holes (patch attached), though another
> possibility is to modify fs_data_getnew_attr so that it does not create
> holes in the first place. This may be more complicated and undesirable
> though.
> 
> My patch *only* fixes the loops in fs_data. A quick grep through the
> code reveals several more similar loops which could cause trouble
> (though through luck, they probably dont!).
> 
> Let me know what you think or if you need a better description of the
> problem, I can fix up the rest for you and send another patch if you
> like.
> 
> Thanks,
> David Collett
> 
> 
> ------------------------------------------------------------------------
> 
> diff -ruN sleuthkit-2.06/src/fstools/fs_data.c sleuthkit-2.06-dave/src/fstools/fs_data.c
> --- sleuthkit-2.06/src/fstools/fs_data.c	2006-09-02 02:09:15.000000000 +1000
> +++ sleuthkit-2.06-dave/src/fstools/fs_data.c	2006-11-17 18:10:59.615647500 +1100
> @@ -242,9 +242,11 @@
>  	return NULL;
>      }
>  
> -    while ((fs_data) && (fs_data->flags & FS_DATA_INUSE) &&
> -	((fs_data->type != type) || (fs_data->id != id)))
> -	fs_data = fs_data->next;
> +    while (fs_data) {
> +        if((fs_data->flags & FS_DATA_INUSE) && (fs_data->type == type) && (fs_data->id == id))
> +            break;
> +        fs_data = fs_data->next;
> +    }
>  
>      if ((!fs_data) || (fs_data->type != type) || (fs_data->id != id)) {
>  	return NULL;
> @@ -280,8 +282,8 @@
>       * lowest id of the given type (if more than one exists) 
>       */
>  
> -    while ((fs_data) && (fs_data->flags & FS_DATA_INUSE)) {
> -	if (fs_data->type == type) {
> +    while (fs_data) {
> +	if ((fs_data->flags & FS_DATA_INUSE) && fs_data->type == type) {
>  
>  	    /* replace existing if new is lower */
>  	    if ((!fs_data_ret) || (fs_data_ret->id > fs_data->id))
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> 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-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers

[sleuthkit-developers] sleuthkit bug in fs_data.c

[David C. <da...@in...>]

G'Day Brian,

I believe I have found a bug in sleuthkit.

in fs_data.c:

fs_data_getnew_attr can create unused 'holes' in attr lists. At least
two functions, fs_data_lookup and fs_data_lookup_noid do not jump the
holes which can cause them to return early without finding the correct
FS_DATA element to return.
 
This does not seem to effect sleuthkit (though I havent done much
testing), but it does effect pyflag. Probably because we live for longer
and perform more walks etc than the sk tools. As such there is more
opportunities for structure reuse and hence more chances to hit this
bug.
 
My solution for now is to change the loops in fs_data_lookup and
fs_data_lookup_noid to jump the holes (patch attached), though another
possibility is to modify fs_data_getnew_attr so that it does not create
holes in the first place. This may be more complicated and undesirable
though.

My patch *only* fixes the loops in fs_data. A quick grep through the
code reveals several more similar loops which could cause trouble
(though through luck, they probably dont!).

Let me know what you think or if you need a better description of the
problem, I can fix up the rest for you and send another patch if you
like.

Thanks,
David Collett

[sleuthkit-developers] Creating XFS support

[q u. <que...@ya...>]

Developers,

XFS (and ReiserFS) are frequently used filesystems yet
there is no support in the sleuthkit.
I like to research possible development and I can use
some information:

- is there any fs support development documentation
available?
- how much time did it take to develop the current
supported fss in sleuthkit?

Tim


	
	
		
___________________________________________________________ 
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine 
http://uk.docs.yahoo.com/nowyoucan.html

Re: [sleuthkit-developers] autoconf sk

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

Thanks Michael.  This will be my motivation to start to learn autoconf 
and finish it up.

thanks,
brian

Michael Cohen wrote:
> Hi Brian,
>   I had a bit of time this evening to have a first poke at sk with autoconf. I
>   have posted what I have at the moment on:
> 
> http://pyflag.sourceforge.net/misc/sk_autoconf.tgz
> 
>   Its far from finished but is a good start, still left to do:
>   - Remove all the os dependent defines in various .h files
> 
>   - Make lots of stuff optional (e.g. libewf support etc).
>   
>   - Decide what is to be installed and where when users do make install - users
>   can always use --prefix to install to a stand alone directory or they may
>   choose to install to the system.  There is probably little point have bin,
>   lib etc in the top build tree when they will be installed to the prefix
>   anyway.
>   
>   - Fine tune what will be included in the distribution tar ball - then you can
>   do a make dist-gz to get a sleuthkit.tar.gz ready to ship.
> 
>   You can check the differences between the tar ball i made and sk-2.05 using
>   meld for example.
> 
>   Michael.
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> sleuthkit-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers

[sleuthkit-developers] autoconf sk

[Michael C. <mic...@ne...>]

Hi Brian,
  I had a bit of time this evening to have a first poke at sk with autoconf. I
  have posted what I have at the moment on:

http://pyflag.sourceforge.net/misc/sk_autoconf.tgz

  Its far from finished but is a good start, still left to do:
  - Remove all the os dependent defines in various .h files

  - Make lots of stuff optional (e.g. libewf support etc).
  
  - Decide what is to be installed and where when users do make install - users
  can always use --prefix to install to a stand alone directory or they may
  choose to install to the system.  There is probably little point have bin,
  lib etc in the top build tree when they will be installed to the prefix
  anyway.
  
  - Fine tune what will be included in the distribution tar ball - then you can
  do a make dist-gz to get a sleuthkit.tar.gz ready to ship.

  You can check the differences between the tar ball i made and sk-2.05 using
  meld for example.

  Michael.

[sleuthkit-developers] autoconf people?

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

Anyone here a pro at autoconf / automake?  I'm in the process of 
cleaning up the makefiles / libraries / header files etc. and am 
considering the use of autoconf to make the build process more clean.

brian

[sleuthkit-developers] Nigilant32 - Free Windows Incident Response Tool based on Sleuthkit - Final Article Released

[Matthew M. S. <msh...@ag...>]

To all- 

 

Agile Risk Management is committed to advancing information security
concepts, technology, and techniques. As such, we have recently released
Nigilant32, a freeware Windows GUI Incident Response tool based on the
source code provided by Sleuthkit.

 

Nigilant32 is an incident response tool designed to capture as much
information as possible from a running system with the smallest potential
impact. Nigilant32 has been developed with Windows 2000, XP, and 2003 in
mind, and should work fine with computers running one of those operating
systems. Nigilant32 is beta software and may not work in all instances.

 

The third article in our series of "Nigilant32 For First Responders"
articles is "Active Memory Imaging". This article covers using Nigilant32 to
image the active physical memory (RAM) of the suspect workstation or server
to secure portable media. Make sure you download the article, as the last
pages contain a sneak preview of the current project being developed in the
Agile Research Lab.

 

We sincerely hope you find Nigilant32 useful, however please remember, it is
beta software therefore you should exercise good judgment when using it in
your IT environment.

 

Nigilant32, articles (as they are released), and modified Sleuthkit source
code (libsleuthkit) is available at
http://www.agilerm.net/publications_4.html

 

Warmest Regards,

 

Matthew M Shannon, CIFI, CISSP
Principal - Computer Forensics and Litigation Support
Agile Risk Management LLC
2202 N Westshore Blvd, Suite 200
Tampa, FL 33607
(M) 813.732.5076
(O) 1.877.AGILE13 (877.244.5313)
 <http://www.agileriskmanagement.com/> www.agileriskmanagement.com

 

Re: [sleuthkit-developers] Some questions

[kenshin <ken...@gm...>]

Thks Michael to solve my doubts
I make some test with sgzip, but I dont see whereis the compression between
raw image and sgzip image. Do you now other seekable compression system?

2000/1/1, Michael Cohen <mic...@ne...>:
>
> On Wed, Jun 21, 2006 at 01:38:13PM +0200, kenshin wrote:
> > Other suggestion, I think that open stdin is better that open a file.
> > For example "fls < ext3fs.img" is better because you could for example
> > make "bunzip2 -c ext3fs.img.bz2| fls" or other combinations. With this
> > you have small images and if you have a good cpu you could scan
> > images faster :)
>
> kenshin, Its impossible for fls to use stdin since it needs to seek in the
> input file which means it cant use a pipe (you could still do fls <
> ext3fs.img
> because thats not a pipe, but not the second example). Also for normal
> images
> you certainly couldnt do bunzip2 -c ext3fs.img.bz2| fls because the image
> would
> take a huge length of time to decompress for a single shot of fls. If you
> want
> to handle compressed images you better use ewf, eff or sgzip formats.
>
> Michael.
>
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> sleuthkit-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers
>

Re: [sleuthkit-developers] Some questions

[Michael C. <mic...@ne...>]

On Wed, Jun 21, 2006 at 01:38:13PM +0200, kenshin wrote:
> Other suggestion, I think that open stdin is better that open a file.
> For example "fls < ext3fs.img" is better because you could for example
> make "bunzip2 -c ext3fs.img.bz2| fls" or other combinations. With this
> you have small images and if you have a good cpu you could scan
> images faster :)

kenshin, Its impossible for fls to use stdin since it needs to seek in the
input file which means it cant use a pipe (you could still do fls < ext3fs.img
because thats not a pipe, but not the second example). Also for normal images
you certainly couldnt do bunzip2 -c ext3fs.img.bz2| fls because the image would
take a huge length of time to decompress for a single shot of fls. If you want
to handle compressed images you better use ewf, eff or sgzip formats.

Michael.

[sleuthkit-developers] Nigilant32 - Free Windows Incident Response Tool based on Sleuthkit - New Article Released

[Matthew M. S. <msh...@ag...>]

To all- 

 

Agile Risk Management is committed to advancing information security
concepts, technology, and techniques. As such, we have recently released
Nigilant32, a freeware Windows GUI Incident Response tool based on the
source code provided by Sleuthkit.

 

Nigilant32 is an incident response tool designed to capture as much
information as possible from a running system with the smallest potential
impact. Nigilant32 has been developed with Windows 2000, XP, and 2003 in
mind, and should work fine with computers running one of those operating
systems. Nigilant32 is beta software and may not work in all instances.

 

The second article in our series of "Nigilant32 For First Responders"
articles is "The Filesystem". This article covers using Nigilant32 to review
the active filesystem using the code and technology provided by The
Sleuthkit Project..

 

We sincerely hope you find Nigilant32 useful, however please remember, it is
beta software therefore you should exercise good judgment when using it in
your IT environment.

 

Nigilant32, articles (as they are released), and modified Sleuthkit source
code (libsleuthkit) is available at
http://www.agilerm.net/publications_4.html

 

Warmest Regards,

 

 

 

Matthew M Shannon, CIFI, CISSP
Principal - Computer Forensics and Litigation Support
Agile Risk Management LLC
2202 N Westshore Blvd, Suite 200
Tampa, FL 33607

msh...@ag...
(M) 813.732.5076
(O) 1.877.AGILE13 (877.244.5313)
 <http://www.agileriskmanagement.com/> www.agileriskmanagement.com

 

Re: [sleuthkit-developers] Some questions

[Valter S. <vsa...@se...>]

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

kenshin wrote:
> I know that we don't use untruted executable, but normaly we make a copy
> of hd
> in other and then we analyzed this image in our computer and I trust my
> computer :)
> 

Kenshin,

but this is not always the case, there are times that we need to analyze
a system that couldn't be powered off, so we need trusted binaries for
live analysis.

Anyways, as Brian already pointed out, compiling sleuthkit as static is
optional so your problem is solved here :-)

have fun
/valter


- --
o Valter Santos <vsantola at sectoid.com>
o INFOCON Tactical Overview: http://infocon.sectoid.com
o
o PGP Key ID:  0xE2A4B206
o Fingerprint: 99FA 3D80 4B54 BA70 7DD7 C751 47BA 49BC E2A4 B206
o
o Attack is the secret of defense; defense is the planning of an attack.
o Sun Tzu, Art of War

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEmWzAR7pJvOKksgYRAhIXAKC91oSrjzgBLrjjRAuXyH+nr7Y2pgCgiv65
H7rV0GQofgXPE+1dE0mdqoA=
=fCen
-----END PGP SIGNATURE-----

Re: [sleuthkit-developers] Some questions

[kenshin <ken...@gm...>]

I think that make a shared library witch all the posible code is better than
put
the same code in all files. You could make a libsleuthkit.so with ~1M of
code
If you want small files don't use -g -Wall in gcc :)


> They have the same effect don't they?  Is 'make -C dir' only in GNU
> or is it also in BSD make?

FreeBSD have -C option in make


Other suggestion, I think that open stdin is better that open a file.
For example "fls < ext3fs.img" is better because you could for example
make "bunzip2 -c ext3fs.img.bz2| fls" or other combinations. With this
you have small images and if you have a good cpu you could scan
images faster :)

Thanks to solve my doubts


2006/6/21, Brian Carrier <ca...@sl...>:
>
>
> On Jun 20, 2006, at 7:37 PM, kenshin wrote:
>
> > I'm interesting in develop sleuthkit and I have some questions ...
> >
> > Why do you want to use static executables?
> > Why do you not use shared libraries?
>
> By default, the executables use shared libraries and are not static.
> There is the option for static binaries so that you can use them for
> live analysis and not have to rely on untrusted libraries.
>
> > Why do you use "cd dir; make" instead "make -C dir" ?
>
> They have the same effect don't they?  Is 'make -C dir' only in GNU
> or is it also in BSD make?
>
> > Why have "src/fstools/" filesystems and tools to analyze? I thinks
> > that is better
> > put filesystems in src/fs/ and tools in src/fstools/
>
> Yea, I could separate the library code from the tools one of these days.
>
> > Why do you compile the comand file,md5,sha1? (a normal system have
> > its)
> > Has anyone interesting in reiserfs development?
>
> As someone else said, it forces a consistent version of the tools to
> exist.  Different systems have different output formats.
>
> brian
>
>
>

Re: [sleuthkit-developers] Some questions

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

On Jun 20, 2006, at 7:37 PM, kenshin wrote:

> I'm interesting in develop sleuthkit and I have some questions ...
>
> Why do you want to use static executables?
> Why do you not use shared libraries?

By default, the executables use shared libraries and are not static.   
There is the option for static binaries so that you can use them for  
live analysis and not have to rely on untrusted libraries.

> Why do you use "cd dir; make" instead "make -C dir" ?

They have the same effect don't they?  Is 'make -C dir' only in GNU  
or is it also in BSD make?

> Why have "src/fstools/" filesystems and tools to analyze? I thinks  
> that is better
> put filesystems in src/fs/ and tools in src/fstools/

Yea, I could separate the library code from the tools one of these days.

> Why do you compile the comand file,md5,sha1? (a normal system have  
> its)
> Has anyone interesting in reiserfs development?

As someone else said, it forces a consistent version of the tools to  
exist.  Different systems have different output formats.

brian

Re: [sleuthkit-developers] Some questions

[kenshin <ken...@gm...>]

I know that we don't use untruted executable, but normaly we make a copy of
hd
in other and then we analyzed this image in our computer and I trust my
computer :)

Thanks for the interest


2006/6/21, Valter Santos <vsa...@se...>:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> kenshin wrote:
> >
> > Why do you want to use static executables?
> > Why do you not use shared libraries?
>
> For forensic and incident response purposes: with static executables we
> don't rely on anything that is deployed on a compromised system on
> performing live analysis. This is done so we get a "trusted" executable
> we can rely on.
>
> > Why do you compile the comand file,md5,sha1? (a normal system have its)
>
> The same as above, I think. These tools are crucial to sleuthkit
> activity, so they get compiled in a trusted fashion ;)
>
> have fun
> /valter
>
>
> - --
> o Valter Santos <vsantola at sectoid.com>
> o INFOCON Tactical Overview: http://infocon.sectoid.com
> o
> o PGP Key ID:  0xE2A4B206
> o Fingerprint: 99FA 3D80 4B54 BA70 7DD7 C751 47BA 49BC E2A4 B206
> o
> o Attack is the secret of defense; defense is the planning of an attack.
> o Sun Tzu, Art of War
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
>
> iD8DBQFEmJJeR7pJvOKksgYRAm+8AJ4m3GMPJ7KyMSBHsHsIeqac5uZioACggiTY
> 0rjxbwEXzHvqWrOHPzb9tDE=
> =1nis
> -----END PGP SIGNATURE-----
>

Re: [sleuthkit-developers] Some questions

[Valter S. <vsa...@se...>]

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

kenshin wrote:
>
> Why do you want to use static executables?
> Why do you not use shared libraries?

For forensic and incident response purposes: with static executables we
don't rely on anything that is deployed on a compromised system on
performing live analysis. This is done so we get a "trusted" executable
we can rely on.

> Why do you compile the comand file,md5,sha1? (a normal system have its)

The same as above, I think. These tools are crucial to sleuthkit
activity, so they get compiled in a trusted fashion ;)

have fun
/valter


- --
o Valter Santos <vsantola at sectoid.com>
o INFOCON Tactical Overview: http://infocon.sectoid.com
o
o PGP Key ID:  0xE2A4B206
o Fingerprint: 99FA 3D80 4B54 BA70 7DD7 C751 47BA 49BC E2A4 B206
o
o Attack is the secret of defense; defense is the planning of an attack.
o Sun Tzu, Art of War

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEmJJeR7pJvOKksgYRAm+8AJ4m3GMPJ7KyMSBHsHsIeqac5uZioACggiTY
0rjxbwEXzHvqWrOHPzb9tDE=
=1nis
-----END PGP SIGNATURE-----