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

Re: [sleuthkit-users] MFT entry sequence numbers

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

>From the linux NTFS documentation project: 

-- quote --

Sequence Number

Number of times this mft record has been reused.

N.B. The increment (skipping zero) is done when the file isdeleted.

N.B. If this is set to zero it is left as zero.

-- unquote --


My understanding of this is: 

65535 (-1) is the first sequence number
1 is the second sequence number
2 is the third sequence number
etc

0 means that the sequence number is not used (possibly because the entry
shall not be reused because it is baad or for another reason)


Svein 


> -----Original Message-----
> From: sle...@li... [mailto:sleuthkit-
> use...@li...] On Behalf Of Svein Yngvar Willassen
> Sent: 28. august 2006 14:20
> To: sle...@li...
> Subject: [sleuthkit-users] MFT entry sequence numbers
> 
> 
> I'm looking at the MFT entry sequence numbers. I notice that while most of
> the entries have sequence number 1-100, there is also a fair amount with
> sequence number 65535 (0xffff).
> 
> Anyone know if this value is special and if so what it means?
> 
> Regards,
> 
> Svein Y. Willassen
> Researcher, Norwegian University of Technology and Science
> 
> 
> 
> -------------------------------------------------------------------------
> 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-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

Re: [sleuthkit-users] mounting of aff-files?

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

Hi, Uwe.

Your experience matches mine. In general it is faster  (with most =20
processor/disk combinations) to read a compressed file and decompress =20=

it, than to read a decompressed file.

Right now there is no way to mount aff-files via a loopback device. =20
However, if you want to write the code, I'll be happy to integrate it!

On Aug 28, 2006, at 3:17 AM, Uwe Danz wrote:

> Hi List,
>
> Sleuthkit works very well with AFF-Harddisk images.
> All tasks run much more quicker with my 9GB aff-file
> instead of the "original" 300GB (test-)dd-image.
>
> Does anyone know a way to mount aff-files via the
> loopback device or via an other way?
>
> Regards,
>    Uwe.
> --=20
> "The greatest of all faults is to be conscious of none" Thomas
> Carlyle
>
> Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> Ideal f=FCr Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
>
> ----------------------------------------------------------------------=20=

> ---
> 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?=20
> cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D121642
> _______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>

[sleuthkit-users] MFT entry sequence numbers

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

I'm looking at the MFT entry sequence numbers. I notice that while most of
the entries have sequence number 1-100, there is also a fair amount with
sequence number 65535 (0xffff).

Anyone know if this value is special and if so what it means?

Regards,

Svein Y. Willassen
Researcher, Norwegian University of Technology and Science

[sleuthkit-users] mounting of aff-files?

[Uwe D. <uwe...@gm...>]

Hi List,

Sleuthkit works very well with AFF-Harddisk images.
All tasks run much more quicker with my 9GB aff-file
instead of the "original" 300GB (test-)dd-image.

Does anyone know a way to mount aff-files via the
loopback device or via an other way?

Regards,
   Uwe.
-- 
"The greatest of all faults is to be conscious of none" Thomas 
Carlyle

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

Re: [sleuthkit-users] more crashes

[Gary F. <ga...@in...>]

Brian Carrier wrote (in part):
> 
> I thought I was handling corrupt path and file name info, but I'll check 
> it out in more detail today.

Running with the debug version of malloc/free might be worth a shot:
Setting the environment variable MALLOC_CHECK_=2 will do that on modern
glibc based implmentations of malloc().

Re: [sleuthkit-users] more crashes

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

On Aug 24, 2006, at 11:40 PM, Svein Yngvar Willassen wrote:

> Hello Simson,
>
> Are these "Drive #xxx" something that is publicly available, or are  
> they
> internal references?

They are internal reference numbers from my corpus.

>
> Anyway, at least the first (and third) of the crashes you cite here  
> could be
> a similar problem as discussed previously, namely that ntfs_info- 
> >sds->data
> could be NULL. If these problems have turned up in recent versions,  
> it would
> be reasonable to check any recent changes in the code that build these
> structures.

Nope. I tried try patching the code so that it checks the value  
before it frees...

static void
ntfs_secure_data_free(NTFS_INFO * ntfs_info)
{
     // Iterate of sds entries and free them
     while (ntfs_info->sds) {
=>      if(ntfs_info->sds->data) free(ntfs_info->sds->data);
         ntfs_info->sds = ntfs_info->sds->next;
     }

And I got another crash. ntfs_info->sds->data isn't NULL, it's just  
an invalid pointer:

(gdb) p ntfs_info->sds
$1 = (NTFS_SDS_ENTRY *) 0x7332ddf
(gdb) p ntfs_info->sds->data
Cannot access memory at address 0x7332def
(gdb)







>
> Regards,
>
> Svein
>
>
>
>> -----Original Message-----
>> From: sle...@li...  
>> [mailto:sleuthkit-
>> use...@li...] On Behalf Of Simson Garfinkel
>> Sent: 24. august 2006 21:20
>> To: sle...@li...
>> Subject: [sleuthkit-users] more crashes
>>
>> Drive #193 causes a crash at line 3874 of ntfs.c.
>>
>> Here is the stack trace:
>>
>> (gdb) where
>> #0  0x0000000000429427 in ntfs_secure_data_free (ntfs_info=0x566400)
>> at ntfs.c:3874
>> #1  0x00000000004294d8 in ntfs_close (fs=0x566400) at ntfs.c:3896
>> #2  0x0000000000402b0a in do_vol (img=0x564000, start=32256) at
>> iwalk.cpp:178
>> #3  0x0000000000402b7c in mm_act (mm=0x564080, pnum=2, part=0x563180,
>> flag=0, ptr=0x44a304 "") at iwalk.cpp:195
>> #4  0x00000000004342e0 in dos_part_walk (mm=0x564080, start=0,
>> last=2, flags=6, action=0x402b30 <mm_act>, ptr=0x44a304 "") at dos.c:
>> 1013
>> #5  0x0000000000402c5e in do_dimage (img=0x564000, desc=0x44a406 "my
>> boring test comment") at iwalk.cpp:229
>> #6  0x0000000000402e39 in main (argc=1, argv=0x7fffffffe988) at
>> iwalk.cpp:294
>> (gdb)
>>
>>
>> and the code:
>> static void
>> ntfs_secure_data_free(NTFS_INFO * ntfs_info)
>> {
>>      // Iterate of sds entries and free them
>>      while (ntfs_info->sds) {
>> =>      free(ntfs_info->sds->data);
>>          ntfs_info->sds = ntfs_info->sds->next;
>>      }
>>
>> ==================
>> Drive #248:
>>
>> stack appears corrupted; this is what's on top:
>>
>> #0  0x0000000800d9c020 in strncpy () from /lib/libc.so.6
>> (gdb) where
>> #0  0x0000000800d9c020 in strncpy () from /lib/libc.so.6
>> #1  0x00000000004206f4 in fatfs_dent_parse_buf (fatfs=0x566400,
>> dinfo=0x7fffffffdd80,
>>      buf=0xffffffffffffe788 <Address 0xffffffffffffe788 out of
>> bounds>, len=6144, addrs=0x1663000, flags=7, action=0x402530
>> <dent_act>, ptr=0x0)
>>      at fatfs_dent.c:521
>> #2  0x0000000000420c46 in fatfs_dent_walk_lcl (fs=0x566400,
>> dinfo=0x7fffffffdd80, inode=40, flags=7, action=0x402530 <dent_act>,
>> ptr=0x0)
>>      at fatfs_dent.c:754
>> #3  0x0000000000420771 in fatfs_dent_parse_buf (fatfs=0x566400,
>> dinfo=0x7fffffffdd80,
>>      buf=0xffffffffffffe788 <Address 0xffffffffffffe788 out of
>> bounds>, len=6144, addrs=0x1662000, flags=7, action=0x402530
>> <dent_act>, ptr=0x0)
>>      at fatfs_dent.c:539
>> #4  0x0000000000420c46 in fatfs_dent_walk_lcl (fs=0x566400,
>> dinfo=0x7fffffffdd80, inode=40, flags=7, action=0x402530 <dent_act>,
>> ptr=0x0)
>>      at fatfs_dent.c:754
>> #5  0x0000000000420771 in fatfs_dent_parse_buf (fatfs=0x566400,
>> dinfo=0x7fffffffdd80,
>>      buf=0xffffffffffffe788 <Address 0xffffffffffffe788 out of
>> bounds>, len=6144, addrs=0x165b000, flags=7, action=0x402530
>> <dent_act>, ptr=0x0)
>>      at fatfs_dent.c:539
>> #6  0x0000000000420c46 in fatfs_dent_walk_lcl (fs=0x566400,
>> dinfo=0x7fffffffdd80, inode=40, flags=7, action=0x402530 <dent_act>,
>> ptr=0x0)
>>      at fatfs_dent.c:754
>> #7  0x0000000000420771 in fatfs_dent_parse_buf (fatfs=0x566400,
>> dinfo=0x7fffffffdd80,
>>      buf=0xffffffffffffe788 <Address 0xffffffffffffe788 out of
>> bounds>, len=6144, addrs=0x165a000, flags=7, action=0x402530
>> <dent_act>, ptr=0x0)
>>      at fatfs_dent.c:539
>> #8  0x0000000000420c46 in fatfs_dent_walk_lcl (fs=0x566400,
>> dinfo=0x7fffffffdd80, inode=40, flags=7, action=0x402530 <dent_act>,
>> ptr=0x0)
>>      at fatfs_dent.c:754
>> #9  0x0000000000420771 in fatfs_dent_parse_buf (fatfs=0x566400,
>> dinfo=0x7fffffffdd80,
>>      buf=0xffffffffffffe788 <Address 0xffffffffffffe788 out of
>> bounds>, len=6144, addrs=0x1653000, flags=7, action=0x402530
>> <dent_act>, ptr=0x0)
>>      at fatfs_dent.c:539
>> #10 0x0000000000420c46 in fatfs_dent_walk_lcl (fs=0x566400,
>> dinfo=0x7fffffffdd80, inode=40, flags=7, action=0x402530 <dent_act>,
>> ptr=0x0)
>>      at fatfs_dent.c:754
>> #11 0x0000000000420771 in fatfs_dent_parse_buf (fatfs=0x566400,
>> dinfo=0x7fffffffdd80,
>>      buf=0xffffffffffffe788 <Address 0xffffffffffffe788 out of
>> bounds>, len=6144, addrs=0x1652000, flags=7, action=0x402530
>> <dent_act>, ptr=0x0)
>>      at fatfs_dent.c:539
>>
>>
>>                  /* append our name */
>>                  if (dinfo->depth < MAX_DEPTH) {
>>                      dinfo->didx[dinfo->depth] =
>>                          &dinfo->dirs[strlen(dinfo->dirs)];
>> =>                  strncpy(dinfo->didx[dinfo->depth], fs_dent->name,
>>                          DIR_STRSZ - strlen(dinfo->dirs));
>>                      strncat(dinfo->dirs, "/", DIR_STRSZ);
>>                  }
>>
>> (gdb) p dinfo->didx[53]
>> $2 = 0x7fffffffe789 "\345\221\201\345\275\205\344\241\223\345\211\217
>> \345\275\224\345\211\205\346\214\240\346\271\257\347\211\264\346\261
>> \257\346\
>> \215\234\347\211\264\346\261\257"
>> (gdb) p *fs_dent
>> $3 = {name = 0x1666000 "\345\221\201\345\275\205\344\241\223\345\211
>> \217\345\275\224\345\211\205\346\214\240\346\271\257\347\211\264\346
>> \261\257\\
>> 346\215\234\347\211\264\346\261\257", name_max = 1024,
>>    shrt_name = 0x563f00 ".", shrt_name_max = 32, inode = 40, fsi =
>> 0x164ec00, ent_type = 4 '\004',
>>    path = 0x7fffffffdf88 "DOS/\345\221\201\345\275\205\344\241\223 
>> \345
>> \211\217\345\275\224\345\211\205\346\214\240\346\271\257\347\211\264
>> \346\261\
>> \257\346\215\234\347\211\264\346\261\257/\345\221\201\345\275\205\344
>> \241\223\345\211\217\345\275\224\345\211\205\346\214\240\346\271\257
>> \347\211\
>> \264\346\261\257\346\215\234\347\211\264\346\261\257/\345\221\201\345
>> \275\205\344\241\223\345\211\217\345\275\224\345\211\205\346\214\240
>> \346\271\
>> \257\347\211\264\346\261\257\346\215\234\347\211\264\346\261\257/\345
>> \221\201\345\275\205\344\241\223\345\211\217\345\275\224\345\211\205
>> \346\214\
>> \240\346\271\257\347\211\264\346\261\257\346\215\234\347\211\264\346
>> \261\257/\345\221\201\345\275\205\344\241\223\345\211\217\345\275\224
>> \345\211\
>> \205\346\214\240\346\271\257\347\211\264\346\261\257\346\215\234\347
>> \211\264"..., pathdepth = 53}
>> (gdb)
>>
>>
>> Looks like the structures on the disk are corrupt and the
>> fatfs_dent.c routine is being a little too trusting?
>>
>> ===============================
>> Image 471:
>> (gdb) where
>> #0  0x0000000000429427 in ntfs_secure_data_free (ntfs_info=0x566400)
>> at ntfs.c:3874
>> #1  0x00000000004294d8 in ntfs_close (fs=0x566400) at ntfs.c:3896
>> #2  0x0000000000402b0a in do_vol (img=0x564000, start=32256) at
>> iwalk.cpp:178
>> #3  0x0000000000402b7c in mm_act (mm=0x564080, pnum=2, part=0x563180,
>> flag=0, ptr=0x44a304 "") at iwalk.cpp:195
>> #4  0x00000000004342e0 in dos_part_walk (mm=0x564080, start=0,
>> last=2, flags=6, action=0x402b30 <mm_act>, ptr=0x44a304 "") at dos.c:
>> 1013
>> #5  0x0000000000402c5e in do_dimage (img=0x564000, desc=0x44a406 "my
>> boring test comment") at iwalk.cpp:229
>> #6  0x0000000000402e39 in main (argc=1, argv=0x7fffffffe988) at
>> iwalk.cpp:294
>> (gdb)
>>
>>
>> This looks like the same problem as Drive #193
>
>
>
> ---------------------------------------------------------------------- 
> ---
> 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-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>

