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

Re: [sleuthkit-developers] Date Keyword Expansion

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

On Sep 27, 2008, at 7:15 PM, Michael Cohen wrote:

> Hi Brian,
>   The whole keyword expansion thing imho is just a hack its not really
> needed since any decent VC system can tell you the latest date a file
> was changed. The only thing we have in the top of our files is a
> version string which contains a date a release was made (not when the
> file was changed). This then makes it easier to see which actual
> release a file came from when not under version control.
>
> We just use a quick bash script to sed the version string in prior  
> to release.

Do you do that as part of 'make dist' in auto* or do you do it as a  
separate process?

> I vote to remove the whole keyword expansion thing.

Done. I just removed them all.

brian

Re: [sleuthkit-developers] Date Keyword Expansion

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

Hi Brian,
  The whole keyword expansion thing imho is just a hack its not really
needed since any decent VC system can tell you the latest date a file
was changed. The only thing we have in the top of our files is a
version string which contains a date a release was made (not when the
file was changed). This then makes it easier to see which actual
release a file came from when not under version control.

We just use a quick bash script to sed the version string in prior to release.

I vote to remove the whole keyword expansion thing.

Michael.

On Sun, Sep 28, 2008 at 12:29 AM, Brian Carrier <ca...@sl...> wrote:
> I'm in the process of migrating from CVS to SVN and will be making
> the repository public. One difference that I have found between CVS
> and SVN is the handling of keyword expansion.  SVN seems to require
> that you configure each file for keyword expansion. The TSK/autopsy
> code currently has the $Date$ keyword in each file.
>
> I'm not sure if I have ever used the $Date$ keyword in practice and
> it always forces me to rebuild a lot of files when I checkin a .h
> file. It seems error-prone to make sure that every file has the
> keyword expansion setting enabled. Any arguments on why I should keep
> it around?
>
> brian
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> sleuthkit-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers
>

[sleuthkit-developers] Date Keyword Expansion

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

I'm in the process of migrating from CVS to SVN and will be making  
the repository public. One difference that I have found between CVS  
and SVN is the handling of keyword expansion.  SVN seems to require  
that you configure each file for keyword expansion. The TSK/autopsy  
code currently has the $Date$ keyword in each file.

I'm not sure if I have ever used the $Date$ keyword in practice and  
it always forces me to rebuild a lot of files when I checkin a .h  
file. It seems error-prone to make sure that every file has the  
keyword expansion setting enabled. Any arguments on why I should keep  
it around?

brian

Re: [sleuthkit-developers] win32 live bugs?

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

Sorry, accidentally sent that early.

mingw has gethostname AFAIK, this sample compiles for me:

 #include <winsock2.h>

 int main(void) {
    char name[255];
    gethostname(name, 1);
    return 0;
 }

compile with:
i586-mingw32msvc-gcc -o test.exe test.c -lws2_32

Dave

>
>
> On Wed, Jul 23, 2008 at 9:02 PM, Michael Cohen <scu...@gm...> wrote:
>> Forgot to reply to list first, so here is a retransmission:
>>
>> Hi Brian,
>>  Its already there since you are using autoconf it can cross compile
>> for free. There are some tweaks you need to do to make sk itself
>> compile cleanly. I will summarise these here:
>>
>> 1) Have mingw installed on your linux box (apt-get install mingw32)
>> 2) Give configure the x compile flags:
>>
>>   ./configure --host=i586-mingw32msvc
>>
>> 3) tsk_base.h specifically removes autoconf support on windows - which
>> defeats the whole purpose of having autoconf - so you need to make it
>> use it:
>>
>> #if defined(__MINGW32__) || (!defined(_WIN32) && !defined (__WIN32__))
>> #include "tsk/tsk_incs.h"
>> #endif
>>
>> 4) In tsk_os.h you need to tweak some things specific to mingw:
>>
>> The section in
>> #if defined(_WIN32) || defined (__WIN32__)
>> should be inserted into #ifndef __MINGW32__
>> should not be included because most of that stuff is msvc hacks.
>> Instead add the defines for mingw:
>>
>> #ifdef __MINGW32__
>> #define roundup(x, y)   \
>>       ( ( ((x)+((y) - 1)) / (y)) * (y) )
>>
>> #define HAVE_GETHOSTNAME
>> #include <windows.h>
>> int gethostname_mingw (char *, size_t);
>>
>> #define gethostname gethostname_mingw
>> #define strtok_r(a,b,c) strtok(a,b)
>> #define fseeko fseek
>> #define daddr_t int
>>
>> #endif
>>
>> The biggest problem is that windows does not have a gethostname
>> function, instead you need to put an implementation of it like:
>>
>> #ifdef __MINGW32__
>> int
>> gethostname_mingw (char *name, size_t len)
>> {
>>  DWORD dlen = len;
>>  return (GetComputerName (name, &dlen) ? 0 : -1);
>> }
>> #endif
>>
>> Into one of the .c files (maybe you can think of a better place to put it).
>>
>> 5) make -j2 will build everything
>>
>> Let me know if you have any problems
>>
>> Michael.
>>
>> On Wed, Jul 23, 2008 at 12:53 AM, Brian Carrier <ca...@sl...> wrote:
>>> Hi Michael,
>>>
>>> I received at least one inquery about mingw-gcc support. I haven't had a
>>> chance to look into it though.  What would be required to add support for it
>>> into TSK?
>>>
>>> brian
>>>
>>> On Jul 21, 2008, at 8:47 PM, Michael Cohen wrote:
>>>
>>>> Brian,
>>>>  Would there be any interest in sharing the gcc produced binaries
>>>> which can be easily cross compiled form the main source distribution.
>>>> These are static and dont use MFC at all and are very small - they use
>>>> mingw-gcc and run natively with no dlls required.
>>>>
>>>> Michael.
>>>>
>>>> On Tue, Jul 22, 2008 at 6:37 AM, Brian Carrier <ca...@sl...>
>>>> wrote:
>>>>>
>>>>> On Jul 21, 2008, at 4:20 PM, Darren Bilby wrote:
>>>>>
>>>>>> Thanks for taking a look at this, replies inline.
>>>>>>
>>>>>> Darren.
>>>>>>
>>>>>> On Mon, Jul 21, 2008 at 6:37 PM, Brian Carrier
>>>>>> <ca...@sl...> wrote:
>>>>>>>
>>>>>>> Ok, I'll add a variation of this in, but only if the path has the
>>>>>>> form of
>>>>>>>  "\\.\?:" because I don't want random WRITE opens occurring for
>>>>>>> image files.
>>>>>>
>>>>>> Note that the FILE_SHARE_WRITE designation doesn't open the file for
>>>>>> writing, it designates how others should be able to access it, but
>>>>>> this seems sensible anyway.
>>>>>> http://msdn.microsoft.com/en-us/library/aa363874(VS.85).aspx
>>>>>> http://blogs.msdn.com/larryosterman/archive/2004/05/13/131263.aspx
>>>>>
>>>>> Ahh, even better. I had forgotten what each of the arguments to
>>>>> CreateFile meant.
>>>>>
>>>>>
>>>>>>>
>>>>>>>> 3. When recompiling with VS 2005 i get some errors on execution on
>>>>>>>> some hosts due to wrong versions of the msvc libs. Is there any
>>>>>>>> reason
>>>>>>>> we don't compile these libs in statically by default? given the
>>>>>>>> use of
>>>>>>>> these binaries it seems sensible and it only marginally affects the
>>>>>>>> size.
>>>>>>>
>>>>>>> Can you compile them in statically? I didn't think you could.
>>>>>>
>>>>>> I figured it should be possible so went looking and found "Use of
>>>>>> MFC" under:
>>>>>> Project Properties -> Configuration Properties -> General -> Use of
>>>>>> MFC
>>>>>> Setting that to "Use MFC in a Static Library" for each sleuthkit
>>>>>> project and recompiling it appears to work perfectly.
>>>>>> Searching after the fact I found:
>>>>>> http://msdn.microsoft.com/en-us/library/ms235264(VS.80).aspx
>>>>>> http://msdn.microsoft.com/en-us/library/ms235316(VS.80).aspx
>>>>>> Which advises against it, but I don't see any of the downsides being
>>>>>> applicable in this instance.
>>>>>> I did this under VC++ Express 2k8, but seems like it should work on
>>>>>> any VS.
>>>>>
>>>>> If there is a large desire to do this, I will consider it more, but
>>>>> if you are building your own executables then you probably should be
>>>>> using the MFC dlls from your compiler and not using the ones that I
>>>>> ship with the pre-built executables (which could be a different
>>>>> version).
>>>>>
>>>>> thanks,
>>>>> brian
>>>>>
>>>>>
>>>>>
>>>>> -------------------------------------------------------------------------
>>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>>> challenge
>>>>> Build the coolest Linux based applications with Moblin SDK & win great
>>>>> prizes
>>>>> Grand prize is a trip for two to an Open Source event anywhere in the
>>>>> world
>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>>> _______________________________________________
>>>>> sleuthkit-developers mailing list
>>>>> sle...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers
>>>>>
>>>
>>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> sleuthkit-developers mailing list
>> sle...@li...
>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers
>>
>

