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

[sleuthkit-developers] autopsy and >tsk-2.50

[RB <ao...@gm...>]

I really appreciate the effort made in recent TSK releases to
eliminate internal baggage and depend on the host more to provide the
necessary dependencies and facilities - good stuff, particularly for
packagers.

It seems that autopsy has been left in the cold, though - it still
looks for the 'md5' binary, which isn't provided any more.  The simple
fix you guys have introduced in sorter would work as well, but you may
want to be cautious about preferring 'md5' over 'md5sum' - FreeBSD
provides 'md5', and its output is significantly different.

Would you like me to submit a patch?  Do you have a public repository
(other than the tarballs) I could make it against?

[sleuthkit-developers] Block Alignment in FFS / ExtX

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

There is a legacy TCT feature in TSK that I am thinking about  
removing, but first want to see if anyone is using it. In UFS (and in  
theory, but not practice, Ext2/3), a block (4KB for example) is  
broken up into fragments (each 1KB for example). Each fragment has an  
address and an allocation status.

With 'dls' (and ffs_block_walk() for the developers out there), there  
is an alignment option that forces the output to be in block-sized  
chunks.  The fragments that do not meet your filtering criteria (such  
as allocated or unallocated) will be returned with all 0s if there is  
a fragment in the block that does meet your criteria.  Therefore, if  
you use 'dls' to output the unallocated fragments, and there is a  
block that contains some allocated fragments and some unallocated  
fragments, then 'dls' will currently output the allocated fragments  
as all 0s.   I think this is confusing.

I propose to change the behavior so that only fragments that meet the  
filtering criteria are returned. If you ask 'dls' to give you  
unallocated fragments then it gives only unallocated fragments. You  
can currently do this with 'dls' using '-b'.  (in fact, you can see  
the difference by comparing the output of 'dls -l'  and 'dls -lb'.   
'dls -l' will likely have some entries for allocated fragments).

Is anyone depending on this behavior?  Removing it will simplify the  
code.

brian

Re: [sleuthkit-developers] JFFS2 Support

[Knut E. <kn...@ac...>]

Dear Jeff,

> It appears that TSK actively tries to avoid external dependencies, for
> instance, the ext2 support does not depend upon <linux/ext2.h>.
> Understanding that I shouldn't include <linux/jffs2.h> in my source, how
> appropriate is it examine that file in my creation of a jffs2.h file for
> TSK?  As I tried to familiarize myself with the TSK file system code,
> I've made a point of not looking into the jffs2.h file in the Linux
> headers, but obviously using that code (even if it were copied along
> with the copyright notice), would make my task easier.

In my opinion (and experience - I added experimental support for JFS for
Linux, not published (yet) but available on request as a source diff to
tsk-2.03), you should definitely look at jffs2.h, but not necessarily copy
the whole file for the following reasons:

1. It may include more data structure definitions and/or macros than you
will need for your TSK module, e.g. in-kernel memory data structures in
addition to on-disk data structures

2. I see the on-disk data structures specified in e.g. jffs2.h as a
"published interface", which means that you should read them and
understand them, but also be prepared to validate during your development
and testing whether the sequence of bytes in the jffs2 images you will
analyse contain additional, "unpublished details" which could be very
relevant from a forensic point of view.

3. I am not a lawyer, but I would see data structure definitions in .h
files not as code, but as an interface definition, so I would not worry
too much about license issues. You could also just take the component data
types from the data structure definition and (re)define the data
structures using your own component names. I initially studied the FFS
code in TSK to understand the differen types of callback routines and data
structures and then tried to keep with TSK naming conventions etc when
creating my own jfs.h file. Naturally there are limits to this, as JFFS2
in your case may have concepts and consequentially data structures which
are very different from FFS. The jffs2.h file may also contain macro
definitions, which could be seen as code, so you may want to avoid copying
those macros directly.

Kind regards,

Knut

Re: [sleuthkit-developers] JFFS2 Support

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

Hi,