Re: [sleuthkit-users] more crashes

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

The SDS code was contributed to the last version and I briefly looked it 
over, but I'll look at it more today to find out why it is not being 
allocated on some drives.  I'm assuming is based on what version of NTFS 
you are using since the security descriptor stuff changed.

I thought I was handling corrupt path and file name info, but I'll check 
it out in more detail today.

brian


Simson Garfinkel wrote:
> Drive #193 causes a crash at line 3874 of ntfs.c.
> 
> Here is the stack trace:
> 
> (gdb) where
> #0  0x0000000000429427 in ntfs_secure_data_free (ntfs_info=0x566400) at 
> ntfs.c:3874
> #1  0x00000000004294d8 in ntfs_close (fs=0x566400) at ntfs.c:3896
> #2  0x0000000000402b0a in do_vol (img=0x564000, start=32256) at 
> iwalk.cpp:178
> #3  0x0000000000402b7c in mm_act (mm=0x564080, pnum=2, part=0x563180, 
> flag=0, ptr=0x44a304 "") at iwalk.cpp:195
> #4  0x00000000004342e0 in dos_part_walk (mm=0x564080, start=0, last=2, 
> flags=6, action=0x402b30 <mm_act>, ptr=0x44a304 "") at dos.c:1013
> #5  0x0000000000402c5e in do_dimage (img=0x564000, desc=0x44a406 "my 
> boring test comment") at iwalk.cpp:229
> #6  0x0000000000402e39 in main (argc=1, argv=0x7fffffffe988) at 
> iwalk.cpp:294
> (gdb)
> 
> 
> and the code:
> static void
> ntfs_secure_data_free(NTFS_INFO * ntfs_info)
> {
>     // Iterate of sds entries and free them
>     while (ntfs_info->sds) {
> =>      free(ntfs_info->sds->data);
>         ntfs_info->sds = ntfs_info->sds->next;
>     }
> 
> ==================
> Drive #248:
> 
> stack appears corrupted; this is what's on top:
> 
> #0  0x0000000800d9c020 in strncpy () from /lib/libc.so.6
> (gdb) where
> #0  0x0000000800d9c020 in strncpy () from /lib/libc.so.6
> #1  0x00000000004206f4 in fatfs_dent_parse_buf (fatfs=0x566400, 
> dinfo=0x7fffffffdd80,
>     buf=0xffffffffffffe788 <Address 0xffffffffffffe788 out of bounds>, 
> len=6144, addrs=0x1663000, flags=7, action=0x402530 <dent_act>, ptr=0x0)
>     at fatfs_dent.c:521
> #2  0x0000000000420c46 in fatfs_dent_walk_lcl (fs=0x566400, 
> dinfo=0x7fffffffdd80, inode=40, flags=7, action=0x402530 <dent_act>, 
> ptr=0x0)
>     at fatfs_dent.c:754
> #3  0x0000000000420771 in fatfs_dent_parse_buf (fatfs=0x566400, 
> dinfo=0x7fffffffdd80,
>     buf=0xffffffffffffe788 <Address 0xffffffffffffe788 out of bounds>, 
> len=6144, addrs=0x1662000, flags=7, action=0x402530 <dent_act>, ptr=0x0)
>     at fatfs_dent.c:539
> #4  0x0000000000420c46 in fatfs_dent_walk_lcl (fs=0x566400, 
> dinfo=0x7fffffffdd80, inode=40, flags=7, action=0x402530 <dent_act>, 
> ptr=0x0)
>     at fatfs_dent.c:754
> #5  0x0000000000420771 in fatfs_dent_parse_buf (fatfs=0x566400, 
> dinfo=0x7fffffffdd80,
>     buf=0xffffffffffffe788 <Address 0xffffffffffffe788 out of bounds>, 
> len=6144, addrs=0x165b000, flags=7, action=0x402530 <dent_act>, ptr=0x0)
>     at fatfs_dent.c:539
> #6  0x0000000000420c46 in fatfs_dent_walk_lcl (fs=0x566400, 
> dinfo=0x7fffffffdd80, inode=40, flags=7, action=0x402530 <dent_act>, 
> ptr=0x0)
>     at fatfs_dent.c:754
> #7  0x0000000000420771 in fatfs_dent_parse_buf (fatfs=0x566400, 
> dinfo=0x7fffffffdd80,
>     buf=0xffffffffffffe788 <Address 0xffffffffffffe788 out of bounds>, 
> len=6144, addrs=0x165a000, flags=7, action=0x402530 <dent_act>, ptr=0x0)
>     at fatfs_dent.c:539
> #8  0x0000000000420c46 in fatfs_dent_walk_lcl (fs=0x566400, 
> dinfo=0x7fffffffdd80, inode=40, flags=7, action=0x402530 <dent_act>, 
> ptr=0x0)
>     at fatfs_dent.c:754
> #9  0x0000000000420771 in fatfs_dent_parse_buf (fatfs=0x566400, 
> dinfo=0x7fffffffdd80,
>     buf=0xffffffffffffe788 <Address 0xffffffffffffe788 out of bounds>, 
> len=6144, addrs=0x1653000, flags=7, action=0x402530 <dent_act>, ptr=0x0)
>     at fatfs_dent.c:539
> #10 0x0000000000420c46 in fatfs_dent_walk_lcl (fs=0x566400, 
> dinfo=0x7fffffffdd80, inode=40, flags=7, action=0x402530 <dent_act>, 
> ptr=0x0)
>     at fatfs_dent.c:754
> #11 0x0000000000420771 in fatfs_dent_parse_buf (fatfs=0x566400, 
> dinfo=0x7fffffffdd80,
>     buf=0xffffffffffffe788 <Address 0xffffffffffffe788 out of bounds>, 
> len=6144, addrs=0x1652000, flags=7, action=0x402530 <dent_act>, ptr=0x0)
>     at fatfs_dent.c:539
> 
> 
>                 /* append our name */
>                 if (dinfo->depth < MAX_DEPTH) {
>                     dinfo->didx[dinfo->depth] =
>                         &dinfo->dirs[strlen(dinfo->dirs)];
> =>                  strncpy(dinfo->didx[dinfo->depth], fs_dent->name,
>                         DIR_STRSZ - strlen(dinfo->dirs));
>                     strncat(dinfo->dirs, "/", DIR_STRSZ);
>                 }
> 
> (gdb) p dinfo->didx[53]
> $2 = 0x7fffffffe789 
> "\345\221\201\345\275\205\344\241\223\345\211\217\345\275\224\345\211\205\346\214\240\346\271\257\347\211\264\346\261\257\346\ 
> 
> \215\234\347\211\264\346\261\257"
> (gdb) p *fs_dent
> $3 = {name = 0x1666000 
> "\345\221\201\345\275\205\344\241\223\345\211\217\345\275\224\345\211\205\346\214\240\346\271\257\347\211\264\346\261\257\\ 
> 
> 346\215\234\347\211\264\346\261\257", name_max = 1024,
>   shrt_name = 0x563f00 ".", shrt_name_max = 32, inode = 40, fsi = 
> 0x164ec00, ent_type = 4 '\004',
>   path = 0x7fffffffdf88 
> "DOS/\345\221\201\345\275\205\344\241\223\345\211\217\345\275\224\345\211\205\346\214\240\346\271\257\347\211\264\346\261\ 
> 
> \257\346\215\234\347\211\264\346\261\257/\345\221\201\345\275\205\344\241\223\345\211\217\345\275\224\345\211\205\346\214\240\346\271\257\347\211\ 
> 
> \264\346\261\257\346\215\234\347\211\264\346\261\257/\345\221\201\345\275\205\344\241\223\345\211\217\345\275\224\345\211\205\346\214\240\346\271\ 
> 
> \257\347\211\264\346\261\257\346\215\234\347\211\264\346\261\257/\345\221\201\345\275\205\344\241\223\345\211\217\345\275\224\345\211\205\346\214\ 
> 
> \240\346\271\257\347\211\264\346\261\257\346\215\234\347\211\264\346\261\257/\345\221\201\345\275\205\344\241\223\345\211\217\345\275\224\345\211\ 
> 
> \205\346\214\240\346\271\257\347\211\264\346\261\257\346\215\234\347\211\264"..., 
> pathdepth = 53}
> (gdb)
> 
> 
> Looks like the structures on the disk are corrupt and the fatfs_dent.c 
> routine is being a little too trusting?
> 
> ===============================
> Image 471:
> (gdb) where
> #0  0x0000000000429427 in ntfs_secure_data_free (ntfs_info=0x566400) at 
> ntfs.c:3874
> #1  0x00000000004294d8 in ntfs_close (fs=0x566400) at ntfs.c:3896
> #2  0x0000000000402b0a in do_vol (img=0x564000, start=32256) at 
> iwalk.cpp:178
> #3  0x0000000000402b7c in mm_act (mm=0x564080, pnum=2, part=0x563180, 
> flag=0, ptr=0x44a304 "") at iwalk.cpp:195
> #4  0x00000000004342e0 in dos_part_walk (mm=0x564080, start=0, last=2, 
> flags=6, action=0x402b30 <mm_act>, ptr=0x44a304 "") at dos.c:1013
> #5  0x0000000000402c5e in do_dimage (img=0x564000, desc=0x44a406 "my 
> boring test comment") at iwalk.cpp:229
> #6  0x0000000000402e39 in main (argc=1, argv=0x7fffffffe988) at 
> iwalk.cpp:294
> (gdb)
> 
> 
> This looks like the same problem as Drive #193
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> 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-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

Re: [sleuthkit-users] more crashes

[Gary F. <ga...@in...>]