Re: [sleuthkit-developers] win32 live bugs?

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

mingw has gethostname AFAIK.

#include <winsock2.h>

int main(void) {
char name[255];
    gethostname(name, 1);
    return 0;
}


On Wed, Jul 23, 2008 at 9:02 PM, Michael Cohen <scu...@gm...> wrote:
> Forgot to reply to list first, so here is a retransmission:
>
> Hi Brian,
>  Its already there since you are using autoconf it can cross compile
> for free. There are some tweaks you need to do to make sk itself
> compile cleanly. I will summarise these here:
>
> 1) Have mingw installed on your linux box (apt-get install mingw32)
> 2) Give configure the x compile flags:
>
>   ./configure --host=i586-mingw32msvc
>
> 3) tsk_base.h specifically removes autoconf support on windows - which
> defeats the whole purpose of having autoconf - so you need to make it
> use it:
>
> #if defined(__MINGW32__) || (!defined(_WIN32) && !defined (__WIN32__))
> #include "tsk/tsk_incs.h"
> #endif
>
> 4) In tsk_os.h you need to tweak some things specific to mingw:
>
> The section in
> #if defined(_WIN32) || defined (__WIN32__)
> should be inserted into #ifndef __MINGW32__
> should not be included because most of that stuff is msvc hacks.
> Instead add the defines for mingw:
>
> #ifdef __MINGW32__
> #define roundup(x, y)   \
>       ( ( ((x)+((y) - 1)) / (y)) * (y) )
>
> #define HAVE_GETHOSTNAME
> #include <windows.h>
> int gethostname_mingw (char *, size_t);
>
> #define gethostname gethostname_mingw
> #define strtok_r(a,b,c) strtok(a,b)
> #define fseeko fseek
> #define daddr_t int
>
> #endif
>
> The biggest problem is that windows does not have a gethostname
> function, instead you need to put an implementation of it like:
>
> #ifdef __MINGW32__
> int
> gethostname_mingw (char *name, size_t len)
> {
>  DWORD dlen = len;
>  return (GetComputerName (name, &dlen) ? 0 : -1);
> }
> #endif
>
> Into one of the .c files (maybe you can think of a better place to put it).
>
> 5) make -j2 will build everything
>
> Let me know if you have any problems
>
> Michael.
>
> On Wed, Jul 23, 2008 at 12:53 AM, Brian Carrier <ca...@sl...> wrote:
>> Hi Michael,
>>
>> I received at least one inquery about mingw-gcc support. I haven't had a
>> chance to look into it though.  What would be required to add support for it
>> into TSK?
>>
>> brian
>>
>> On Jul 21, 2008, at 8:47 PM, Michael Cohen wrote:
>>
>>> Brian,
>>>  Would there be any interest in sharing the gcc produced binaries
>>> which can be easily cross compiled form the main source distribution.
>>> These are static and dont use MFC at all and are very small - they use
>>> mingw-gcc and run natively with no dlls required.
>>>
>>> Michael.
>>>
>>> On Tue, Jul 22, 2008 at 6:37 AM, Brian Carrier <ca...@sl...>
>>> wrote:
>>>>
>>>> On Jul 21, 2008, at 4:20 PM, Darren Bilby wrote:
>>>>
>>>>> Thanks for taking a look at this, replies inline.
>>>>>
>>>>> Darren.
>>>>>
>>>>> On Mon, Jul 21, 2008 at 6:37 PM, Brian Carrier
>>>>> <ca...@sl...> wrote:
>>>>>>
>>>>>> Ok, I'll add a variation of this in, but only if the path has the
>>>>>> form of
>>>>>>  "\\.\?:" because I don't want random WRITE opens occurring for
>>>>>> image files.
>>>>>
>>>>> Note that the FILE_SHARE_WRITE designation doesn't open the file for
>>>>> writing, it designates how others should be able to access it, but
>>>>> this seems sensible anyway.
>>>>> http://msdn.microsoft.com/en-us/library/aa363874(VS.85).aspx
>>>>> http://blogs.msdn.com/larryosterman/archive/2004/05/13/131263.aspx
>>>>
>>>> Ahh, even better. I had forgotten what each of the arguments to
>>>> CreateFile meant.
>>>>
>>>>
>>>>>>
>>>>>>> 3. When recompiling with VS 2005 i get some errors on execution on
>>>>>>> some hosts due to wrong versions of the msvc libs. Is there any
>>>>>>> reason
>>>>>>> we don't compile these libs in statically by default? given the
>>>>>>> use of
>>>>>>> these binaries it seems sensible and it only marginally affects the
>>>>>>> size.
>>>>>>
>>>>>> Can you compile them in statically? I didn't think you could.
>>>>>
>>>>> I figured it should be possible so went looking and found "Use of
>>>>> MFC" under:
>>>>> Project Properties -> Configuration Properties -> General -> Use of
>>>>> MFC
>>>>> Setting that to "Use MFC in a Static Library" for each sleuthkit
>>>>> project and recompiling it appears to work perfectly.
>>>>> Searching after the fact I found:
>>>>> http://msdn.microsoft.com/en-us/library/ms235264(VS.80).aspx
>>>>> http://msdn.microsoft.com/en-us/library/ms235316(VS.80).aspx
>>>>> Which advises against it, but I don't see any of the downsides being
>>>>> applicable in this instance.
>>>>> I did this under VC++ Express 2k8, but seems like it should work on
>>>>> any VS.
>>>>
>>>> If there is a large desire to do this, I will consider it more, but
>>>> if you are building your own executables then you probably should be
>>>> using the MFC dlls from your compiler and not using the ones that I
>>>> ship with the pre-built executables (which could be a different
>>>> version).
>>>>
>>>> thanks,
>>>> brian
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------------------------
>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>> challenge
>>>> Build the coolest Linux based applications with Moblin SDK & win great
>>>> prizes
>>>> Grand prize is a trip for two to an Open Source event anywhere in the
>>>> world
>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>> _______________________________________________
>>>> sleuthkit-developers mailing list
>>>> sle...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers
>>>>
>>
>>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> sleuthkit-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers
>