Actually, most of Sleuthkit is under the IBM Public License, NOT the GPL.
'mactime' is under the GPL, but (akaif) it is a separate tool, not
linked to sk directly.

I do not know enough about licences to know if you can copy GPL'd code
and link it to the IBM licensed code.
This page suggests perhaps not (though it doesnt really explain why):
http://www.fsf.org/licensing/licenses/

I'd suggest that the FSF would be happy help you out, let us all know
what you find.

Alternatively, Brian may be able to approach the other authors and
re-licence Sleuthkit under the GPL (something I'd like to see).

Dave

On Jan 10, 2008 6:37 PM, Jim Halfpenny <jim...@gm...> wrote:
> Hi Jeff,
> Both Linux and TSK are relased under the GNU Public License, so I can see no
> reason why you cannot look at or simply copy jff2.h into the TSK source
> tree. It would then cease to be an external dependancy. There's no sense in
> reinventing the wheel when you can enjoy the benefits of free software.
>
> Regards,
> Jim
>
>
>
>
> On 10/01/2008, Jeff Craig <li...@fo...> wrote:
> > I'm looking at writing JFFS2[1] support into TSK, as I have a pair of
> > images I'm interested in analyzing.  My questions are of semantics for
> > the code.
> >
> > It appears that TSK actively tries to avoid external dependencies, for
> > instance, the ext2 support does not depend upon <linux/ext2.h>.
> > Understanding that I shouldn't include <linux/jffs2.h> in my source, how
> > appropriate is it examine that file in my creation of a jffs2.h file for
> > TSK?  As I tried to familiarize myself with the TSK file system code,
> > I've made a point of not looking into the jffs2.h file in the Linux
> > headers, but obviously using that code (even if it were copied along
> > with the copyright notice), would make my task easier.
> >
> > Jeff Craig
> >
> > [1] http://sourceware.org/jffs2/
> >
> >
> > -------------------------------------------------------------------------
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services for
> > just about anything Open Source.
> >
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> > _______________________________________________
> > sleuthkit-developers mailing list
> > sle...@li...
> > https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers
> >
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> sleuthkit-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers
>
>

Re: [sleuthkit-developers] JFFS2 Support

[Jim H. <jim...@gm...>]

Hi Jeff,
Both Linux and TSK are relased under the GNU Public License, so I can see no
reason why you cannot look at or simply copy jff2.h into the TSK source
tree. It would then cease to be an external dependancy. There's no sense in
reinventing the wheel when you can enjoy the benefits of free software.

Regards,
Jim


On 10/01/2008, Jeff Craig <li...@fo...> wrote:
>
> I'm looking at writing JFFS2[1] support into TSK, as I have a pair of
> images I'm interested in analyzing.  My questions are of semantics for
> the code.
>
> It appears that TSK actively tries to avoid external dependencies, for
> instance, the ext2 support does not depend upon <linux/ext2.h>.
> Understanding that I shouldn't include <linux/jffs2.h> in my source, how
> appropriate is it examine that file in my creation of a jffs2.h file for
> TSK?  As I tried to familiarize myself with the TSK file system code,
> I've made a point of not looking into the jffs2.h file in the Linux
> headers, but obviously using that code (even if it were copied along
> with the copyright notice), would make my task easier.
>
> Jeff Craig
>
> [1] http://sourceware.org/jffs2/
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
>
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> sleuthkit-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers
>

[sleuthkit-developers] JFFS2 Support

[Jeff C. <li...@fo...>]

I'm looking at writing JFFS2[1] support into TSK, as I have a pair of
images I'm interested in analyzing.  My questions are of semantics for
the code.

It appears that TSK actively tries to avoid external dependencies, for
instance, the ext2 support does not depend upon <linux/ext2.h>.
Understanding that I shouldn't include <linux/jffs2.h> in my source, how
appropriate is it examine that file in my creation of a jffs2.h file for
TSK?  As I tried to familiarize myself with the TSK file system code,
I've made a point of not looking into the jffs2.h file in the Linux
headers, but obviously using that code (even if it were copied along
with the copyright notice), would make my task easier.
        
Jeff Craig
        
[1] http://sourceware.org/jffs2/

Re: [sleuthkit-developers] NTFS

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

Hi David,

Good catch. I added the "if (type == 0)" check and updated the API  
docs to identify that 0 should be passed to use the default, which is  
the same behavior as file_walk().   The compressed handling code is  
fine because file_walk will choose the correct default type.

As an aside, the performance of the fs_read_file() API for FAT file  
systems has been greatly improved in the next version. When a FAT  
file is loaded, an internal runlist for its clusters is created and  
maintained for the life of the FS_INODE. When you need to read from  
inside of a file, the runlist is used to find where to read from  
(instead of needing to read the FAT each time.

brian

On Dec 5, 2007, at 7:30 AM, David Collett wrote:

> Hi Brian,
>
> I've found a bug in fs_read_file_int in fs_io.c in sleuthkit.
>
> on line 410 it sets the 'type' of the ntfs attribute regardless of
> what was passed in to the function. This caused the function to fail
> when trying to read a particular attribute ($Extend/$ObjID:$0
> (25-144-2)) as the '144' was being reset to '128' and the lookup on
> line 421 failed as the attribute 25-128-2 did not exist.
>
> I think the solution is to simply surround the block (410-414) with an
> "if(type == 0)" check.
>
> Also, the compressed file handling on line 385 occurs before this
> block which assigns a default type, so it may be called with a type=0,
> is this ok? I think file_walk will just give you the default ($DATA)
> attribute if this is 0, but I cant remember for sure.
>
> Thanks,
>
> Dave
>
> ---------------------------------------------------------------------- 
> ---
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> sleuthkit-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers

[sleuthkit-developers] NTFS

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

Hi Brian,

I've found a bug in fs_read_file_int in fs_io.c in sleuthkit.

on line 410 it sets the 'type' of the ntfs attribute regardless of
what was passed in to the function. This caused the function to fail
when trying to read a particular attribute ($Extend/$ObjID:$0
(25-144-2)) as the '144' was being reset to '128' and the lookup on
line 421 failed as the attribute 25-128-2 did not exist.

I think the solution is to simply surround the block (410-414) with an
"if(type == 0)" check.

Also, the compressed file handling on line 385 occurs before this
block which assigns a default type, so it may be called with a type=0,
is this ok? I think file_walk will just give you the default ($DATA)
attribute if this is 0, but I cant remember for sure.

Thanks,

Dave

Re: [sleuthkit-developers] mmls mis-feature?

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

Hey Michael,

I've been adjusting these types of checks.  As you can see in the  
code, there used to be a check that the partition ended in the image,  
now it just checks that it starts in the image. The main motivation  
for this was as a sanity check and to detect when 'mmls' is being run  
on a FAT superblock versus a DOS partition table (since they share  
the same 2 byte magic value). The problem is that the only way to  
'detect' a DOS partition table is to check the two magic bytes and  
then do some sanity checks on the partition table content.   Since  
CHS values do not really work for current disks, that leaves only the  
LBA values and partition type.

The problem arises specifically when you have a tool that takes both  
disk and volume images as input. First you may try to use mm_open to  
see if there is a volume system.  If that fails, then you would want  
to try fs_open to see if there is a known file system.  If the DOS  
code is more liberal with its checks, then FAT file systems could be  
easily detected as DOS partition tables and the results would be  
garbage.

Perhaps the requirement could be:
- At least one partition must start in the image file.  It can end  
outside of the image file (This is currently supported).
- A partition can start and end outside of the image file if it  
starts within X sectors of the end of another partition.

I just changed some of the file system code to deal with a similar  
problem.  There is now a last_block_act value in FS_INFO that reports  
the actual last block of the file system versus the reported last  
block.  They are different if the image is corrupt or partial. Maybe  
I need something similar for the MM_PART structure.

brian



On Sep 11, 2007, at 7:08 AM, Michael Cohen wrote:

> Hi List,
>   I tried to use mmls today on a truncated disk image and received an
> error that the partition table was invalid. This was despite the fact
> that sfdisk and disktype successfully printed the partition table. I
> looked into it and saw this kind of code, e.g. dos.c:
>
> DADDR_T max_addr = (mm->img_info->size - mm->offset) / mm->block_size;
>
> and
>
> if (part_start > max_addr) {
>             tsk_error_reset();
>             tsk_errno = TSK_ERR_MM_BLK_NUM;
>             snprintf(tsk_errstr, TSK_ERRSTR_L,
>                 "dos_load_prim_table: Starting sector too large for  
> image");
>             if (tsk_verbose)
>                 tsk_fprintf(stderr,
>                     "Starting sector %" PRIu32 " too large for image 
> \n",
>                     part_start);
>
>             return 1;
>         }
>
> The problem is that some of the later partitions of course fall  
> past the end of
> the truncated image. In this case I get no output at all, and it  
> errors out
> altogether.
>
> I wonder if its better to either change the error to a warning or  
> leave this
> error check altogether - whats the point of it? I kind of expected  
> mmls to tell
> me what the partition table says - its irrelevant that its not  
> exactly expected
> from the image. I would have expected to at least be told something  
> about the
> earlier partitions that can possibly fall in this image.
>
> Thanks,
> Michael.
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> sleuthkit-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers

[sleuthkit-developers] mmls mis-feature?

[Michael C. <scu...@gm...>]

Hi List,
  I tried to use mmls today on a truncated disk image and received an
error that the partition table was invalid. This was despite the fact
that sfdisk and disktype successfully printed the partition table. I
looked into it and saw this kind of code, e.g. dos.c:

DADDR_T max_addr = (mm->img_info->size - mm->offset) / mm->block_size;

and 

if (part_start > max_addr) {
            tsk_error_reset();
            tsk_errno = TSK_ERR_MM_BLK_NUM;
            snprintf(tsk_errstr, TSK_ERRSTR_L,
                "dos_load_prim_table: Starting sector too large for image");
            if (tsk_verbose)
                tsk_fprintf(stderr,
                    "Starting sector %" PRIu32 " too large for image\n",
                    part_start);

            return 1;
        }

The problem is that some of the later partitions of course fall past the end of
the truncated image. In this case I get no output at all, and it errors out
altogether.

I wonder if its better to either change the error to a warning or leave this
error check altogether - whats the point of it? I kind of expected mmls to tell
me what the partition table says - its irrelevant that its not exactly expected
from the image. I would have expected to at least be told something about the
earlier partitions that can possibly fall in this image.

Thanks,
Michael.

Re: [sleuthkit-developers] NTFS File System Seg Fault

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

Al,

Thanks for reporting this. It was also reported to me a few weeks  
back and I fixed it (I need to get a new release out).  THe simple  
fix is to add this above where you had the problem:


     else if (fs_dent->fsi == NULL) {
         return TSK_WALK_STOP;
     }

thanks,
brian


On Sep 6, 2007, at 12:10 AM, Al MailingList wrote:

> Hello list,
>
> I've been using sk for a while (it's great), and I've just started
> using the excellent python bindings for the sleuthkit (from
> www.pyflag.net). Anyway, when processing a disk image I ran across a
> seg fault. Basically here is what is happened:
>
> - I walked the file system
> - I tried to extract all the files one by one by name
> - When attempting to extract one I got a seg fault
>
> I narrowed it down to the one file it was crashing on, say
>
> /foo/bar/foobar/file
>
> doing an ifind on this seg faults, as too does doing one on foobar;
> doing an ifind on bar gives me an inode of zero. Obviously something
> is not correct. The seg fault occurs in ifind_lib.c. In the pyflag
> version it's line 235, but this might be slightly different in the
> current sk source. The line in question is:
>
> if ((fs_dent->fsi->mode & TSK_FS_INODE_MODE_FMT) == ...
>
> It occurs because in this particular instance, fs_dent->fsi is null.
>
> I would love to debug it myself, but I fear it would take far longer
> than my employer would appreciate :P . I've managed to work around it
> by using inodes instead of file names, so it's not a big deal for me
> anymore, but thought I would raise it. Maybe just a check for a null
> fsi and then returning a TS_WALK_ERROR would do? I can spend a bit
> more time debugging it if you can provide me some pointers. It may
> well just be a corrupt file system? Oh yeah it's an NTFS file system.
> I've checked this against v2.06 and v2.09, both seg fault.
>
> Thanks again, tsk is cool :)
>
> Cheers,
> Al
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> sleuthkit-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers

[sleuthkit-developers] NTFS File System Seg Fault

[Al M. <alp...@gm...>]

Hello list,

I've been using sk for a while (it's great), and I've just started
using the excellent python bindings for the sleuthkit (from
www.pyflag.net). Anyway, when processing a disk image I ran across a
seg fault. Basically here is what is happened:

- I walked the file system
- I tried to extract all the files one by one by name
- When attempting to extract one I got a seg fault

I narrowed it down to the one file it was crashing on, say

/foo/bar/foobar/file

doing an ifind on this seg faults, as too does doing one on foobar;
doing an ifind on bar gives me an inode of zero. Obviously something
is not correct. The seg fault occurs in ifind_lib.c. In the pyflag
version it's line 235, but this might be slightly different in the
current sk source. The line in question is:

if ((fs_dent->fsi->mode & TSK_FS_INODE_MODE_FMT) == ...

It occurs because in this particular instance, fs_dent->fsi is null.

I would love to debug it myself, but I fear it would take far longer
than my employer would appreciate :P . I've managed to work around it
by using inodes instead of file names, so it's not a big deal for me
anymore, but thought I would raise it. Maybe just a check for a null
fsi and then returning a TS_WALK_ERROR would do? I can spend a bit
more time debugging it if you can provide me some pointers. It may
well just be a corrupt file system? Oh yeah it's an NTFS file system.
I've checked this against v2.06 and v2.09, both seg fault.

Thanks again, tsk is cool :)

Cheers,
Al

Re: [sleuthkit-developers] File sizes reported by sleuthkit

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

On Jul 20, 2007, at 4:20 PM, David Kennedy wrote:

> Hi all,
>
> A couple questions on file sizes calculated by TSK:
>
> 1) In NTFS, is the file metadata from MFT record(s) included in a
> file's reported size?  If so, unused space in a record is ignored,
> correct?  Generically, does file metadata from other file systems work
> into a file's reported size?