Simson Garfinkel wrote (in part):
> 
> and the code:
> static void
> ntfs_secure_data_free(NTFS_INFO * ntfs_info)
> {
>      // Iterate of sds entries and free them
>      while (ntfs_info->sds) {
> =>      free(ntfs_info->sds->data);
>          ntfs_info->sds = ntfs_info->sds->next;
>      }

Probably unrelated to the current problem, but it seems
taht the code above will cause ntfs_info->sds to traverse
down the next links until at the end, ntfs_info->sds will
be set to null.  However, the intermediate entries in the
list are not freed and unless these nodes are on some other
list, will become dangling references.  Is this intended?
Or does something like the following implement the specified
operation?

static void
ntfs_secure_data_free(NTFS_INFO * ntfs_info)
{
  NTFS_INFO *n, *nxt;
  // Iterate of sds entries and free them
  for (n = ntfs_info->sds; n; n = nxt)
    {
      if (n->data) free (n->data);
      nxt = n->next;
      free (n);
    }
  nfs_info->sds = 0;
}

Re: [sleuthkit-users] more crashes

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

Hello Simson,

Are these "Drive #xxx" something that is publicly available, or are they
internal references? 

Anyway, at least the first (and third) of the crashes you cite here could be
a similar problem as discussed previously, namely that ntfs_info->sds->data
could be NULL. If these problems have turned up in recent versions, it would
be reasonable to check any recent changes in the code that build these
structures. 

Regards,

Svein



> -----Original Message-----
> From: sle...@li... [mailto:sleuthkit-
> use...@li...] On Behalf Of Simson Garfinkel
> Sent: 24. august 2006 21:20
> To: sle...@li...
> Subject: [sleuthkit-users] more crashes
> 
> Drive #193 causes a crash at line 3874 of ntfs.c.
> 
> Here is the stack trace:
> 
> (gdb) where
> #0  0x0000000000429427 in ntfs_secure_data_free (ntfs_info=0x566400)
> at ntfs.c:3874
> #1  0x00000000004294d8 in ntfs_close (fs=0x566400) at ntfs.c:3896
> #2  0x0000000000402b0a in do_vol (img=0x564000, start=32256) at
> iwalk.cpp:178
> #3  0x0000000000402b7c in mm_act (mm=0x564080, pnum=2, part=0x563180,
> flag=0, ptr=0x44a304 "") at iwalk.cpp:195
> #4  0x00000000004342e0 in dos_part_walk (mm=0x564080, start=0,
> last=2, flags=6, action=0x402b30 <mm_act>, ptr=0x44a304 "") at dos.c:
> 1013
> #5  0x0000000000402c5e in do_dimage (img=0x564000, desc=0x44a406 "my
> boring test comment") at iwalk.cpp:229
> #6  0x0000000000402e39 in main (argc=1, argv=0x7fffffffe988) at
> iwalk.cpp:294
> (gdb)
> 
> 
> and the code:
> static void
> ntfs_secure_data_free(NTFS_INFO * ntfs_info)
> {
>      // Iterate of sds entries and free them
>      while (ntfs_info->sds) {
> =>      free(ntfs_info->sds->data);
>          ntfs_info->sds = ntfs_info->sds->next;
>      }
> 
> ==================
> Drive #248:
> 
> stack appears corrupted; this is what's on top:
> 
> #0  0x0000000800d9c020 in strncpy () from /lib/libc.so.6
> (gdb) where
> #0  0x0000000800d9c020 in strncpy () from /lib/libc.so.6
> #1  0x00000000004206f4 in fatfs_dent_parse_buf (fatfs=0x566400,
> dinfo=0x7fffffffdd80,
>      buf=0xffffffffffffe788 <Address 0xffffffffffffe788 out of
> bounds>, len=6144, addrs=0x1663000, flags=7, action=0x402530
> <dent_act>, ptr=0x0)
>      at fatfs_dent.c:521
> #2  0x0000000000420c46 in fatfs_dent_walk_lcl (fs=0x566400,
> dinfo=0x7fffffffdd80, inode=40, flags=7, action=0x402530 <dent_act>,
> ptr=0x0)
>      at fatfs_dent.c:754
> #3  0x0000000000420771 in fatfs_dent_parse_buf (fatfs=0x566400,
> dinfo=0x7fffffffdd80,
>      buf=0xffffffffffffe788 <Address 0xffffffffffffe788 out of
> bounds>, len=6144, addrs=0x1662000, flags=7, action=0x402530
> <dent_act>, ptr=0x0)
>      at fatfs_dent.c:539
> #4  0x0000000000420c46 in fatfs_dent_walk_lcl (fs=0x566400,
> dinfo=0x7fffffffdd80, inode=40, flags=7, action=0x402530 <dent_act>,
> ptr=0x0)
>      at fatfs_dent.c:754
> #5  0x0000000000420771 in fatfs_dent_parse_buf (fatfs=0x566400,
> dinfo=0x7fffffffdd80,
>      buf=0xffffffffffffe788 <Address 0xffffffffffffe788 out of
> bounds>, len=6144, addrs=0x165b000, flags=7, action=0x402530
> <dent_act>, ptr=0x0)
>      at fatfs_dent.c:539
> #6  0x0000000000420c46 in fatfs_dent_walk_lcl (fs=0x566400,
> dinfo=0x7fffffffdd80, inode=40, flags=7, action=0x402530 <dent_act>,
> ptr=0x0)
>      at fatfs_dent.c:754
> #7  0x0000000000420771 in fatfs_dent_parse_buf (fatfs=0x566400,
> dinfo=0x7fffffffdd80,
>      buf=0xffffffffffffe788 <Address 0xffffffffffffe788 out of
> bounds>, len=6144, addrs=0x165a000, flags=7, action=0x402530
> <dent_act>, ptr=0x0)
>      at fatfs_dent.c:539
> #8  0x0000000000420c46 in fatfs_dent_walk_lcl (fs=0x566400,
> dinfo=0x7fffffffdd80, inode=40, flags=7, action=0x402530 <dent_act>,
> ptr=0x0)
>      at fatfs_dent.c:754
> #9  0x0000000000420771 in fatfs_dent_parse_buf (fatfs=0x566400,
> dinfo=0x7fffffffdd80,
>      buf=0xffffffffffffe788 <Address 0xffffffffffffe788 out of
> bounds>, len=6144, addrs=0x1653000, flags=7, action=0x402530
> <dent_act>, ptr=0x0)
>      at fatfs_dent.c:539
> #10 0x0000000000420c46 in fatfs_dent_walk_lcl (fs=0x566400,
> dinfo=0x7fffffffdd80, inode=40, flags=7, action=0x402530 <dent_act>,
> ptr=0x0)
>      at fatfs_dent.c:754
> #11 0x0000000000420771 in fatfs_dent_parse_buf (fatfs=0x566400,
> dinfo=0x7fffffffdd80,
>      buf=0xffffffffffffe788 <Address 0xffffffffffffe788 out of
> bounds>, len=6144, addrs=0x1652000, flags=7, action=0x402530
> <dent_act>, ptr=0x0)
>      at fatfs_dent.c:539
> 
> 
>                  /* append our name */
>                  if (dinfo->depth < MAX_DEPTH) {
>                      dinfo->didx[dinfo->depth] =
>                          &dinfo->dirs[strlen(dinfo->dirs)];
> =>                  strncpy(dinfo->didx[dinfo->depth], fs_dent->name,
>                          DIR_STRSZ - strlen(dinfo->dirs));
>                      strncat(dinfo->dirs, "/", DIR_STRSZ);
>                  }
> 
> (gdb) p dinfo->didx[53]
> $2 = 0x7fffffffe789 "\345\221\201\345\275\205\344\241\223\345\211\217
> \345\275\224\345\211\205\346\214\240\346\271\257\347\211\264\346\261
> \257\346\
> \215\234\347\211\264\346\261\257"
> (gdb) p *fs_dent
> $3 = {name = 0x1666000 "\345\221\201\345\275\205\344\241\223\345\211
> \217\345\275\224\345\211\205\346\214\240\346\271\257\347\211\264\346
> \261\257\\
> 346\215\234\347\211\264\346\261\257", name_max = 1024,
>    shrt_name = 0x563f00 ".", shrt_name_max = 32, inode = 40, fsi =
> 0x164ec00, ent_type = 4 '\004',
>    path = 0x7fffffffdf88 "DOS/\345\221\201\345\275\205\344\241\223\345
> \211\217\345\275\224\345\211\205\346\214\240\346\271\257\347\211\264
> \346\261\
> \257\346\215\234\347\211\264\346\261\257/\345\221\201\345\275\205\344
> \241\223\345\211\217\345\275\224\345\211\205\346\214\240\346\271\257
> \347\211\
> \264\346\261\257\346\215\234\347\211\264\346\261\257/\345\221\201\345
> \275\205\344\241\223\345\211\217\345\275\224\345\211\205\346\214\240
> \346\271\
> \257\347\211\264\346\261\257\346\215\234\347\211\264\346\261\257/\345
> \221\201\345\275\205\344\241\223\345\211\217\345\275\224\345\211\205
> \346\214\
> \240\346\271\257\347\211\264\346\261\257\346\215\234\347\211\264\346
> \261\257/\345\221\201\345\275\205\344\241\223\345\211\217\345\275\224
> \345\211\
> \205\346\214\240\346\271\257\347\211\264\346\261\257\346\215\234\347
> \211\264"..., pathdepth = 53}
> (gdb)
> 
> 
> Looks like the structures on the disk are corrupt and the
> fatfs_dent.c routine is being a little too trusting?
> 
> ===============================
> Image 471:
> (gdb) where
> #0  0x0000000000429427 in ntfs_secure_data_free (ntfs_info=0x566400)
> at ntfs.c:3874
> #1  0x00000000004294d8 in ntfs_close (fs=0x566400) at ntfs.c:3896
> #2  0x0000000000402b0a in do_vol (img=0x564000, start=32256) at
> iwalk.cpp:178
> #3  0x0000000000402b7c in mm_act (mm=0x564080, pnum=2, part=0x563180,
> flag=0, ptr=0x44a304 "") at iwalk.cpp:195
> #4  0x00000000004342e0 in dos_part_walk (mm=0x564080, start=0,
> last=2, flags=6, action=0x402b30 <mm_act>, ptr=0x44a304 "") at dos.c:
> 1013
> #5  0x0000000000402c5e in do_dimage (img=0x564000, desc=0x44a406 "my
> boring test comment") at iwalk.cpp:229
> #6  0x0000000000402e39 in main (argc=1, argv=0x7fffffffe988) at
> iwalk.cpp:294
> (gdb)
> 
> 
> This looks like the same problem as Drive #193

[sleuthkit-users] more crashes

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

Drive #193 causes a crash at line 3874 of ntfs.c.

Here is the stack trace:

(gdb) where
#0  0x0000000000429427 in ntfs_secure_data_free (ntfs_info=0x566400)  
at ntfs.c:3874
#1  0x00000000004294d8 in ntfs_close (fs=0x566400) at ntfs.c:3896
#2  0x0000000000402b0a in do_vol (img=0x564000, start=32256) at  
iwalk.cpp:178
#3  0x0000000000402b7c in mm_act (mm=0x564080, pnum=2, part=0x563180,  
flag=0, ptr=0x44a304 "") at iwalk.cpp:195
#4  0x00000000004342e0 in dos_part_walk (mm=0x564080, start=0,  
last=2, flags=6, action=0x402b30 <mm_act>, ptr=0x44a304 "") at dos.c: 
1013
#5  0x0000000000402c5e in do_dimage (img=0x564000, desc=0x44a406 "my  
boring test comment") at iwalk.cpp:229
#6  0x0000000000402e39 in main (argc=1, argv=0x7fffffffe988) at  
iwalk.cpp:294
(gdb)


and the code:
static void
ntfs_secure_data_free(NTFS_INFO * ntfs_info)
{
     // Iterate of sds entries and free them
     while (ntfs_info->sds) {
=>      free(ntfs_info->sds->data);
         ntfs_info->sds = ntfs_info->sds->next;
     }

==================
Drive #248:

stack appears corrupted; this is what's on top:

#0  0x0000000800d9c020 in strncpy () from /lib/libc.so.6
(gdb) where
#0  0x0000000800d9c020 in strncpy () from /lib/libc.so.6
#1  0x00000000004206f4 in fatfs_dent_parse_buf (fatfs=0x566400,  
dinfo=0x7fffffffdd80,
     buf=0xffffffffffffe788 <Address 0xffffffffffffe788 out of  
bounds>, len=6144, addrs=0x1663000, flags=7, action=0x402530  
<dent_act>, ptr=0x0)
     at fatfs_dent.c:521