Re: [sleuthkit-developers] win32 live bugs?

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

Forgot to reply to list first, so here is a retransmission:

Hi Brian,
 Its already there since you are using autoconf it can cross compile
for free. There are some tweaks you need to do to make sk itself
compile cleanly. I will summarise these here:

1) Have mingw installed on your linux box (apt-get install mingw32)
2) Give configure the x compile flags:

   ./configure --host=i586-mingw32msvc

3) tsk_base.h specifically removes autoconf support on windows - which
defeats the whole purpose of having autoconf - so you need to make it
use it:

#if defined(__MINGW32__) || (!defined(_WIN32) && !defined (__WIN32__))
#include "tsk/tsk_incs.h"
#endif

4) In tsk_os.h you need to tweak some things specific to mingw:

The section in
#if defined(_WIN32) || defined (__WIN32__)
should be inserted into #ifndef __MINGW32__
should not be included because most of that stuff is msvc hacks.
Instead add the defines for mingw:

#ifdef __MINGW32__
#define roundup(x, y)   \
       ( ( ((x)+((y) - 1)) / (y)) * (y) )

#define HAVE_GETHOSTNAME
#include <windows.h>
int gethostname_mingw (char *, size_t);

#define gethostname gethostname_mingw
#define strtok_r(a,b,c) strtok(a,b)
#define fseeko fseek
#define daddr_t int

#endif

The biggest problem is that windows does not have a gethostname
function, instead you need to put an implementation of it like:

#ifdef __MINGW32__
int
gethostname_mingw (char *name, size_t len)
{
 DWORD dlen = len;
 return (GetComputerName (name, &dlen) ? 0 : -1);
}
#endif

Into one of the .c files (maybe you can think of a better place to put it).

5) make -j2 will build everything

Let me know if you have any problems

Michael.

On Wed, Jul 23, 2008 at 12:53 AM, Brian Carrier <ca...@sl...> wrote:
> Hi Michael,
>
> I received at least one inquery about mingw-gcc support. I haven't had a
> chance to look into it though.  What would be required to add support for it
> into TSK?
>
> brian
>
> On Jul 21, 2008, at 8:47 PM, Michael Cohen wrote:
>
>> Brian,
>>  Would there be any interest in sharing the gcc produced binaries
>> which can be easily cross compiled form the main source distribution.
>> These are static and dont use MFC at all and are very small - they use
>> mingw-gcc and run natively with no dlls required.
>>
>> Michael.
>>
>> On Tue, Jul 22, 2008 at 6:37 AM, Brian Carrier <ca...@sl...>
>> wrote:
>>>
>>> On Jul 21, 2008, at 4:20 PM, Darren Bilby wrote:
>>>
>>>> Thanks for taking a look at this, replies inline.
>>>>
>>>> Darren.
>>>>
>>>> On Mon, Jul 21, 2008 at 6:37 PM, Brian Carrier
>>>> <ca...@sl...> wrote:
>>>>>
>>>>> Ok, I'll add a variation of this in, but only if the path has the
>>>>> form of
>>>>>  "\\.\?:" because I don't want random WRITE opens occurring for
>>>>> image files.
>>>>
>>>> Note that the FILE_SHARE_WRITE designation doesn't open the file for
>>>> writing, it designates how others should be able to access it, but
>>>> this seems sensible anyway.
>>>> http://msdn.microsoft.com/en-us/library/aa363874(VS.85).aspx
>>>> http://blogs.msdn.com/larryosterman/archive/2004/05/13/131263.aspx
>>>
>>> Ahh, even better. I had forgotten what each of the arguments to
>>> CreateFile meant.
>>>
>>>
>>>>>
>>>>>> 3. When recompiling with VS 2005 i get some errors on execution on
>>>>>> some hosts due to wrong versions of the msvc libs. Is there any
>>>>>> reason
>>>>>> we don't compile these libs in statically by default? given the
>>>>>> use of
>>>>>> these binaries it seems sensible and it only marginally affects the
>>>>>> size.
>>>>>
>>>>> Can you compile them in statically? I didn't think you could.
>>>>
>>>> I figured it should be possible so went looking and found "Use of
>>>> MFC" under:
>>>> Project Properties -> Configuration Properties -> General -> Use of
>>>> MFC
>>>> Setting that to "Use MFC in a Static Library" for each sleuthkit
>>>> project and recompiling it appears to work perfectly.
>>>> Searching after the fact I found:
>>>> http://msdn.microsoft.com/en-us/library/ms235264(VS.80).aspx
>>>> http://msdn.microsoft.com/en-us/library/ms235316(VS.80).aspx
>>>> Which advises against it, but I don't see any of the downsides being
>>>> applicable in this instance.
>>>> I did this under VC++ Express 2k8, but seems like it should work on
>>>> any VS.
>>>
>>> If there is a large desire to do this, I will consider it more, but
>>> if you are building your own executables then you probably should be
>>> using the MFC dlls from your compiler and not using the ones that I
>>> ship with the pre-built executables (which could be a different
>>> version).
>>>
>>> thanks,
>>> brian
>>>
>>>
>>>
>>> -------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win great
>>> prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in the
>>> world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> sleuthkit-developers mailing list
>>> sle...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers
>>>
>
>