With NTFS, each attribute has a size.  The reported size should be of  
only the file content -- not any metadata.

> 2) What goes into calculating the reported size of directories?

Typically, it is the number of bytes allocated to the directory.

> 3) I'm running some comparisons between file sizes reported between
> sleuthkit 2.07, encase 5, and windows.  Uncommonly, some non-directory
> file sizes are off.  For example, a test NTFS hard drive of around 30k
> files shows several hundred files with mismatched size, and 90% of
> those are off by 26 bytes.  Any ideas what might account for those 26
> bytes?

Who is reporting what? What type of files are they?

brian

Re: [sleuthkit-developers] unicode encoding/weird file names?

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

The TSK tools have supported Unicode for a couple of years now.

brian


On Jul 20, 2007, at 11:32 AM, David Kennedy wrote:

> I was having some issues with non-ASCII characters with FLS results,
> and ran across the email copied below my message.  At first, I thought
> it was only the Windows Latin MS-added characters, but soon saw it is
> anything non ASCII.  I am currently running TSK 2.08.
>
> Does this issue still exist?  is there any current effort in allowing
> for wider character support in the TSK libs?
>
> I don't know much about swapping encodings around, but i tried
> treating the filename from FS_DENT as a multibyte string and running
> it through mbstowcs with no success.  Is that a possible direction for
> a workaround?
>
> Thanks much!
>
> email:
> If we are considering an NTFS file system, then all names are  
> stored as
> UTF-16 Unicode, but TSK takes only the lower byte and turns it into
> ASCII.  With FAT, the original 8.3 directory entry has only ASCII and
> those can have characters from various code pages (I don't think the
> actual page is defined in the file system though).  FAT long file  
> names
> are stored in UTF-16 and are Unicode so they can use the Unicode name.
>   Therefore, if you have a FAT file system with Arabic then (I think)
> the short name will use a code page and the long name will use  
> Unicode.
>
> In either case, TSK may not even show you the non-ASCII name  
> because it
> requires the name to be valid ASCII.  This is obviously too  
> restrictive
> in light of code pages and such.  Once TSK becomes Unicode-aware then
> this will also change.
>
> brian
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> sleuthkit-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers

[sleuthkit-developers] File sizes reported by sleuthkit

[David K. <dmk...@gm...>]

Hi all,

A couple questions on file sizes calculated by TSK:

1) In NTFS, is the file metadata from MFT record(s) included in a
file's reported size?  If so, unused space in a record is ignored,
correct?  Generically, does file metadata from other file systems work
into a file's reported size?

2) What goes into calculating the reported size of directories?

3) I'm running some comparisons between file sizes reported between
sleuthkit 2.07, encase 5, and windows.  Uncommonly, some non-directory
file sizes are off.  For example, a test NTFS hard drive of around 30k
files shows several hundred files with mismatched size, and 90% of
those are off by 26 bytes.  Any ideas what might account for those 26
bytes?

Thanks much..

[sleuthkit-developers] unicode encoding/weird file names?

[David K. <dmk...@gm...>]

I was having some issues with non-ASCII characters with FLS results,
and ran across the email copied below my message.  At first, I thought
it was only the Windows Latin MS-added characters, but soon saw it is
anything non ASCII.  I am currently running TSK 2.08.

Does this issue still exist?  is there any current effort in allowing
for wider character support in the TSK libs?

I don't know much about swapping encodings around, but i tried
treating the filename from FS_DENT as a multibyte string and running
it through mbstowcs with no success.  Is that a possible direction for
a workaround?