#2  0x0000000000420c46 in fatfs_dent_walk_lcl (fs=0x566400,  
dinfo=0x7fffffffdd80, inode=40, flags=7, action=0x402530 <dent_act>,  
ptr=0x0)
     at fatfs_dent.c:754
#3  0x0000000000420771 in fatfs_dent_parse_buf (fatfs=0x566400,  
dinfo=0x7fffffffdd80,
     buf=0xffffffffffffe788 <Address 0xffffffffffffe788 out of  
bounds>, len=6144, addrs=0x1662000, flags=7, action=0x402530  
<dent_act>, ptr=0x0)
     at fatfs_dent.c:539
#4  0x0000000000420c46 in fatfs_dent_walk_lcl (fs=0x566400,  
dinfo=0x7fffffffdd80, inode=40, flags=7, action=0x402530 <dent_act>,  
ptr=0x0)
     at fatfs_dent.c:754
#5  0x0000000000420771 in fatfs_dent_parse_buf (fatfs=0x566400,  
dinfo=0x7fffffffdd80,
     buf=0xffffffffffffe788 <Address 0xffffffffffffe788 out of  
bounds>, len=6144, addrs=0x165b000, flags=7, action=0x402530  
<dent_act>, ptr=0x0)
     at fatfs_dent.c:539
#6  0x0000000000420c46 in fatfs_dent_walk_lcl (fs=0x566400,  
dinfo=0x7fffffffdd80, inode=40, flags=7, action=0x402530 <dent_act>,  
ptr=0x0)
     at fatfs_dent.c:754
#7  0x0000000000420771 in fatfs_dent_parse_buf (fatfs=0x566400,  
dinfo=0x7fffffffdd80,
     buf=0xffffffffffffe788 <Address 0xffffffffffffe788 out of  
bounds>, len=6144, addrs=0x165a000, flags=7, action=0x402530  
<dent_act>, ptr=0x0)
     at fatfs_dent.c:539
#8  0x0000000000420c46 in fatfs_dent_walk_lcl (fs=0x566400,  
dinfo=0x7fffffffdd80, inode=40, flags=7, action=0x402530 <dent_act>,  
ptr=0x0)
     at fatfs_dent.c:754
#9  0x0000000000420771 in fatfs_dent_parse_buf (fatfs=0x566400,  
dinfo=0x7fffffffdd80,
     buf=0xffffffffffffe788 <Address 0xffffffffffffe788 out of  
bounds>, len=6144, addrs=0x1653000, flags=7, action=0x402530  
<dent_act>, ptr=0x0)
     at fatfs_dent.c:539
#10 0x0000000000420c46 in fatfs_dent_walk_lcl (fs=0x566400,  
dinfo=0x7fffffffdd80, inode=40, flags=7, action=0x402530 <dent_act>,  
ptr=0x0)
     at fatfs_dent.c:754
#11 0x0000000000420771 in fatfs_dent_parse_buf (fatfs=0x566400,  
dinfo=0x7fffffffdd80,
     buf=0xffffffffffffe788 <Address 0xffffffffffffe788 out of  
bounds>, len=6144, addrs=0x1652000, flags=7, action=0x402530  
<dent_act>, ptr=0x0)
     at fatfs_dent.c:539


                 /* append our name */
                 if (dinfo->depth < MAX_DEPTH) {
                     dinfo->didx[dinfo->depth] =
                         &dinfo->dirs[strlen(dinfo->dirs)];
=>                  strncpy(dinfo->didx[dinfo->depth], fs_dent->name,
                         DIR_STRSZ - strlen(dinfo->dirs));
                     strncat(dinfo->dirs, "/", DIR_STRSZ);
                 }

(gdb) p dinfo->didx[53]
$2 = 0x7fffffffe789 "\345\221\201\345\275\205\344\241\223\345\211\217 
\345\275\224\345\211\205\346\214\240\346\271\257\347\211\264\346\261 
\257\346\
\215\234\347\211\264\346\261\257"
(gdb) p *fs_dent
$3 = {name = 0x1666000 "\345\221\201\345\275\205\344\241\223\345\211 
\217\345\275\224\345\211\205\346\214\240\346\271\257\347\211\264\346 
\261\257\\
346\215\234\347\211\264\346\261\257", name_max = 1024,
   shrt_name = 0x563f00 ".", shrt_name_max = 32, inode = 40, fsi =  
0x164ec00, ent_type = 4 '\004',
   path = 0x7fffffffdf88 "DOS/\345\221\201\345\275\205\344\241\223\345 
\211\217\345\275\224\345\211\205\346\214\240\346\271\257\347\211\264 
\346\261\
\257\346\215\234\347\211\264\346\261\257/\345\221\201\345\275\205\344 
\241\223\345\211\217\345\275\224\345\211\205\346\214\240\346\271\257 
\347\211\
\264\346\261\257\346\215\234\347\211\264\346\261\257/\345\221\201\345 
\275\205\344\241\223\345\211\217\345\275\224\345\211\205\346\214\240 
\346\271\
\257\347\211\264\346\261\257\346\215\234\347\211\264\346\261\257/\345 
\221\201\345\275\205\344\241\223\345\211\217\345\275\224\345\211\205 
\346\214\
\240\346\271\257\347\211\264\346\261\257\346\215\234\347\211\264\346 
\261\257/\345\221\201\345\275\205\344\241\223\345\211\217\345\275\224 
\345\211\
\205\346\214\240\346\271\257\347\211\264\346\261\257\346\215\234\347 
\211\264"..., pathdepth = 53}
(gdb)


Looks like the structures on the disk are corrupt and the  
fatfs_dent.c routine is being a little too trusting?

===============================
Image 471:
(gdb) where
#0  0x0000000000429427 in ntfs_secure_data_free (ntfs_info=0x566400)  
at ntfs.c:3874
#1  0x00000000004294d8 in ntfs_close (fs=0x566400) at ntfs.c:3896
#2  0x0000000000402b0a in do_vol (img=0x564000, start=32256) at  
iwalk.cpp:178
#3  0x0000000000402b7c in mm_act (mm=0x564080, pnum=2, part=0x563180,  
flag=0, ptr=0x44a304 "") at iwalk.cpp:195
#4  0x00000000004342e0 in dos_part_walk (mm=0x564080, start=0,  
last=2, flags=6, action=0x402b30 <mm_act>, ptr=0x44a304 "") at dos.c: 
1013
#5  0x0000000000402c5e in do_dimage (img=0x564000, desc=0x44a406 "my  
boring test comment") at iwalk.cpp:229
#6  0x0000000000402e39 in main (argc=1, argv=0x7fffffffe988) at  
iwalk.cpp:294
(gdb)


This looks like the same problem as Drive #193

Re: [sleuthkit-users] Autopsy: The image format type could not be determined for this image file

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

Ok, I'll make it a command line argument.   Default is nothing in the  
path.

brian

On Aug 23, 2006, at 4:04 PM, Angus Marshall wrote:

> Brian - I think this should be a user configurable option please.  
> There are situations where I would not want to have the standard  
> binaries
> available to Autopsy.
>
> On Wed Aug 23 16:51 , Brian Carrier <ca...@sl...> sent:
>
>> Ahh, of course. I commented out the line that clears the path, but I
>> didn't try to reset it with a Unix-like path. I'll update autopsy to
>> include the standard bin directories instead of simply clearing it.
>>
>> brian
>>
>>
>> DePriest, Jason R. wrote:
>>> I change my autopsy file from
>>> # remove environment stuff that we don't need and that could be  
>>> insecure
>>> $ENV{PATH} = '';
>>> to
>>> # remove environment stuff that we don't need and that could be  
>>> insecure
>>> $ENV{PATH} = '/usr/local/bin:/usr/bin:/bin:/usr/lib/lapack';
>>> delete @ENV{'IFS', 'CDPATH', 'ENV', 'BASH_ENV'};
>>>
>>> Of course, this does indeed make it less secure, but it works  
>>> without
>>> copying files over to another directory.
>>>
>>> On 8/23/06, Brian Carrier  wrote:
>>>> I just tried this and got similar results, except that I got a  
>>>> Windows
>>>> dialog box saying that cygcrypto-0.9.8.dll was not found and then
>>>> Autopsy reported that the image type could not be detected (likely
>>>> because img_stat could not run).
>>>>
>>>> Based on the Using TSK/Autopsy with Cygwin doc:
>>>>
>>>> http://www.sleuthkit.org/sleuthkit/docs/lucas_cygwin.pdf
>>>>
>>>> I started to copy the missing dll files into the TSK bin directory.
>>>> After 3 or 4 files, it eventually worked.
>>>>
>>>> Any cygwin experts here that can tell me how to make this process
>>>> easier?  I updated my system path to include c:\cygwin\bin (which
>>>> contains the needed dlls), but it didn't help.
>>>>
>>>> brian
>>>>
>>>>
>>>> John Lehr wrote:
>>>>>> Why are you using TSK 2.05 with AFF 1.6.26? It was released  
>>>>>> with 1.6.28.  Are the images from DFTT?
>>>>> I was following some instructions you posted for Cygwin... I  
>>>>> thought that it might be version dependent.  I have since  
>>>>> recompiled with v.
> 1.6.31 with the same results.
>>>>>
>>>>>> Are the images from DFTT?
>>>>> Yes, from http://dftt.sourceforge.net/.  I also tried Barry  
>>>>> Grundy's practical.floppy.dd image from ftp://ftp.hq.nasa.gov/ 
>>>>> pub/ig/ccd/
> linuxintro/ and received the same error message (I'm looking to  
> start out with TSK using some known images).
>>>>>
>>>>>> Make sure you have the correct "volume" image versus "disk"  
>>>>>> image.
>>>>> I know the difference, but tried both anyway: same error message.
>>>
>>> -------------------------------------------------------------------- 
>>> -----
>>> 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-users mailing list
>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>>> http://www.sleuthkit.org
>>
>> --------------------------------------------------------------------- 
>> ----
>> 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-users mailing list
>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>> http://www.sleuthkit.org
>
>
> ---------------------------------------------------------------------- 
> ---
> 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-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

Re: [sleuthkit-users] Autopsy: The image format type could not be determined for this image file

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

Brian - I think this should be a user configurable option please. There are situations where I would not want to have the standard binaries 
available to Autopsy.

On Wed Aug 23 16:51 , Brian Carrier <ca...@sl...> sent:

>Ahh, of course. I commented out the line that clears the path, but I 
>didn't try to reset it with a Unix-like path. I'll update autopsy to 
>include the standard bin directories instead of simply clearing it.
>
>brian
>
>
>DePriest, Jason R. wrote:
>> I change my autopsy file from
>> # remove environment stuff that we don't need and that could be insecure
>> $ENV{PATH} = '';
>> to
>> # remove environment stuff that we don't need and that could be insecure
>> $ENV{PATH} = '/usr/local/bin:/usr/bin:/bin:/usr/lib/lapack';
>> delete @ENV{'IFS', 'CDPATH', 'ENV', 'BASH_ENV'};
>> 
>> Of course, this does indeed make it less secure, but it works without
>> copying files over to another directory.
>> 
>> On 8/23/06, Brian Carrier  wrote:
>>> I just tried this and got similar results, except that I got a Windows
>>> dialog box saying that cygcrypto-0.9.8.dll was not found and then
>>> Autopsy reported that the image type could not be detected (likely
>>> because img_stat could not run).
>>>
>>> Based on the Using TSK/Autopsy with Cygwin doc:
>>>
>>> http://www.sleuthkit.org/sleuthkit/docs/lucas_cygwin.pdf
>>>
>>> I started to copy the missing dll files into the TSK bin directory.
>>> After 3 or 4 files, it eventually worked.
>>>
>>> Any cygwin experts here that can tell me how to make this process
>>> easier?  I updated my system path to include c:\cygwin\bin (which
>>> contains the needed dlls), but it didn't help.
>>>
>>> brian
>>>
>>>
>>> John Lehr wrote:
>>>>> Why are you using TSK 2.05 with AFF 1.6.26? It was released with 1.6.28.  Are the images from DFTT?
>>>> I was following some instructions you posted for Cygwin... I thought that it might be version dependent.  I have since recompiled with v. 
1.6.31 with the same results.
>>>>
>>>>> Are the images from DFTT?
>>>> Yes, from http://dftt.sourceforge.net/.  I also tried Barry Grundy's practical.floppy.dd image from ftp://ftp.hq.nasa.gov/pub/ig/ccd/
linuxintro/ and received the same error message (I'm looking to start out with TSK using some known images).
>>>>
>>>>> Make sure you have the correct "volume" image versus "disk" image.
>>>> I know the difference, but tried both anyway: same error message.
>> 
>> -------------------------------------------------------------------------
>> 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-users mailing list
>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>> http://www.sleuthkit.org
>
>-------------------------------------------------------------------------
>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-users mailing list
>https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>http://www.sleuthkit.org

Re: [sleuthkit-users] Autopsy: The image format type could not be determined for this image file

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

Ahh, of course. I commented out the line that clears the path, but I 
didn't try to reset it with a Unix-like path. I'll update autopsy to 
include the standard bin directories instead of simply clearing it.

brian


DePriest, Jason R. wrote:
> I change my autopsy file from
> # remove environment stuff that we don't need and that could be insecure
> $ENV{PATH} = '';
> to
> # remove environment stuff that we don't need and that could be insecure
> $ENV{PATH} = '/usr/local/bin:/usr/bin:/bin:/usr/lib/lapack';
> delete @ENV{'IFS', 'CDPATH', 'ENV', 'BASH_ENV'};
> 
> Of course, this does indeed make it less secure, but it works without
> copying files over to another directory.
> 
> On 8/23/06, Brian Carrier <> wrote:
>> I just tried this and got similar results, except that I got a Windows
>> dialog box saying that cygcrypto-0.9.8.dll was not found and then
>> Autopsy reported that the image type could not be detected (likely
>> because img_stat could not run).
>>
>> Based on the Using TSK/Autopsy with Cygwin doc:
>>
>> http://www.sleuthkit.org/sleuthkit/docs/lucas_cygwin.pdf
>>
>> I started to copy the missing dll files into the TSK bin directory.
>> After 3 or 4 files, it eventually worked.
>>
>> Any cygwin experts here that can tell me how to make this process
>> easier?  I updated my system path to include c:\cygwin\bin (which
>> contains the needed dlls), but it didn't help.
>>
>> brian
>>
>>
>> John Lehr wrote:
>>>> Why are you using TSK 2.05 with AFF 1.6.26? It was released with 1.6.28.  Are the images from DFTT?
>>> I was following some instructions you posted for Cygwin... I thought that it might be version dependent.  I have since recompiled with v. 1.6.31 with the same results.
>>>
>>>> Are the images from DFTT?
>>> Yes, from http://dftt.sourceforge.net/.  I also tried Barry Grundy's practical.floppy.dd image from ftp://ftp.hq.nasa.gov/pub/ig/ccd/linuxintro/ and received the same error message (I'm looking to start out with TSK using some known images).
>>>
>>>> Make sure you have the correct "volume" image versus "disk" image.
>>> I know the difference, but tried both anyway: same error message.
> 
> -------------------------------------------------------------------------
> 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-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

Re: [sleuthkit-users] Autopsy: The image format type could not be determined for this image file

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

I change my autopsy file from
# remove environment stuff that we don't need and that could be insecure
$ENV{PATH} = '';
to
# remove environment stuff that we don't need and that could be insecure
$ENV{PATH} = '/usr/local/bin:/usr/bin:/bin:/usr/lib/lapack';
delete @ENV{'IFS', 'CDPATH', 'ENV', 'BASH_ENV'};

Of course, this does indeed make it less secure, but it works without
copying files over to another directory.

On 8/23/06, Brian Carrier <> wrote:
> I just tried this and got similar results, except that I got a Windows
> dialog box saying that cygcrypto-0.9.8.dll was not found and then
> Autopsy reported that the image type could not be detected (likely
> because img_stat could not run).
>
> Based on the Using TSK/Autopsy with Cygwin doc:
>
> http://www.sleuthkit.org/sleuthkit/docs/lucas_cygwin.pdf
>
> I started to copy the missing dll files into the TSK bin directory.
> After 3 or 4 files, it eventually worked.
>
> Any cygwin experts here that can tell me how to make this process
> easier?  I updated my system path to include c:\cygwin\bin (which
> contains the needed dlls), but it didn't help.
>
> brian
>
>
> John Lehr wrote:
> >> Why are you using TSK 2.05 with AFF 1.6.26? It was released with 1.6.28.  Are the images from DFTT?
> >
> > I was following some instructions you posted for Cygwin... I thought that it might be version dependent.  I have since recompiled with v. 1.6.31 with the same results.
> >
> >> Are the images from DFTT?
> >
> > Yes, from http://dftt.sourceforge.net/.  I also tried Barry Grundy's practical.floppy.dd image from ftp://ftp.hq.nasa.gov/pub/ig/ccd/linuxintro/ and received the same error message (I'm looking to start out with TSK using some known images).
> >
> >> Make sure you have the correct "volume" image versus "disk" image.
> >
> > I know the difference, but tried both anyway: same error message.

Re: [sleuthkit-users] Autopsy: The image format type could not be determined for this image file

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

I just tried this and got similar results, except that I got a Windows 
dialog box saying that cygcrypto-0.9.8.dll was not found and then 
Autopsy reported that the image type could not be detected (likely 
because img_stat could not run).

Based on the Using TSK/Autopsy with Cygwin doc:

http://www.sleuthkit.org/sleuthkit/docs/lucas_cygwin.pdf

I started to copy the missing dll files into the TSK bin directory. 
After 3 or 4 files, it eventually worked.

Any cygwin experts here that can tell me how to make this process 
easier?  I updated my system path to include c:\cygwin\bin (which 
contains the needed dlls), but it didn't help.

brian


John Lehr wrote:
>> Why are you using TSK 2.05 with AFF 1.6.26? It was released with 1.6.28.  Are the images from DFTT?
> 
> I was following some instructions you posted for Cygwin... I thought that it might be version dependent.  I have since recompiled with v. 1.6.31 with the same results.
> 
>> Are the images from DFTT?
> 
> Yes, from http://dftt.sourceforge.net/.  I also tried Barry Grundy's practical.floppy.dd image from ftp://ftp.hq.nasa.gov/pub/ig/ccd/linuxintro/ and received the same error message (I'm looking to start out with TSK using some known images).
> 
>> Make sure you have the correct "volume" image versus "disk" image.
> 
> I know the difference, but tried both anyway: same error message.

Re: [sleuthkit-users] crash in fs_inode.c:96 TSK 2.05

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

I'm not sure when this bug was introduced, but it didn't exist a couple 
of versions ago.  Anyway, a couple of other users reported it a few 
weeks ago and it is fixed in the next release, which should be at the 
end of this week or early next week.

thanks,
brian

Simson Garfinkel wrote:
> Okay. Here is the correct code, starting at line 287:
> 
>             /* we know deleted entries with an inode of 0 are not legit 
> because
>              * that is the MFT value.  Free it so it does not confuse
>              * people with invalid data
>              */
>             if (fs_dent->inode == 0) {
> +                if(fs_dent->fsi != NULL){
>                     fs_inode_free(fs_dent->fsi);
>                     fs_dent->fsi = NULL;
> +                }
>             }
> 
> (I also patched fs_inode_free() to just return if it got a NUL. Now I 
> understand that it's getting a NULL because 0 is a special MFT value.)
> 
> On Aug 23, 2006, at 6:02 AM, Svein Yngvar Willassen wrote:
> 
>> Pardon; those line numbers came from my modified version. The call to
>> fs_inode_free is at line 288:
>>
>>        /* we know deleted entries with an inode of 0 are not legit
>> because
>>          * that is the MFT value.  Free it so it does not confuse
>>          * people with invalid data
>>          */
>>         if (fs_dent->inode == 0) {
>>         fs_inode_free(fs_dent->fsi);      <----
>>         fs_dent->fsi = NULL;
>>         }
>>
>> Svein
>>
>>
>>> -----Original Message-----
>>> From: sle...@li... [mailto:sleuthkit-
>>> use...@li...] On Behalf Of Svein Yngvar Willassen
>>> Sent: 23. august 2006 14:56
>>> To: sle...@li...
>>> Subject: Re: [sleuthkit-users] crash in fs_inode.c:96 TSK 2.05
>>>
>>> Apparently fs_inode is NULL. In your case it's called from line 305 in
>>> ntfs.dent.c.
>>>
>>> I notice there's a check for fs_inode != NULL in the call to 
>>> fs_inode_free
>>> at line 97.  There should probably be a similar check at line 305.  
>>> Such a
>>> check should at least eliminate your current crash.
>>>
>>> Regards,
>>>
>>> Svein Willassen
>>>
>>>
>>>> -----Original Message-----
>>>> From: sle...@li... [mailto:sleuthkit-
>>>> use...@li...] On Behalf Of Simson Garfinkel
>>>> Sent: 23. august 2006 14:41
>>>> To: sle...@li...
>>>> Subject: [sleuthkit-users] crash in fs_inode.c:96 TSK 2.05
>>>>
>>>> I have an image to generates a crash in the ntfs_dent_idxentry()
>>>> function.
>>>>
>>>> Here is the stack trace:
>>>>
>>>> (gdb) where
>>>> #0  fs_inode_free (fs_inode=0x0) at fs_inode.c:96
>>>> #1  0x000000000042adf7 in ntfs_dent_idxentry (ntfs=0x566400,
>>>> dinfo=0x7fffffffdda0, idxe=0x1e57040, size=4032, len=31813712, flags=7,
>>>>      action=0x402530 <dent_act>, ptr=0x0) at ntfs_dent.c:288
>>>> #2  0x000000000042bf5c in ntfs_dent_walk_lcl (fs=0x566400,
>>>> dinfo=0x7fffffffdda0, inum=31817728, flags=7, action=0x402530
>>>> <dent_act>, ptr=0x0)
>>>>      at ntfs_dent.c:818
>>>> #3  0x000000000042af54 in ntfs_dent_idxentry (ntfs=0x566400,
>>>> dinfo=0x7fffffffdda0, idxe=0x15787e8, size=4032, len=22513656, flags=7,
>>>>      action=0x402530 <dent_act>, ptr=0x0) at ntfs_dent.c:327
>>>> #4  0x000000000042bf5c in ntfs_dent_walk_lcl (fs=0x566400,
>>>> dinfo=0x7fffffffdda0, inum=22515712, flags=7, action=0x402530
>>>> <dent_act>, ptr=0x0)
>>>>      at ntfs_dent.c:818
>>>> #5  0x000000000042af54 in ntfs_dent_idxentry (ntfs=0x566400,
>>>> dinfo=0x7fffffffdda0, idxe=0x1573458, size=4032, len=22492264, flags=7,
>>>>      action=0x402530 <dent_act>, ptr=0x0) at ntfs_dent.c:327
>>>> #6  0x000000000042c142 in ntfs_dent_walk_lcl (fs=0x566400,
>>>> dinfo=0x7fffffffdda0, inum=4203824, flags=7, action=0x402530
>>>> <dent_act>, ptr=0x0)
>>>>      at ntfs_dent.c:863
>>>> #7  0x000000000042b3ad in ntfs_dent_walk (fs=0x566400, inum=5,
>>>> flags=7, action=0x402530 <dent_act>, ptr=0x0) at ntfs_dent.c:464
>>>> #8  0x0000000000402ae2 in do_vol (img=0x564000, start=32256) at
>>>> iwalk.cpp:170
>>>> #9  0x0000000000402b7c in mm_act (mm=0x564080, pnum=2, part=0x563180,
>>>> flag=0, ptr=0x44a304 "") at iwalk.cpp:195
>>>> #10 0x00000000004342e0 in dos_part_walk (mm=0x564080, start=0,
>>>> last=4, flags=10, action=0x402b30 <mm_act>, ptr=0x44a304 "") at dos.c:
>>>> 1013
>>>> #11 0x0000000000402c5e in do_dimage (img=0x564000, desc=0x44a406 "my
>>>> boring test comment") at iwalk.cpp:229
>>>> #12 0x0000000000402e39 in main (argc=1, argv=0x7fffffffe988) at
>>>> iwalk.cpp:294
>>>> (gdb)
>>>>
>>>> And here is the code itself:
>>>>
>>>> /* fs_inode_free - destroy generic inode structure */
>>>>
>>>> void
>>>> fs_inode_free(FS_INODE * fs_inode)
>>>> {
>>>>      FS_NAME *fs_name, *fs_name2;
>>>>
>>>> =>  if (fs_inode->direct_addr)
>>>>          free((char *) fs_inode->direct_addr);
>>>>      fs_inode->direct_addr = NULL;
>>>>
>>>>      if (fs_inode->indir_addr)
>>>>          free((char *) fs_inode->indir_addr);
>>>>      fs_inode->indir_addr = NULL;
>>>>
>>>>
>>>> Any ideas?
>>>>
>>>> This is TSK 2.05

Re: [sleuthkit-users] crash in fs_inode.c:96 TSK 2.05

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

Okay. Here is the correct code, starting at line 287:

             /* we know deleted entries with an inode of 0 are not  
legit because
              * that is the MFT value.  Free it so it does not confuse
              * people with invalid data
              */
             if (fs_dent->inode == 0) {
+                if(fs_dent->fsi != NULL){
                     fs_inode_free(fs_dent->fsi);
                     fs_dent->fsi = NULL;
+                }
             }

(I also patched fs_inode_free() to just return if it got a NUL. Now I  
understand that it's getting a NULL because 0 is a special MFT value.)

On Aug 23, 2006, at 6:02 AM, Svein Yngvar Willassen wrote:

> Pardon; those line numbers came from my modified version. The call to
> fs_inode_free is at line 288:
>
> 	   /* we know deleted entries with an inode of 0 are not legit
> because
> 	     * that is the MFT value.  Free it so it does not confuse
> 	     * people with invalid data
> 	     */
> 	    if (fs_dent->inode == 0) {
> 		fs_inode_free(fs_dent->fsi);      <----
> 		fs_dent->fsi = NULL;
> 	    }
>
> Svein
>
>
>> -----Original Message-----
>> From: sle...@li...  
>> [mailto:sleuthkit-
>> use...@li...] On Behalf Of Svein Yngvar  
>> Willassen
>> Sent: 23. august 2006 14:56
>> To: sle...@li...
>> Subject: Re: [sleuthkit-users] crash in fs_inode.c:96 TSK 2.05
>>
>> Apparently fs_inode is NULL. In your case it's called from line  
>> 305 in
>> ntfs.dent.c.
>>
>> I notice there's a check for fs_inode != NULL in the call to  
>> fs_inode_free
>> at line 97.  There should probably be a similar check at line  
>> 305.  Such a
>> check should at least eliminate your current crash.
>>
>> Regards,
>>
>> Svein Willassen
>>
>>
>>> -----Original Message-----
>>> From: sle...@li...  
>>> [mailto:sleuthkit-
>>> use...@li...] On Behalf Of Simson Garfinkel
>>> Sent: 23. august 2006 14:41
>>> To: sle...@li...
>>> Subject: [sleuthkit-users] crash in fs_inode.c:96 TSK 2.05
>>>
>>> I have an image to generates a crash in the ntfs_dent_idxentry()
>>> function.
>>>
>>> Here is the stack trace:
>>>
>>> (gdb) where
>>> #0  fs_inode_free (fs_inode=0x0) at fs_inode.c:96
>>> #1  0x000000000042adf7 in ntfs_dent_idxentry (ntfs=0x566400,
>>> dinfo=0x7fffffffdda0, idxe=0x1e57040, size=4032, len=31813712,  
>>> flags=7,
>>>      action=0x402530 <dent_act>, ptr=0x0) at ntfs_dent.c:288
>>> #2  0x000000000042bf5c in ntfs_dent_walk_lcl (fs=0x566400,
>>> dinfo=0x7fffffffdda0, inum=31817728, flags=7, action=0x402530
>>> <dent_act>, ptr=0x0)
>>>      at ntfs_dent.c:818
>>> #3  0x000000000042af54 in ntfs_dent_idxentry (ntfs=0x566400,
>>> dinfo=0x7fffffffdda0, idxe=0x15787e8, size=4032, len=22513656,  
>>> flags=7,
>>>      action=0x402530 <dent_act>, ptr=0x0) at ntfs_dent.c:327
>>> #4  0x000000000042bf5c in ntfs_dent_walk_lcl (fs=0x566400,
>>> dinfo=0x7fffffffdda0, inum=22515712, flags=7, action=0x402530
>>> <dent_act>, ptr=0x0)
>>>      at ntfs_dent.c:818
>>> #5  0x000000000042af54 in ntfs_dent_idxentry (ntfs=0x566400,
>>> dinfo=0x7fffffffdda0, idxe=0x1573458, size=4032, len=22492264,  
>>> flags=7,
>>>      action=0x402530 <dent_act>, ptr=0x0) at ntfs_dent.c:327
>>> #6  0x000000000042c142 in ntfs_dent_walk_lcl (fs=0x566400,
>>> dinfo=0x7fffffffdda0, inum=4203824, flags=7, action=0x402530
>>> <dent_act>, ptr=0x0)
>>>      at ntfs_dent.c:863
>>> #7  0x000000000042b3ad in ntfs_dent_walk (fs=0x566400, inum=5,
>>> flags=7, action=0x402530 <dent_act>, ptr=0x0) at ntfs_dent.c:464
>>> #8  0x0000000000402ae2 in do_vol (img=0x564000, start=32256) at
>>> iwalk.cpp:170
>>> #9  0x0000000000402b7c in mm_act (mm=0x564080, pnum=2,  
>>> part=0x563180,
>>> flag=0, ptr=0x44a304 "") at iwalk.cpp:195
>>> #10 0x00000000004342e0 in dos_part_walk (mm=0x564080, start=0,
>>> last=4, flags=10, action=0x402b30 <mm_act>, ptr=0x44a304 "") at  
>>> dos.c:
>>> 1013
>>> #11 0x0000000000402c5e in do_dimage (img=0x564000, desc=0x44a406 "my
>>> boring test comment") at iwalk.cpp:229
>>> #12 0x0000000000402e39 in main (argc=1, argv=0x7fffffffe988) at
>>> iwalk.cpp:294
>>> (gdb)
>>>
>>> And here is the code itself:
>>>
>>> /* fs_inode_free - destroy generic inode structure */
>>>
>>> void
>>> fs_inode_free(FS_INODE * fs_inode)
>>> {
>>>      FS_NAME *fs_name, *fs_name2;
>>>
>>> =>  if (fs_inode->direct_addr)
>>>          free((char *) fs_inode->direct_addr);
>>>      fs_inode->direct_addr = NULL;
>>>
>>>      if (fs_inode->indir_addr)
>>>          free((char *) fs_inode->indir_addr);
>>>      fs_inode->indir_addr = NULL;
>>>
>>>
>>> Any ideas?
>>>
>>> This is TSK 2.05
>>
>>
>> --------------------------------------------------------------------- 
>> ----
>> 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-users mailing list
>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>> http://www.sleuthkit.org
>
>
>
> ---------------------------------------------------------------------- 
> ---
> 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-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>

Re: [sleuthkit-users] crash in fs_inode.c:96 TSK 2.05

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

Pardon; those line numbers came from my modified version. The call to
fs_inode_free is at line 288:

	   /* we know deleted entries with an inode of 0 are not legit
because
	     * that is the MFT value.  Free it so it does not confuse
	     * people with invalid data
	     */
	    if (fs_dent->inode == 0) {
		fs_inode_free(fs_dent->fsi);      <----
		fs_dent->fsi = NULL;
	    }

Svein


> -----Original Message-----
> From: sle...@li... [mailto:sleuthkit-
> use...@li...] On Behalf Of Svein Yngvar Willassen
> Sent: 23. august 2006 14:56
> To: sle...@li...
> Subject: Re: [sleuthkit-users] crash in fs_inode.c:96 TSK 2.05
> 
> Apparently fs_inode is NULL. In your case it's called from line 305 in
> ntfs.dent.c.
> 
> I notice there's a check for fs_inode != NULL in the call to fs_inode_free
> at line 97.  There should probably be a similar check at line 305.  Such a
> check should at least eliminate your current crash.
> 
> Regards,
> 
> Svein Willassen
> 
> 
> > -----Original Message-----
> > From: sle...@li... [mailto:sleuthkit-
> > use...@li...] On Behalf Of Simson Garfinkel
> > Sent: 23. august 2006 14:41
> > To: sle...@li...
> > Subject: [sleuthkit-users] crash in fs_inode.c:96 TSK 2.05
> >
> > I have an image to generates a crash in the ntfs_dent_idxentry()
> > function.
> >
> > Here is the stack trace:
> >
> > (gdb) where
> > #0  fs_inode_free (fs_inode=0x0) at fs_inode.c:96
> > #1  0x000000000042adf7 in ntfs_dent_idxentry (ntfs=0x566400,
> > dinfo=0x7fffffffdda0, idxe=0x1e57040, size=4032, len=31813712, flags=7,
> >      action=0x402530 <dent_act>, ptr=0x0) at ntfs_dent.c:288
> > #2  0x000000000042bf5c in ntfs_dent_walk_lcl (fs=0x566400,
> > dinfo=0x7fffffffdda0, inum=31817728, flags=7, action=0x402530
> > <dent_act>, ptr=0x0)
> >      at ntfs_dent.c:818
> > #3  0x000000000042af54 in ntfs_dent_idxentry (ntfs=0x566400,
> > dinfo=0x7fffffffdda0, idxe=0x15787e8, size=4032, len=22513656, flags=7,
> >      action=0x402530 <dent_act>, ptr=0x0) at ntfs_dent.c:327
> > #4  0x000000000042bf5c in ntfs_dent_walk_lcl (fs=0x566400,
> > dinfo=0x7fffffffdda0, inum=22515712, flags=7, action=0x402530
> > <dent_act>, ptr=0x0)
> >      at ntfs_dent.c:818
> > #5  0x000000000042af54 in ntfs_dent_idxentry (ntfs=0x566400,
> > dinfo=0x7fffffffdda0, idxe=0x1573458, size=4032, len=22492264, flags=7,
> >      action=0x402530 <dent_act>, ptr=0x0) at ntfs_dent.c:327
> > #6  0x000000000042c142 in ntfs_dent_walk_lcl (fs=0x566400,
> > dinfo=0x7fffffffdda0, inum=4203824, flags=7, action=0x402530
> > <dent_act>, ptr=0x0)
> >      at ntfs_dent.c:863
> > #7  0x000000000042b3ad in ntfs_dent_walk (fs=0x566400, inum=5,
> > flags=7, action=0x402530 <dent_act>, ptr=0x0) at ntfs_dent.c:464
> > #8  0x0000000000402ae2 in do_vol (img=0x564000, start=32256) at
> > iwalk.cpp:170
> > #9  0x0000000000402b7c in mm_act (mm=0x564080, pnum=2, part=0x563180,
> > flag=0, ptr=0x44a304 "") at iwalk.cpp:195
> > #10 0x00000000004342e0 in dos_part_walk (mm=0x564080, start=0,
> > last=4, flags=10, action=0x402b30 <mm_act>, ptr=0x44a304 "") at dos.c:
> > 1013
> > #11 0x0000000000402c5e in do_dimage (img=0x564000, desc=0x44a406 "my
> > boring test comment") at iwalk.cpp:229
> > #12 0x0000000000402e39 in main (argc=1, argv=0x7fffffffe988) at
> > iwalk.cpp:294
> > (gdb)
> >
> > And here is the code itself:
> >
> > /* fs_inode_free - destroy generic inode structure */
> >
> > void
> > fs_inode_free(FS_INODE * fs_inode)
> > {
> >      FS_NAME *fs_name, *fs_name2;
> >
> > =>  if (fs_inode->direct_addr)
> >          free((char *) fs_inode->direct_addr);
> >      fs_inode->direct_addr = NULL;
> >
> >      if (fs_inode->indir_addr)
> >          free((char *) fs_inode->indir_addr);
> >      fs_inode->indir_addr = NULL;
> >
> >
> > Any ideas?
> >
> > This is TSK 2.05
> 
> 
> -------------------------------------------------------------------------
> 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-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org

Re: [sleuthkit-users] crash in fs_inode.c:96 TSK 2.05

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

Thanks. Line 305 in which file?

You are right --- the "quick patch" is:

	if(fs_inode==NULL) return;

However, there's clearly a deeper bug somewhere...


On Aug 23, 2006, at 5:55 AM, Svein Yngvar Willassen wrote:

> Apparently fs_inode is NULL. In your case it's called from line 305 in
> ntfs.dent.c.
>
> I notice there's a check for fs_inode != NULL in the call to  
> fs_inode_free
> at line 97.  There should probably be a similar check at line 305.   
> Such a
> check should at least eliminate your current crash.
>
> Regards,
>
> Svein Willassen
>
>
>> -----Original Message-----
>> From: sle...@li...  
>> [mailto:sleuthkit-
>> use...@li...] On Behalf Of Simson Garfinkel
>> Sent: 23. august 2006 14:41
>> To: sle...@li...
>> Subject: [sleuthkit-users] crash in fs_inode.c:96 TSK 2.05
>>
>> I have an image to generates a crash in the ntfs_dent_idxentry()
>> function.
>>
>> Here is the stack trace:
>>
>> (gdb) where
>> #0  fs_inode_free (fs_inode=0x0) at fs_inode.c:96
>> #1  0x000000000042adf7 in ntfs_dent_idxentry (ntfs=0x566400,
>> dinfo=0x7fffffffdda0, idxe=0x1e57040, size=4032, len=31813712,  
>> flags=7,
>>      action=0x402530 <dent_act>, ptr=0x0) at ntfs_dent.c:288
>> #2  0x000000000042bf5c in ntfs_dent_walk_lcl (fs=0x566400,
>> dinfo=0x7fffffffdda0, inum=31817728, flags=7, action=0x402530
>> <dent_act>, ptr=0x0)
>>      at ntfs_dent.c:818
>> #3  0x000000000042af54 in ntfs_dent_idxentry (ntfs=0x566400,
>> dinfo=0x7fffffffdda0, idxe=0x15787e8, size=4032, len=22513656,  
>> flags=7,
>>      action=0x402530 <dent_act>, ptr=0x0) at ntfs_dent.c:327
>> #4  0x000000000042bf5c in ntfs_dent_walk_lcl (fs=0x566400,
>> dinfo=0x7fffffffdda0, inum=22515712, flags=7, action=0x402530
>> <dent_act>, ptr=0x0)
>>      at ntfs_dent.c:818
>> #5  0x000000000042af54 in ntfs_dent_idxentry (ntfs=0x566400,
>> dinfo=0x7fffffffdda0, idxe=0x1573458, size=4032, len=22492264,  
>> flags=7,
>>      action=0x402530 <dent_act>, ptr=0x0) at ntfs_dent.c:327
>> #6  0x000000000042c142 in ntfs_dent_walk_lcl (fs=0x566400,
>> dinfo=0x7fffffffdda0, inum=4203824, flags=7, action=0x402530
>> <dent_act>, ptr=0x0)
>>      at ntfs_dent.c:863
>> #7  0x000000000042b3ad in ntfs_dent_walk (fs=0x566400, inum=5,
>> flags=7, action=0x402530 <dent_act>, ptr=0x0) at ntfs_dent.c:464
>> #8  0x0000000000402ae2 in do_vol (img=0x564000, start=32256) at
>> iwalk.cpp:170
>> #9  0x0000000000402b7c in mm_act (mm=0x564080, pnum=2, part=0x563180,
>> flag=0, ptr=0x44a304 "") at iwalk.cpp:195
>> #10 0x00000000004342e0 in dos_part_walk (mm=0x564080, start=0,
>> last=4, flags=10, action=0x402b30 <mm_act>, ptr=0x44a304 "") at  
>> dos.c:
>> 1013
>> #11 0x0000000000402c5e in do_dimage (img=0x564000, desc=0x44a406 "my
>> boring test comment") at iwalk.cpp:229
>> #12 0x0000000000402e39 in main (argc=1, argv=0x7fffffffe988) at
>> iwalk.cpp:294
>> (gdb)
>>
>> And here is the code itself:
>>
>> /* fs_inode_free - destroy generic inode structure */
>>
>> void
>> fs_inode_free(FS_INODE * fs_inode)
>> {
>>      FS_NAME *fs_name, *fs_name2;
>>
>> =>  if (fs_inode->direct_addr)
>>          free((char *) fs_inode->direct_addr);
>>      fs_inode->direct_addr = NULL;
>>
>>      if (fs_inode->indir_addr)
>>          free((char *) fs_inode->indir_addr);
>>      fs_inode->indir_addr = NULL;
>>
>>
>> Any ideas?
>>
>> This is TSK 2.05
>
>
> ---------------------------------------------------------------------- 
> ---
> 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-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
>

Re: [sleuthkit-users] crash in fs_inode.c:96 TSK 2.05

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

Apparently fs_inode is NULL. In your case it's called from line 305 in
ntfs.dent.c. 

I notice there's a check for fs_inode != NULL in the call to fs_inode_free
at line 97.  There should probably be a similar check at line 305.  Such a
check should at least eliminate your current crash.

Regards,

Svein Willassen


> -----Original Message-----
> From: sle...@li... [mailto:sleuthkit-
> use...@li...] On Behalf Of Simson Garfinkel
> Sent: 23. august 2006 14:41
> To: sle...@li...
> Subject: [sleuthkit-users] crash in fs_inode.c:96 TSK 2.05
> 
> I have an image to generates a crash in the ntfs_dent_idxentry()
> function.
> 
> Here is the stack trace:
> 
> (gdb) where
> #0  fs_inode_free (fs_inode=0x0) at fs_inode.c:96
> #1  0x000000000042adf7 in ntfs_dent_idxentry (ntfs=0x566400,
> dinfo=0x7fffffffdda0, idxe=0x1e57040, size=4032, len=31813712, flags=7,
>      action=0x402530 <dent_act>, ptr=0x0) at ntfs_dent.c:288
> #2  0x000000000042bf5c in ntfs_dent_walk_lcl (fs=0x566400,
> dinfo=0x7fffffffdda0, inum=31817728, flags=7, action=0x402530
> <dent_act>, ptr=0x0)
>      at ntfs_dent.c:818
> #3  0x000000000042af54 in ntfs_dent_idxentry (ntfs=0x566400,
> dinfo=0x7fffffffdda0, idxe=0x15787e8, size=4032, len=22513656, flags=7,
>      action=0x402530 <dent_act>, ptr=0x0) at ntfs_dent.c:327
> #4  0x000000000042bf5c in ntfs_dent_walk_lcl (fs=0x566400,
> dinfo=0x7fffffffdda0, inum=22515712, flags=7, action=0x402530
> <dent_act>, ptr=0x0)
>      at ntfs_dent.c:818
> #5  0x000000000042af54 in ntfs_dent_idxentry (ntfs=0x566400,
> dinfo=0x7fffffffdda0, idxe=0x1573458, size=4032, len=22492264, flags=7,
>      action=0x402530 <dent_act>, ptr=0x0) at ntfs_dent.c:327
> #6  0x000000000042c142 in ntfs_dent_walk_lcl (fs=0x566400,
> dinfo=0x7fffffffdda0, inum=4203824, flags=7, action=0x402530
> <dent_act>, ptr=0x0)
>      at ntfs_dent.c:863
> #7  0x000000000042b3ad in ntfs_dent_walk (fs=0x566400, inum=5,
> flags=7, action=0x402530 <dent_act>, ptr=0x0) at ntfs_dent.c:464
> #8  0x0000000000402ae2 in do_vol (img=0x564000, start=32256) at
> iwalk.cpp:170
> #9  0x0000000000402b7c in mm_act (mm=0x564080, pnum=2, part=0x563180,
> flag=0, ptr=0x44a304 "") at iwalk.cpp:195
> #10 0x00000000004342e0 in dos_part_walk (mm=0x564080, start=0,
> last=4, flags=10, action=0x402b30 <mm_act>, ptr=0x44a304 "") at dos.c:
> 1013
> #11 0x0000000000402c5e in do_dimage (img=0x564000, desc=0x44a406 "my
> boring test comment") at iwalk.cpp:229
> #12 0x0000000000402e39 in main (argc=1, argv=0x7fffffffe988) at
> iwalk.cpp:294
> (gdb)
> 
> And here is the code itself:
> 
> /* fs_inode_free - destroy generic inode structure */
> 
> void
> fs_inode_free(FS_INODE * fs_inode)
> {
>      FS_NAME *fs_name, *fs_name2;
> 
> =>  if (fs_inode->direct_addr)
>          free((char *) fs_inode->direct_addr);
>      fs_inode->direct_addr = NULL;
> 
>      if (fs_inode->indir_addr)
>          free((char *) fs_inode->indir_addr);
>      fs_inode->indir_addr = NULL;
> 
> 
> Any ideas?
> 
> This is TSK 2.05

[sleuthkit-users] crash in fs_inode.c:96 TSK 2.05

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

I have an image to generates a crash in the ntfs_dent_idxentry()  
function.

Here is the stack trace:

(gdb) where
#0  fs_inode_free (fs_inode=0x0) at fs_inode.c:96
#1  0x000000000042adf7 in ntfs_dent_idxentry (ntfs=0x566400,  
dinfo=0x7fffffffdda0, idxe=0x1e57040, size=4032, len=31813712, flags=7,
     action=0x402530 <dent_act>, ptr=0x0) at ntfs_dent.c:288