Re: [sleuthkit-developers] win32 live bugs?

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

Hi Michael,

I received at least one inquery about mingw-gcc support. I haven't  
had a chance to look into it though.  What would be required to add  
support for it into TSK?

brian

On Jul 21, 2008, at 8:47 PM, Michael Cohen wrote:

> Brian,
>   Would there be any interest in sharing the gcc produced binaries
> which can be easily cross compiled form the main source distribution.
> These are static and dont use MFC at all and are very small - they use
> mingw-gcc and run natively with no dlls required.
>
> Michael.
>
> On Tue, Jul 22, 2008 at 6:37 AM, Brian Carrier  
> <ca...@sl...> wrote:
>>
>> On Jul 21, 2008, at 4:20 PM, Darren Bilby wrote:
>>
>>> Thanks for taking a look at this, replies inline.
>>>
>>> Darren.
>>>
>>> On Mon, Jul 21, 2008 at 6:37 PM, Brian Carrier
>>> <ca...@sl...> wrote:
>>>>
>>>> Ok, I'll add a variation of this in, but only if the path has the
>>>> form of
>>>>  "\\.\?:" because I don't want random WRITE opens occurring for
>>>> image files.
>>>
>>> Note that the FILE_SHARE_WRITE designation doesn't open the file for
>>> writing, it designates how others should be able to access it, but
>>> this seems sensible anyway.
>>> http://msdn.microsoft.com/en-us/library/aa363874(VS.85).aspx
>>> http://blogs.msdn.com/larryosterman/archive/2004/05/13/131263.aspx
>>
>> Ahh, even better. I had forgotten what each of the arguments to
>> CreateFile meant.
>>
>>
>>>>
>>>>> 3. When recompiling with VS 2005 i get some errors on execution on
>>>>> some hosts due to wrong versions of the msvc libs. Is there any
>>>>> reason
>>>>> we don't compile these libs in statically by default? given the
>>>>> use of
>>>>> these binaries it seems sensible and it only marginally affects  
>>>>> the
>>>>> size.
>>>>
>>>> Can you compile them in statically? I didn't think you could.
>>>
>>> I figured it should be possible so went looking and found "Use of
>>> MFC" under:
>>> Project Properties -> Configuration Properties -> General -> Use of
>>> MFC
>>> Setting that to "Use MFC in a Static Library" for each sleuthkit
>>> project and recompiling it appears to work perfectly.
>>> Searching after the fact I found:
>>> http://msdn.microsoft.com/en-us/library/ms235264(VS.80).aspx
>>> http://msdn.microsoft.com/en-us/library/ms235316(VS.80).aspx
>>> Which advises against it, but I don't see any of the downsides being
>>> applicable in this instance.
>>> I did this under VC++ Express 2k8, but seems like it should work on
>>> any VS.
>>
>> If there is a large desire to do this, I will consider it more, but
>> if you are building your own executables then you probably should be
>> using the MFC dlls from your compiler and not using the ones that I
>> ship with the pre-built executables (which could be a different
>> version).
>>
>> thanks,
>> brian
>>
>>
>>
>> --------------------------------------------------------------------- 
>> ----
>> This SF.Net email is sponsored by the Moblin Your Move Developer's  
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win  
>> great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in  
>> the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> sleuthkit-developers mailing list
>> sle...@li...
>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers
>>

Re: [sleuthkit-developers] win32 live bugs?

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

Brian,
  Would there be any interest in sharing the gcc produced binaries
which can be easily cross compiled form the main source distribution.
These are static and dont use MFC at all and are very small - they use
mingw-gcc and run natively with no dlls required.

Michael.

On Tue, Jul 22, 2008 at 6:37 AM, Brian Carrier <ca...@sl...> wrote:
>
> On Jul 21, 2008, at 4:20 PM, Darren Bilby wrote:
>
>> Thanks for taking a look at this, replies inline.
>>
>> Darren.
>>
>> On Mon, Jul 21, 2008 at 6:37 PM, Brian Carrier
>> <ca...@sl...> wrote:
>>>
>>> Ok, I'll add a variation of this in, but only if the path has the
>>> form of
>>>  "\\.\?:" because I don't want random WRITE opens occurring for
>>> image files.
>>
>> Note that the FILE_SHARE_WRITE designation doesn't open the file for
>> writing, it designates how others should be able to access it, but
>> this seems sensible anyway.
>> http://msdn.microsoft.com/en-us/library/aa363874(VS.85).aspx
>> http://blogs.msdn.com/larryosterman/archive/2004/05/13/131263.aspx
>
> Ahh, even better. I had forgotten what each of the arguments to
> CreateFile meant.
>
>
>>>
>>>> 3. When recompiling with VS 2005 i get some errors on execution on
>>>> some hosts due to wrong versions of the msvc libs. Is there any
>>>> reason
>>>> we don't compile these libs in statically by default? given the
>>>> use of
>>>> these binaries it seems sensible and it only marginally affects the
>>>> size.
>>>
>>> Can you compile them in statically? I didn't think you could.
>>
>> I figured it should be possible so went looking and found "Use of
>> MFC" under:
>> Project Properties -> Configuration Properties -> General -> Use of
>> MFC
>> Setting that to "Use MFC in a Static Library" for each sleuthkit
>> project and recompiling it appears to work perfectly.
>> Searching after the fact I found:
>> http://msdn.microsoft.com/en-us/library/ms235264(VS.80).aspx
>> http://msdn.microsoft.com/en-us/library/ms235316(VS.80).aspx
>> Which advises against it, but I don't see any of the downsides being
>> applicable in this instance.
>> I did this under VC++ Express 2k8, but seems like it should work on
>> any VS.
>
> If there is a large desire to do this, I will consider it more, but
> if you are building your own executables then you probably should be
> using the MFC dlls from your compiler and not using the ones that I
> ship with the pre-built executables (which could be a different
> version).
>
> thanks,
> brian
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> sleuthkit-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers
>