Thanks much!

email:
If we are considering an NTFS file system, then all names are stored as
UTF-16 Unicode, but TSK takes only the lower byte and turns it into
ASCII.  With FAT, the original 8.3 directory entry has only ASCII and
those can have characters from various code pages (I don't think the
actual page is defined in the file system though).  FAT long file names
are stored in UTF-16 and are Unicode so they can use the Unicode name.
  Therefore, if you have a FAT file system with Arabic then (I think)
the short name will use a code page and the long name will use Unicode.

In either case, TSK may not even show you the non-ASCII name because it
requires the name to be valid ASCII.  This is obviously too restrictive
in light of code pages and such.  Once TSK becomes Unicode-aware then
this will also change.

brian

Re: [sleuthkit-developers] A question regarding the licensing of TSK

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

Based on:
http://www.gnu.org/philosophy/license-list.html

It says that the IBM / Common Public licenses are not compatible with  
GPL.  It has been a while since I read the GPL (especially the new  
one), but I think that means that it cannot be used.

brian


On Jul 4, 2007, at 3:24 AM, Balazs Attila-Mihaly (Cd-MaN) wrote:

> Hello, I already sent this mail to the sleuthkit-users lists, but  
> probably this is a more appropiate forum to ask:
>
> As part of a personal
> project I created some code to make TSK capable of reading some image
> formats used by virtual machines (VirtualPC, VMWare, Qemu and Bochs).
> This was done by developing a "translation layer" between TSK and the
> procedures from Qemu (http://fabrice.bellard.free.fr/qemu/).
> My question is (since IANAL): how compatible is the IBM Open Source
> License and the GPL? I'm asking this since the code taken from Qemu is
> licensed under the GPL. If somebody with legal expertise could  
> chime in
> and confirm that this is ok, I would be happy to release the source
> code (if there is the need that is).
>
> Update: Qemu CVS just added support for the VirtualBox disk images  
> (VDI), which should be easy to port over too.
>
> Best regards,
> Cd-MAN
>
>
>
>
> 		
> ___________________________________________________________
> Copy addresses and emails from any email account to Yahoo! Mail -  
> quick, easy and free. http://uk.docs.yahoo.com/trueswitch2.html
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> sleuthkit-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers

[sleuthkit-developers] A question regarding the licensing of TSK

[Balazs Attila-M. \(Cd-MaN\) <x_a...@ya...>]

Hello, I already sent this mail to the sleuthkit-users lists, but probably this is a more appropiate forum to ask:

As part of a personal
project I created some code to make TSK capable of reading some image
formats used by virtual machines (VirtualPC, VMWare, Qemu and Bochs).
This was done by developing a "translation layer" between TSK and the
procedures from Qemu (http://fabrice.bellard.free.fr/qemu/).
My question is (since IANAL): how compatible is the IBM Open Source
License and the GPL? I'm asking this since the code taken from Qemu is
licensed under the GPL. If somebody with legal expertise could chime in
and confirm that this is ok, I would be happy to release the source
code (if there is the need that is).

Update: Qemu CVS just added support for the VirtualBox disk images (VDI), which should be easy to port over too.

Best regards,
Cd-MAN




		
___________________________________________________________ 
Copy addresses and emails from any email account to Yahoo! Mail - quick, easy and free. http://uk.docs.yahoo.com/trueswitch2.html

Re: [sleuthkit-developers] Istat shows Direct Blocks incorrectly

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

You are correct.  Fixed.

thanks,
brian

On Apr 6, 2007, at 2:31 AM, Makoto Shiotsuki wrote:

> When the file system type is Ext, istat falls into eternal loop
> and shows Direct Blocks more than existing block numbers.
>
> example:
>
>     [root@ns sleuthkit-2.08]# bin/istat -f ext /dev/hda1 6033
>     inode: 6033
>     Allocated
>     Group: 3
>     Generation Id: 702883908
>     uid / gid: 0 / 0
>     mode: -rw-r-----
>     size: 6
>     num of links: 1
>
>     Inode Times:
>     Accessed:       Fri Apr  6 14:51:52 2007
>     File Modified:  Fri Apr  6 14:51:52 2007
>     Inode Modified: Fri Apr  6 14:51:52 2007
>
>     Direct Blocks:
>     27354 27355 27356 27357 27358 27359 27360 27361
>     27362 27363 27364 27365 27366 27367 27368 27369
>     27370 27371 27372 27373 27374 27375 27376 27377
>     .....
>
> This seems to happen because of the wrong comparison of size_t value
> in print_addr_act(). (ext2fs.c, line 1798)
>
>     for (i = 0, s = size; s > 0; s -= fs->block_size, i++) {
>
> Because the type of variable "s" is "size_t", I think this should be
> like the following.
>
>     for (i = 0, s = size; s > 0;
>          s = (s > fs->block_size) ? s - fs->block_size : 0, i++) {
>
> There is same code in ffs.c so it may have same problem.
>
> Hope this helps.
>
> Makoto Shiotsuki
>
> ---------------------------------------------------------------------- 
> ---
> 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] Istat shows Direct Blocks incorrectly

[Makoto S. <sh...@st...>]

When the file system type is Ext, istat falls into eternal loop
and shows Direct Blocks more than existing block numbers.

example:

    [root@ns sleuthkit-2.08]# bin/istat -f ext /dev/hda1 6033
    inode: 6033
    Allocated
    Group: 3
    Generation Id: 702883908
    uid / gid: 0 / 0
    mode: -rw-r-----
    size: 6
    num of links: 1

    Inode Times:
    Accessed:       Fri Apr  6 14:51:52 2007
    File Modified:  Fri Apr  6 14:51:52 2007
    Inode Modified: Fri Apr  6 14:51:52 2007

    Direct Blocks:
    27354 27355 27356 27357 27358 27359 27360 27361
    27362 27363 27364 27365 27366 27367 27368 27369
    27370 27371 27372 27373 27374 27375 27376 27377
    .....

This seems to happen because of the wrong comparison of size_t value
in print_addr_act(). (ext2fs.c, line 1798)

    for (i = 0, s = size; s > 0; s -= fs->block_size, i++) {

Because the type of variable "s" is "size_t", I think this should be
like the following.

    for (i = 0, s = size; s > 0;
         s = (s > fs->block_size) ? s - fs->block_size : 0, i++) {

There is same code in ffs.c so it may have same problem.

Hope this helps.

Makoto Shiotsuki

[sleuthkit-developers] 2.08 Version API Changes

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

Many of you who are using TSK as a library may not like me after  
looking at the 2.08 release. It is not backward compatible with 2.07.

It contains a lot of API name changes.  All of the functions and  
structures have tsk_ or TSK_ ahead of them and some also now have  
TSK_FS_... in front of them. The goal was to make the naming scheme  
more consistent and prevent name conflicts.

In general, the names get more specific.  They start with TSK, the  
next part is typically the data layer, the next part may be another  
layer, or a data structure name, etc.

Many of the FLAG names changed and they are all part of an enum.  For  
example, FS_FLAG_META_ALLOC is now TSK_FS_INODE_FLAG_ALLOC and it is  
part of the TSK_FS_INODE_FLAG_ENUM enum .

Many of the callback functions changed because the flags argument was  
redundant for inode_walk and dent_walk.

As a good thing though, I have started to add doxygen comments as I  
work on files.  Therefore, there are now basic API documents in docs/ 
api-docs/index.html.

If you have any problems / questions with the new API, let me know.

brian

[sleuthkit-developers] DFRWS 2007 File Carving Challenge

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

[I figured this would be relevant to some of the developers on this  
list]



The DFRWS 2007 File Carving Challenge has been posted:

http://www.dfrws.org/2007/challenge/

Submissions are Due July 9, 2007.

This years challenge builds upon last years and adds more file types  
and scenarios. File carving is the process of extracting files from  
data using file type specific  knowledge, such as header and footer  
values or internal data structures. Different approaches to file  
carving result in different error rates and the goal of this  
challenge is to develop AUTOMATED file carving programs that are  
efficient and have low false positive rates.

Additional details are on the website.

Remember that paper submissions for the general conference are due  
April 2, 2007.

The Challenge Organizers (Brian Carrier, Eoghan Casey, and Wietse  
Venema)

Re: [sleuthkit-developers] retrieving full directory/path name from FS_DENT

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

Do you have the latest version? The long name should be given in  
'path', but I think that behavior started only in the last few  
versions. That is of course, unless the long name does not exist for  
some reason (which could happen with deleted directories -- if the  
directory entries for the long name have been overwritten).

brian



On Jan 23, 2007, at 4:17 PM, dave kennedy wrote:

> hi..
> I am using dent_walk to gain a list of files on an image, along  
> with their information.  I was grabbing the path of a particular  
> file by accessing fs_dent's 'path' variable- listed in fs_tools.h  
> as the 'prefix to name when recursing'.  It was working great..
>
> Until I noticed that when looking at a FAT32 image (running on  
> linux) that particular variable seems to be only represented by the  
> directory's short name.  Is there any easy way to get the full name  
> of a file's parent directory, or will my solution in essence have  
> to renavigate through all the filenames again until I locate a  
> directory with a matching shortname?
>
> Thanks much..
> ---------------------------------------------------------------------- 
> ---
> 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] retrieving full directory/path name from FS_DENT

[dave k. <ken...@gm...>]

hi..
I am using dent_walk to gain a list of files on an image, along with their
information.  I was grabbing the path of a particular file by accessing
fs_dent's 'path' variable- listed in fs_tools.h as the 'prefix to name when
recursing'.  It was working great..

Until I noticed that when looking at a FAT32 image (running on linux) that
particular variable seems to be only represented by the directory's short
name.  Is there any easy way to get the full name of a file's parent
directory, or will my solution in essence have to renavigate through all the
filenames again until I locate a directory with a matching shortname?

Thanks much..

Re: [sleuthkit-developers] small patch for 2.07

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

Thanks Dave.


David Collett wrote:
> 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
> 
> -------------------------------------------------------------------------
> 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