#2  0x000000000042bf5c in ntfs_dent_walk_lcl (fs=0x566400,  
dinfo=0x7fffffffdda0, inum=31817728, flags=7, action=0x402530  
<dent_act>, ptr=0x0)
     at ntfs_dent.c:818
#3  0x000000000042af54 in ntfs_dent_idxentry (ntfs=0x566400,  
dinfo=0x7fffffffdda0, idxe=0x15787e8, size=4032, len=22513656, flags=7,
     action=0x402530 <dent_act>, ptr=0x0) at ntfs_dent.c:327
#4  0x000000000042bf5c in ntfs_dent_walk_lcl (fs=0x566400,  
dinfo=0x7fffffffdda0, inum=22515712, flags=7, action=0x402530  
<dent_act>, ptr=0x0)
     at ntfs_dent.c:818
#5  0x000000000042af54 in ntfs_dent_idxentry (ntfs=0x566400,  
dinfo=0x7fffffffdda0, idxe=0x1573458, size=4032, len=22492264, flags=7,
     action=0x402530 <dent_act>, ptr=0x0) at ntfs_dent.c:327
#6  0x000000000042c142 in ntfs_dent_walk_lcl (fs=0x566400,  
dinfo=0x7fffffffdda0, inum=4203824, flags=7, action=0x402530  
<dent_act>, ptr=0x0)
     at ntfs_dent.c:863