Re: [sleuthkit-developers] win32 live bugs?

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

On Jul 21, 2008, at 4:20 PM, Darren Bilby wrote:

> Thanks for taking a look at this, replies inline.
>
> Darren.
>
> On Mon, Jul 21, 2008 at 6:37 PM, Brian Carrier  
> <ca...@sl...> wrote:
>>
>> Ok, I'll add a variation of this in, but only if the path has the  
>> form of
>>  "\\.\?:" because I don't want random WRITE opens occurring for  
>> image files.
>
> Note that the FILE_SHARE_WRITE designation doesn't open the file for
> writing, it designates how others should be able to access it, but
> this seems sensible anyway.
> http://msdn.microsoft.com/en-us/library/aa363874(VS.85).aspx
> http://blogs.msdn.com/larryosterman/archive/2004/05/13/131263.aspx

Ahh, even better. I had forgotten what each of the arguments to  
CreateFile meant.


>>
>>> 3. When recompiling with VS 2005 i get some errors on execution on
>>> some hosts due to wrong versions of the msvc libs. Is there any  
>>> reason
>>> we don't compile these libs in statically by default? given the  
>>> use of
>>> these binaries it seems sensible and it only marginally affects the
>>> size.
>>
>> Can you compile them in statically? I didn't think you could.
>
> I figured it should be possible so went looking and found "Use of  
> MFC" under:
> Project Properties -> Configuration Properties -> General -> Use of  
> MFC
> Setting that to "Use MFC in a Static Library" for each sleuthkit
> project and recompiling it appears to work perfectly.
> Searching after the fact I found:
> http://msdn.microsoft.com/en-us/library/ms235264(VS.80).aspx
> http://msdn.microsoft.com/en-us/library/ms235316(VS.80).aspx
> Which advises against it, but I don't see any of the downsides being
> applicable in this instance.
> I did this under VC++ Express 2k8, but seems like it should work on  
> any VS.

If there is a large desire to do this, I will consider it more, but  
if you are building your own executables then you probably should be  
using the MFC dlls from your compiler and not using the ones that I  
ship with the pre-built executables (which could be a different  
version).

thanks,
brian

Re: [sleuthkit-developers] win32 live bugs?

[Darren B. <dar...@gm...>]

Thanks for taking a look at this, replies inline.

Darren.

On Mon, Jul 21, 2008 at 6:37 PM, Brian Carrier <ca...@sl...> wrote:

>> 2. Access to \\.\C: doesn't work on a live system as due to a sharing
>> violation. I care about this because going via \\.\PhysicalDrive0
>> won't work for full disk encrypted drives. The problem is raw.c line
>> 237 where the image file is opened FILE_SHARE_READ, this is normally
>> correct, but in the case of volumes this will always fail. It is
>> possible however to open as FILE_SHARE_WRITE and then read the volume.
>> I have patched this and it works, but I guess we could add something
>> that tries FILE_SHARE_READ, the falls back to FILE_SHARE_WRITE on
>> failure. Happy to submit a patch for this if it is deemed useful.
>
> Ok, I'll add a variation of this in, but only if the path has the form of
>  "\\.\?:" because I don't want random WRITE opens occurring for image files.

Note that the FILE_SHARE_WRITE designation doesn't open the file for
writing, it designates how others should be able to access it, but
this seems sensible anyway.
http://msdn.microsoft.com/en-us/library/aa363874(VS.85).aspx
http://blogs.msdn.com/larryosterman/archive/2004/05/13/131263.aspx

>
>> 3. When recompiling with VS 2005 i get some errors on execution on
>> some hosts due to wrong versions of the msvc libs. Is there any reason
>> we don't compile these libs in statically by default? given the use of
>> these binaries it seems sensible and it only marginally affects the
>> size.
>
> Can you compile them in statically? I didn't think you could.

I figured it should be possible so went looking and found "Use of MFC" under:
Project Properties -> Configuration Properties -> General -> Use of MFC
Setting that to "Use MFC in a Static Library" for each sleuthkit
project and recompiling it appears to work perfectly.
Searching after the fact I found:
http://msdn.microsoft.com/en-us/library/ms235264(VS.80).aspx
http://msdn.microsoft.com/en-us/library/ms235316(VS.80).aspx
Which advises against it, but I don't see any of the downsides being
applicable in this instance.
I did this under VC++ Express 2k8, but seems like it should work on any VS.

Re: [sleuthkit-developers] win32 live bugs?

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

Comments inline.

On Jul 17, 2008, at 10:14 AM, Darren Bilby wrote:

> Hi folks,
>
> I've been using sleuthkit for a long time, but I've been doing some
> testing with sleuthkit-win32 version 2.52 on live systems and come
> across a couple of odd things, would be appreciated if someone could
> verify these.
>
> 1. there is a bug in the ntfs for ifind_lib.c parsing that seems to
> only rear it's head when running on Windows, i'm guessing this is an
> implementation difference in the string comparison routines used. No
> idea if it affects other places but may be worth a look. ifind -n
> /windows/system32/drivers/etc/hosts \\.\C: should show up the issue.
> Essentially, during directory traversal there is a string comparison
> on line 166:
> if (strcasecmp(a_fs_dent->name, ipd->cur_dir) != 0) {
> which in the case of hunting for c:\windows\system32 actually finds
> c:\windows\system due to the string comparison only checking to length
> of the first param a_fs_dent->name (system). This means ifind won't
> find anything under c:\windows\system32 on any windows system in its
> current form.
> changing to the below fixes it:
> if (strcasecmp(ipd->cur_dir, a_fs_dent->name) != 0) {

I fixed this by defining strcasecmp to map to _stricmp instead of  
_strnicmp.  I don't remember why I did that in the first place...

> 2. Access to \\.\C: doesn't work on a live system as due to a sharing
> violation. I care about this because going via \\.\PhysicalDrive0
> won't work for full disk encrypted drives. The problem is raw.c line
> 237 where the image file is opened FILE_SHARE_READ, this is normally
> correct, but in the case of volumes this will always fail. It is
> possible however to open as FILE_SHARE_WRITE and then read the volume.
> I have patched this and it works, but I guess we could add something
> that tries FILE_SHARE_READ, the falls back to FILE_SHARE_WRITE on
> failure. Happy to submit a patch for this if it is deemed useful.

Ok, I'll add a variation of this in, but only if the path has the  
form of  "\\.\?:" because I don't want random WRITE opens occurring  
for image files.

> 3. When recompiling with VS 2005 i get some errors on execution on
> some hosts due to wrong versions of the msvc libs. Is there any reason
> we don't compile these libs in statically by default? given the use of
> these binaries it seems sensible and it only marginally affects the
> size.

Can you compile them in statically? I didn't think you could.

thanks!
brian

Re: [sleuthkit-developers] win32 live bugs?

[Darren B. <dar...@gm...>]

Hi folks,

I've been using sleuthkit for a long time, but I've been doing some
testing with sleuthkit-win32 version 2.52 on live systems and come
across a couple of odd things, would be appreciated if someone could
verify these.

1. there is a bug in the ntfs for ifind_lib.c parsing that seems to
only rear it's head when running on Windows, i'm guessing this is an
implementation difference in the string comparison routines used. No
idea if it affects other places but may be worth a look. ifind -n
/windows/system32/drivers/etc/hosts \\.\C: should show up the issue.
Essentially, during directory traversal there is a string comparison
on line 166:
if (strcasecmp(a_fs_dent->name, ipd->cur_dir) != 0) {
which in the case of hunting for c:\windows\system32 actually finds
c:\windows\system due to the string comparison only checking to length
of the first param a_fs_dent->name (system). This means ifind won't
find anything under c:\windows\system32 on any windows system in its
current form.
changing to the below fixes it:
if (strcasecmp(ipd->cur_dir, a_fs_dent->name) != 0) {

2. Access to \\.\C: doesn't work on a live system as due to a sharing
violation. I care about this because going via \\.\PhysicalDrive0
won't work for full disk encrypted drives. The problem is raw.c line
237 where the image file is opened FILE_SHARE_READ, this is normally
correct, but in the case of volumes this will always fail. It is
possible however to open as FILE_SHARE_WRITE and then read the volume.
I have patched this and it works, but I guess we could add something
that tries FILE_SHARE_READ, the falls back to FILE_SHARE_WRITE on
failure. Happy to submit a patch for this if it is deemed useful.

3. When recompiling with VS 2005 i get some errors on execution on
some hosts due to wrong versions of the msvc libs. Is there any reason
we don't compile these libs in statically by default? given the use of
these binaries it seems sensible and it only marginally affects the
size.

thanks

Darren.

[sleuthkit-developers] Need for special RECOVER flag?

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

Currently, there is a TSK_FS_FILE_FLAG_RECOVER flag that can be  
passed to file_walk so that "special" data recovery techniques are  
used.  This really only has an effect on FAT (because other file  
systems are either all or nothing and the recovery "guessing"  
associated with FAT does not exist). If you do not pass the RECOVER  
flag with a deleted FAT file then you get only the first cluster of  
the file.  If you pass the RECOVER flag, TSK tries to recover the  
full file and if it can it returns it.  If it can't, it returns an  
error. The caller must then know to try again without the RECOVER  
flag so that they at least get the first cluster.

My open question is if this flag is needed?  Should TSK apply  
recovery techniques to all unallocated files regardless if the flag  
is given or not?

The benefit of this approach is that it simplifies the calling code  
because they do not need to retry if the RECOVER attempt fails.

The downside of this approach is it hides the fact that there is  
guessing going on behind the scenes with respect to choosing the  
data, but then again all unallocated files have uncertainty  
associated with them.

Thoughts?

brian

Re: [sleuthkit-developers] extra directory entries found in ext2 by sk

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

Hi David,

These are false positives that result from the goal of supporting non- 
Latin file names (ExtX stores non-Latin text in UTF-8) and file names  
with control characters (both of which can occur). So, the code that  
parses through the directory looking for deleted directory entries  
can't really do any checks on the text of the file name (because  
everything is "valid" if we allow control characters).  We allow  
control characters because they do not seem to be uncommon and when I  
disabled the support a while back I quickly had requests to enable it  
again. The current code "cleans" up control characters by replacing  
them with a '^'.

The code that tests the directory entries now looks at the other non- 
name fields.  It checks if the inode number is too big, if the record  
length is shorter than the name length, if the record length is not a  
multiple of 4 etc. So, there will be false positives.

brian


On Jul 5, 2008, at 12:23 AM, David Collett wrote:

> Hi Brian,
>
> Sleuthkit (fls) seems to find bogus deleted directory entries in the
> following (ext2) image:
>
> http://www.pyflag.net/testimages/pyflag_stdimage_0.1.e01
>
> The offending entries are the three containing non-printable
> characters (output appended below).
> I've opened the same fs in 'debugfs' and it does not find these
> deleted entries (it does find all the others that sk finds).
> Can you explain this? Is sk being over zealous in its search for
> deleted ext2 directory entries? Is it normal to get a few
> false-positives?
>
> Thanks,
> Dave
>
> Here is the output of "fls -r":
>
> d/d 11:	lost+found
> r/- * 0:	0000000001289728.jpg
> r/- * 0:	NTUSER.DAT
> r/r 14:	hello.txt
> d/d 1281:	Documents and Settings
> + d/d 1282:	Administrator
> ++ d/d 1283:	Local Settings
> +++ r/r 1284:	index.dat
> +++ -/- * 0:	@"^^��������^
> +++ -/r * 20(realloc):	 
> ��^^��������������������^
> ++ r/r 1285:	outlook.pst
> ++ r/r 13:	NTUSER.DAT
> + -/r * 20(realloc):	 
> `,^^�����������������^
> r/r 15:	rk_044.zip
> r/r 16:	test.txt.gz
> r/r 17:	test.zip
> r/r 18:	dscf1081.jpg
> r/r 19:	dscf1082.jpg
> r/r 20:	dscf1080.jpg
> r/- * 0:	dscf1061.jpg
> r/r 22:	dscf1052.jpg
> r/- * 0:	.DonVittos_private_key.txt.swp
> r/r 23:	DonVittos_private_key.txt
> ---------------------------------------------------------------------- 
> ---
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> sleuthkit-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers

[sleuthkit-developers] extra directory entries found in ext2 by sk

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

Hi Brian,

Sleuthkit (fls) seems to find bogus deleted directory entries in the
following (ext2) image:

http://www.pyflag.net/testimages/pyflag_stdimage_0.1.e01

The offending entries are the three containing non-printable
characters (output appended below).
I've opened the same fs in 'debugfs' and it does not find these
deleted entries (it does find all the others that sk finds).
Can you explain this? Is sk being over zealous in its search for
deleted ext2 directory entries? Is it normal to get a few
false-positives?

Thanks,
Dave

Here is the output of "fls -r":

d/d 11:	lost+found
r/- * 0:	0000000001289728.jpg
r/- * 0:	NTUSER.DAT
r/r 14:	hello.txt
d/d 1281:	Documents and Settings
+ d/d 1282:	Administrator
++ d/d 1283:	Local Settings
+++ r/r 1284:	index.dat
+++ -/- * 0:	@"^^��������^
+++ -/r * 20(realloc):	��^^��������������������^
++ r/r 1285:	outlook.pst
++ r/r 13:	NTUSER.DAT
+ -/r * 20(realloc):	`,^^�����������������^
r/r 15:	rk_044.zip
r/r 16:	test.txt.gz
r/r 17:	test.zip
r/r 18:	dscf1081.jpg
r/r 19:	dscf1082.jpg
r/r 20:	dscf1080.jpg
r/- * 0:	dscf1061.jpg
r/r 22:	dscf1052.jpg
r/- * 0:	.DonVittos_private_key.txt.swp
r/r 23:	DonVittos_private_key.txt

Re: [sleuthkit-developers] Small bug in fs_io.c

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

Thanks Michael!

On Jul 1, 2008, at 5:47 AM, Michael Cohen wrote:

> Hi Brian,
>   I have just hit a small bug in fs_io.c in fs_read_file_int we  
> have the check:
>
>     if(offset > fsi->size) {
>       return 0;
>     }
>
> This is normally perfectly reasonable, except when callers specified
> the TSK_FS_FILE_FLAG_SLACK flag. This that case users want to read
> past the end of the file, and so therefore should be allowed to also
> seek past the end of the file. The current check stops callers from
> seeking and reading buffers purely from the slack - but they can read
> the slack if they start reading within the file and read buffers into
> the slack. Anyway a small patch like:
>
>     // If callers wanted slack its perfectly reasonable for them to
>     // read past the end of the file.
>     if (!(flagsBase & TSK_FS_FILE_FLAG_SLACK) && offset > fsi->size) {
>       return 0;
>     }
> seems to fix things.
>
> Michael.
>
> ---------------------------------------------------------------------- 
> ---
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> sleuthkit-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers

[sleuthkit-developers] Small bug in fs_io.c

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

Hi Brian,
  I have just hit a small bug in fs_io.c in fs_read_file_int we have the check:

    if(offset > fsi->size) {
      return 0;
    }

This is normally perfectly reasonable, except when callers specified
the TSK_FS_FILE_FLAG_SLACK flag. This that case users want to read
past the end of the file, and so therefore should be allowed to also
seek past the end of the file. The current check stops callers from
seeking and reading buffers purely from the slack - but they can read
the slack if they start reading within the file and read buffers into
the slack. Anyway a small patch like:

    // If callers wanted slack its perfectly reasonable for them to
    // read past the end of the file.
    if (!(flagsBase & TSK_FS_FILE_FLAG_SLACK) && offset > fsi->size) {
      return 0;
    }
seems to fix things.

Michael.

Re: [sleuthkit-developers] Valgrind problems with iso9660

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

Hi Michael again,

Thanks.  I hadn't hit that one yet, but I found a similar issue a  
little while back and modified tsk_malloc() to do a memset for all  
memory allocated.

I haven't run valgrind in a while, but I should since I have made so  
many changes recently for the new APIs.  I'll make sure I do.

thanks,
brian


On Jun 23, 2008, at 8:41 AM, Michael Cohen wrote:

> Hi All,
>   I was tracking down a crash in pyflag's sk support and ran valgrind
> on fls with an iso image. It turns out that in iso9660.c at line 406
> the structure in_inode is allocated, but not initialised. This may
> cause a crash later in line 571:
>
>    if (in_node->inode.rr)
>                         free(in_node->inode.rr);
>
> (because there could be any rubbish in there).
>
> I found that a             memset(in_node, 0 , sizeof 
> (iso9660_inode_node));
> right after the allocation at line 412 fixed things.
>
> Also added a     memset(&t, 0, sizeof(t));
> at line 869 to stop other valgrind complaints.
>
> Probably not a bad idea to run valgrind over all the sk tools now and
> again. The ntfs drivers are certainly very quiet with valgrind which
> is great.
>
> Thanks,
> Michael.
>
> ---------------------------------------------------------------------- 
> ---
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> sleuthkit-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers

Re: [sleuthkit-developers] regression bug in sleuthkit iso9660

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

Hi Michael,

Someone reported this a little while ago and I fixed it as you  
suggested.  I force it to the big endian layout with:

     tmpguess[0] = 0;
     tmpguess[1] = 0;
     tmpguess[2] = 0;
     tmpguess[3] = 1;
     tsk_fs_guessu32(fs, tmpguess, 1);

The idea of notifying if the different orderings are different is an  
interesting one.

thanks,
brian

On Jun 23, 2008, at 7:08 AM, Michael Cohen wrote:

> Hi All,
>   There seems to be a regression bug in sk iso9660 handling. The
> problem started during version 2.10 (i.e. 2.09 worked correctly).
> Version 2.09 defines the following macro:
>
> #define parseu32(foo, x) \
>     (uint32_t)( (foo->endian & TSK_LIT_ENDIAN)  ? \
>     ((uint32_t) \
>         ((uint32_t)((uint8_t *)(x))[0] << 0) + \
>         ((uint32_t)((uint8_t *)(x))[1] << 8) + \
>         ((uint32_t)((uint8_t *)(x))[2] << 16) + \
>         ((uint32_t)((uint8_t *)(x))[3] << 24)) \
>         : \
>     ((uint32_t) \
>         ((uint32_t)((uint8_t *)(x))[7] << 0) + \
>         ((uint32_t)((uint8_t *)(x))[6] << 8) + \
>         ((uint32_t)((uint8_t *)(x))[5] << 16) + \
>         ((uint32_t)((uint8_t *)(x))[4] << 24)) )
>
> Note that x is an unsigned char [8]. In particular this is called from
> iso9660_open as:
> fs->block_count = parseu32(fs, iso->pvd->pvd.vol_spc)
>
> In sk 2.10 the primary volume descriptor was redefined to have better
> granularity. In particular the volume size was split into 2 parts:
>
>     uint8_t vs_sz_l[ISODCL(81, 84)];    /* volume space size in  
> blocks - le */
>     uint8_t vs_sz_m[ISODCL(85, 88)];    /* volume space size in  
> blocks - be */
>
> presumable the iso header specifies the same quantity both in big and
> little endian. iso9660_open then goes to calculate the block_count as:
>
> if (iso->pvd) {
>         fs->block_size = tsk_getu16(fs->endian, iso->pvd- 
> >pvd.blk_sz_m);
>         fs->block_count = tsk_getu32(fs->endian, iso->pvd- 
> >pvd.vs_sz_m);
>     }
>
> This is wrong now because fs->endian can be big or little presumably,
> but iso->pvd->pvd.vs_sz_m is always big endian. The correct call
> should be (or equally we can choose the big endian version too):
> if (iso->pvd) {
>         fs->block_size = tsk_getu16(TSK_LIT_ENDIAN, iso->pvd- 
> >pvd.blk_sz_l);
>         fs->block_count = tsk_getu32(TSK_LIT_ENDIAN, iso->pvd- 
> >pvd.vs_sz_l);
>     }
>
> That is we should just pick an endianess and use the corresponding
> vs_sz_X.  I guess from a forensic pov what if they say different
> things? Presumably the os which mounts it would only look at either
> the big endian version or the little endian version. Maybe this can
> result in a disk which shows more files if mounted on a big endian
> machine vs a little endian machine???  Maybe SK should issue warnings
> if the fields contradict.
>
> Michael.
>
> ---------------------------------------------------------------------- 
> ---
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> sleuthkit-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers

[sleuthkit-developers] Valgrind problems with iso9660

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

Hi All,
  I was tracking down a crash in pyflag's sk support and ran valgrind
on fls with an iso image. It turns out that in iso9660.c at line 406
the structure in_inode is allocated, but not initialised. This may
cause a crash later in line 571:

   if (in_node->inode.rr)
                        free(in_node->inode.rr);

(because there could be any rubbish in there).

I found that a             memset(in_node, 0 , sizeof(iso9660_inode_node));
right after the allocation at line 412 fixed things.

Also added a     memset(&t, 0, sizeof(t));
at line 869 to stop other valgrind complaints.

Probably not a bad idea to run valgrind over all the sk tools now and
again. The ntfs drivers are certainly very quiet with valgrind which
is great.

Thanks,
Michael.

[sleuthkit-developers] regression bug in sleuthkit iso9660

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

Hi All,
  There seems to be a regression bug in sk iso9660 handling. The
problem started during version 2.10 (i.e. 2.09 worked correctly).
Version 2.09 defines the following macro:

#define parseu32(foo, x) \
    (uint32_t)( (foo->endian & TSK_LIT_ENDIAN)  ? \
    ((uint32_t) \
        ((uint32_t)((uint8_t *)(x))[0] << 0) + \
        ((uint32_t)((uint8_t *)(x))[1] << 8) + \
        ((uint32_t)((uint8_t *)(x))[2] << 16) + \
        ((uint32_t)((uint8_t *)(x))[3] << 24)) \
        : \
    ((uint32_t) \
        ((uint32_t)((uint8_t *)(x))[7] << 0) + \
        ((uint32_t)((uint8_t *)(x))[6] << 8) + \
        ((uint32_t)((uint8_t *)(x))[5] << 16) + \
        ((uint32_t)((uint8_t *)(x))[4] << 24)) )

Note that x is an unsigned char [8]. In particular this is called from
iso9660_open as:
fs->block_count = parseu32(fs, iso->pvd->pvd.vol_spc)

In sk 2.10 the primary volume descriptor was redefined to have better
granularity. In particular the volume size was split into 2 parts:

    uint8_t vs_sz_l[ISODCL(81, 84)];    /* volume space size in blocks - le */
    uint8_t vs_sz_m[ISODCL(85, 88)];    /* volume space size in blocks - be */

presumable the iso header specifies the same quantity both in big and
little endian. iso9660_open then goes to calculate the block_count as:

if (iso->pvd) {
        fs->block_size = tsk_getu16(fs->endian, iso->pvd->pvd.blk_sz_m);
        fs->block_count = tsk_getu32(fs->endian, iso->pvd->pvd.vs_sz_m);
    }

This is wrong now because fs->endian can be big or little presumably,
but iso->pvd->pvd.vs_sz_m is always big endian. The correct call
should be (or equally we can choose the big endian version too):
if (iso->pvd) {
        fs->block_size = tsk_getu16(TSK_LIT_ENDIAN, iso->pvd->pvd.blk_sz_l);
        fs->block_count = tsk_getu32(TSK_LIT_ENDIAN, iso->pvd->pvd.vs_sz_l);
    }

That is we should just pick an endianess and use the corresponding
vs_sz_X.  I guess from a forensic pov what if they say different
things? Presumably the os which mounts it would only look at either
the big endian version or the little endian version. Maybe this can
result in a disk which shows more files if mounted on a big endian
machine vs a little endian machine???  Maybe SK should issue warnings
if the fields contradict.

Michael.

Re: [sleuthkit-developers] autopsy and >tsk-2.50

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

>  Starting at line 287 of configure:
So it would seem Gentoo has gone and provided their own $conf instead
of the one generated; I'll work on remedying that in the updated
package I'm making.

Re: [sleuthkit-developers] autopsy and >tsk-2.50

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

On Jun 6, 2008, at 2:58 PM, RB wrote:

>>  2.10 will look for both md5 and md5sum in the configure script  
>> when it
>> searches for the needed parts.  The outputs are different when you  
>> run them
>> on a file, but autopsy uses them by piping data into them via  
>> STDIN . In
>> that scenario, they seem to operate the same.
>
> The 2.10 I've downloaded (January 29) doesn't do so; do you mean a
> future release?

Starting at line 287 of configure:

found=0
for d in $dirs
   do if (test -x ${d}md5) then
     echo \$MD5_EXE = \'${d}md5\'\; >> $conf;
     echo "md5 found: ${d}md5";
     found=1;
     break;
   elif (test -x ${d}md5sum) then
     echo \$MD5_EXE = \'${d}md5sum\'\; >> $conf;
     echo "md5 found: ${d}md5sum";
     found=1;
     break;
   fi;
done

Re: [sleuthkit-developers] autopsy and >tsk-2.50

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

>  2.10 will look for both md5 and md5sum in the configure script when it
> searches for the needed parts.  The outputs are different when you run them
> on a file, but autopsy uses them by piping data into them via STDIN . In
> that scenario, they seem to operate the same.

The 2.10 I've downloaded (January 29) doesn't do so; do you mean a
future release?

Re: [sleuthkit-developers] autopsy and >tsk-2.50

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

On Jun 5, 2008, at 11:13 AM, RB wrote:

> 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.

2.10 will look for both md5 and md5sum in the configure script when  
it searches for the needed parts.  The outputs are different when you  
run them on a file, but autopsy uses them by piping data into them  
via STDIN . In that scenario, they seem to operate the same.

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

No, but I have been thinking about making the CVS repository public...

thanks,
brian