#7  0x000000000042b3ad in ntfs_dent_walk (fs=0x566400, inum=5,  
flags=7, action=0x402530 <dent_act>, ptr=0x0) at ntfs_dent.c:464
#8  0x0000000000402ae2 in do_vol (img=0x564000, start=32256) at  
iwalk.cpp:170
#9  0x0000000000402b7c in mm_act (mm=0x564080, pnum=2, part=0x563180,  
flag=0, ptr=0x44a304 "") at iwalk.cpp:195
#10 0x00000000004342e0 in dos_part_walk (mm=0x564080, start=0,  
last=4, flags=10, action=0x402b30 <mm_act>, ptr=0x44a304 "") at dos.c: 
1013
#11 0x0000000000402c5e in do_dimage (img=0x564000, desc=0x44a406 "my  
boring test comment") at iwalk.cpp:229
#12 0x0000000000402e39 in main (argc=1, argv=0x7fffffffe988) at  
iwalk.cpp:294
(gdb)

And here is the code itself:

/* fs_inode_free - destroy generic inode structure */

void
fs_inode_free(FS_INODE * fs_inode)
{
     FS_NAME *fs_name, *fs_name2;

=>  if (fs_inode->direct_addr)
         free((char *) fs_inode->direct_addr);
     fs_inode->direct_addr = NULL;

     if (fs_inode->indir_addr)
         free((char *) fs_inode->indir_addr);
     fs_inode->indir_addr = NULL;


Any ideas?

This is TSK 2.05

Re: [sleuthkit-users] Autopsy over SSL?

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

In that situation, since you already have a ssh session running, I'd strongly
recommend going for the simple solution using ssh port forwarding. Using Apache
here seems like a hammer to crack a nut.

In putty you can achieve it by going into the Putty Configuration screen and
going down into Connection->SSH->Tunnels.

You need to establish forwarding of a local port to the remote port. (e.g. local
1234 to remote 9999 - you can then use your local browser to connect to
http://127.0.0.1:1234/autopsy and let ssh handle the encryption for you.

See this URL for an example :
http://www.cs.uu.nl/technical/services/ssh/putty/puttyfw.html

Your Apache config probably doesn't because the config file doesn't contain the
VHost for the SSL server. 

On Tue Aug 22 15:22 , 'Sorrelle Michael W Ctr AFOSI/DOZI'
<mic...@og...> sent:

> 
>Thanks for all the suggestions!
>I tried the Apache proxy method that Prentis gave, but it didn't seem to
>work.
>So (as requested), here's a bit more detail on what I'm doing, and
>trying to accomplish:
>
>1. On the local/client machine (WinXP), I'm using puTTY to open an SSH
>login to the remote/server machine (Ubuntu 6.06), and in that login
>window, I start Autopsy (via the supplied Perl script, with slight
>modification), which generates the http string (for use in the client
>browser), which I then write to a file on the remote server.
>
>2. I then use WinSCP to copy that file from server to client, and then
>open a browser window (IE) on the client with that generated http string
>(ex: http://192.168.1.101:9999/19427537547421863764/autopsy) in the
>address, which displays the Autopsy main screen. (for test purposes, I
>have the two machines on a standalone local network, but in actual use,
>the remote machine could be anywhere in the world.)
>
>So from that point, the forensic analysis via Autopsy transpires over
>the network via the browser.  It's that communication via browser that I
>need to have secure/encrypted.
>
>I did the Apache proxy configuration given, in the proxy.conf file, and
>added the symlinks for proxy* and ssl* in the mods_enabled directory.  I
>also added 'Listen 443' to the ports.conf file.  I then restarted
>apache, and did the above steps to open Autopsy.  But when I change the
>url to https (with or without ':443'), it doesn't work.
>
>If I'm missing something simple/obvious, by all means let me know.  And
>I won't be insulted by any explicit instructions or steps to follow.
>
>- -
>Mike 
> 
>
>-----Original Message-----
>Date: Mon, 21 Aug 2006 16:01:41 -0400
>From: "Brooks, Prentis" pre...@tw...>
>Subject: Re: [sleuthkit-users] Autopsy over SSL?
>To: an...@n-...>,	sle...@li...>
>
>Here is a sample from the apache 2.2 documentation that I have modified
>to reflect how I did this before.  These commands have not changed since
>2.0, so this will work.
>
>ProxyRequests Off
>
># This is to control access, I highly recommend configuring apache to
>require some level of authentication before # proxying the connections.
>
>Order deny,allow
>Allow from all
>
>
>ProxyPass /autopsy http://127.0.0.1/autopsy 
>ProxyPassReverse /autopsy http://127.0.0.1/autopsy
>
>
>-----Original Message-----
>From: sle...@li... on behalf of Angus
>Marshall
>Sent: Mon 8/21/2006 3:56 PM
>To: sle...@li...
>Subject: Re: [sleuthkit-users] Autopsy over SSL?
> 
>Installing apache as a server won't help you - Autopsy is a server in
>its own right and doesn't speak HTTPS itself.
>
>OTOH - you could probably use Apache's proxy pass through functionality
>to enable it to act as a HTTPS proxy to the Autopsy process. That would
>take a little bit of hacking around in the config file, but should be
>possible. If you can wait a couple of days, I'll see if I can find time
>to try it out.
>
>-------------------------------------------------------------------------
>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-users mailing list
>https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>http://www.sleuthkit.org

Re: [sleuthkit-users] Autopsy over SSL?

[Brooks, P. <pre...@tw...>]

If you are going to do the reverse proxy, then you need to start autopsy
with the -C option.  It doesn't work with the cookie in the URL.

Did you confirm that apache is running on port 443.  I would get apache
configured to respond on 443. 
I ran autopsy from inittab, actually with the -C option.   Once that is
running, test that you can reach the autopsy session via the localhost.
You can try lynx to test.

Then add the proxy config to join the two together.  This way, you can
troubleshoot one component at a time.

On Tue, 2006-08-22 at 10:22 -0400, Sorrelle Michael W Ctr AFOSI/DOZI
wrote:

> 
> 
> Thanks for all the suggestions!
> I tried the Apache proxy method that Prentis gave, but it didn't seem
> to
> work.
> So (as requested), here's a bit more detail on what I'm doing, and
> trying to accomplish:
> 
> 1. On the local/client machine (WinXP), I'm using puTTY to open an SSH
> login to the remote/server machine (Ubuntu 6.06), and in that login
> window, I start Autopsy (via the supplied Perl script, with slight
> modification), which generates the http string (for use in the client
> browser), which I then write to a file on the remote server.
> 
> 2. I then use WinSCP to copy that file from server to client, and then
> open a browser window (IE) on the client with that generated http
> string
> (ex: http://192.168.1.101:9999/19427537547421863764/autopsy) in the
> address, which displays the Autopsy main screen. (for test purposes, I
> have the two machines on a standalone local network, but in actual
> use,
> the remote machine could be anywhere in the world.)
> 
> So from that point, the forensic analysis via Autopsy transpires over
> the network via the browser.  It's that communication via browser that
> I
> need to have secure/encrypted.
> 
> I did the Apache proxy configuration given, in the proxy.conf file,
> and
> added the symlinks for proxy* and ssl* in the mods_enabled directory.
> I
> also added 'Listen 443' to the ports.conf file.  I then restarted
> apache, and did the above steps to open Autopsy.  But when I change
> the
> url to https (with or without ':443'), it doesn't work.
> 
> If I'm missing something simple/obvious, by all means let me know.
> And
> I won't be insulted by any explicit instructions or steps to follow.
> 
> - -
> Mike
> 
> 
> -----Original Message-----
> Date: Mon, 21 Aug 2006 16:01:41 -0400
> From: "Brooks, Prentis" <pre...@tw...>
> Subject: Re: [sleuthkit-users] Autopsy over SSL?
> To: <an...@n-...>, <sle...@li...>
> 
> Here is a sample from the apache 2.2 documentation that I have
> modified
> to reflect how I did this before.  These commands have not changed
> since
> 2.0, so this will work.
> 
> ProxyRequests Off
> 
> # This is to control access, I highly recommend configuring apache to
> require some level of authentication before # proxying the
> connections.
> <Proxy *>
> Order deny,allow
> Allow from all
> </Proxy>
> 
> ProxyPass /autopsy http://127.0.0.1/autopsy
> ProxyPassReverse /autopsy http://127.0.0.1/autopsy
> 
> 
> -----Original Message-----
> From: sle...@li... on behalf of Angus
> Marshall
> Sent: Mon 8/21/2006 3:56 PM
> To: sle...@li...
> Subject: Re: [sleuthkit-users] Autopsy over SSL?
> 
> Installing apache as a server won't help you - Autopsy is a server in
> its own right and doesn't speak HTTPS itself.
> 
> OTOH - you could probably use Apache's proxy pass through
> functionality
> to enable it to act as a HTTPS proxy to the Autopsy process. That
> would
> take a little bit of hacking around in the config file, but should be
> possible. If you can wait a couple of days, I'll see if I can find
> time
> to try it out.
> 
> -------------------------------------------------------------------------
> 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-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org
> 
> 

Re: [sleuthkit-users] Autopsy over SSL?

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

=20
Thanks for all the suggestions!
I tried the Apache proxy method that Prentis gave, but it didn't seem to
work.
So (as requested), here's a bit more detail on what I'm doing, and
trying to accomplish:

1. On the local/client machine (WinXP), I'm using puTTY to open an SSH
login to the remote/server machine (Ubuntu 6.06), and in that login
window, I start Autopsy (via the supplied Perl script, with slight
modification), which generates the http string (for use in the client
browser), which I then write to a file on the remote server.

2. I then use WinSCP to copy that file from server to client, and then
open a browser window (IE) on the client with that generated http string
(ex: http://192.168.1.101:9999/19427537547421863764/autopsy) in the
address, which displays the Autopsy main screen. (for test purposes, I
have the two machines on a standalone local network, but in actual use,
the remote machine could be anywhere in the world.)

So from that point, the forensic analysis via Autopsy transpires over
the network via the browser.  It's that communication via browser that I
need to have secure/encrypted.

I did the Apache proxy configuration given, in the proxy.conf file, and
added the symlinks for proxy* and ssl* in the mods_enabled directory.  I
also added 'Listen 443' to the ports.conf file.  I then restarted
apache, and did the above steps to open Autopsy.  But when I change the
url to https (with or without ':443'), it doesn't work.

If I'm missing something simple/obvious, by all means let me know.  And
I won't be insulted by any explicit instructions or steps to follow.

- -
Mike=20
=20

-----Original Message-----
Date: Mon, 21 Aug 2006 16:01:41 -0400
From: "Brooks, Prentis" <pre...@tw...>
Subject: Re: [sleuthkit-users] Autopsy over SSL?
To: <an...@n-...>,	<sle...@li...>

Here is a sample from the apache 2.2 documentation that I have modified
to reflect how I did this before.  These commands have not changed since
2.0, so this will work.

ProxyRequests Off

# This is to control access, I highly recommend configuring apache to
require some level of authentication before # proxying the connections.
<Proxy *>
Order deny,allow
Allow from all
</Proxy>

ProxyPass /autopsy http://127.0.0.1/autopsy=20
ProxyPassReverse /autopsy http://127.0.0.1/autopsy


-----Original Message-----
From: sle...@li... on behalf of Angus
Marshall
Sent: Mon 8/21/2006 3:56 PM
To: sle...@li...
Subject: Re: [sleuthkit-users] Autopsy over SSL?
=20
Installing apache as a server won't help you - Autopsy is a server in
its own right and doesn't speak HTTPS itself.

OTOH - you could probably use Apache's proxy pass through functionality
to enable it to act as a HTTPS proxy to the Autopsy process. That would
take a little bit of hacking around in the config file, but should be
possible. If you can wait a couple of days, I'll see if I can find time
to try it out.

Re: [sleuthkit-users] Autopsy over SSL?

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

SSH is the approach that I have tried in the past as well.

I previously looked into incorporating SSL into Autopsy, but that 
created a lot more dependencies on OpenSSL existing etc.  TSK now 
requires OpenSSL for the new image formats that it supports, so it might 
not be that difficult to do now.  I'll look into it.

brian


Angus Marshall wrote:
> A little idea for everyone - how about running it using SSH rather than HTTPS ? 
> 
> I've just tried 
> 
>                ssh -L 1234:127.0.0.1:9999 amarshall@myhost 
> 
> to log in to one of my workstations and launch autopsy
> 
> and then aimed a browser on the remote workstation to http://localhost:1234/autopsy
> 
> it works - my autopsy session on "myhost" is visible to the remote machine and
> totally dependent on the ssh tunnel existing between the two hosts. 
> 
> This gives a transient session, requiring an authentication process from the
> remote end.
> 
> 
> On Mon Aug 21 21:01 , 'Brooks, Prentis' <pre...@tw...> sent:
> 
>> Here is a sample from the apache 2.2 documentation that I have modified to
> reflect how I did this before.  These commands have not changed since 2.0, so
> this will work.
>> ProxyRequests Off
>>
>> # This is to control access, I highly recommend configuring apache to require
> some level of authentication before 
>> # proxying the connections.
>>
>> Order deny,allow
>> Allow from all
>>
>>
>> ProxyPass /autopsy http://127.0.0.1/autopsy
>> ProxyPassReverse /autopsy http://127.0.0.1/autopsy
>>
>>
>>
> 
> 
> -------------------------------------------------------------------------
> 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-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org