Thread: Re: [sleuthkit-developers] win32 live bugs?
Brought to you by:
carrier
Menu
▾
▴
sleuthkit-developers
|
From: Darren B. <dar...@gm...> - 2008-07-17 14:14:21
|
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.
|
|
From: Brian C. <ca...@sl...> - 2008-07-21 16:37:39
|
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
|
|
From: Darren B. <dar...@gm...> - 2008-07-21 20:20:01
|
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. |
|
From: Brian C. <ca...@sl...> - 2008-07-21 20:37:48
|
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 |
|
From: Michael C. <scu...@gm...> - 2008-07-22 00:47:56
|
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 > |
|
From: Brian C. <ca...@sl...> - 2008-07-22 14:53:27
|
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 >> |
|
From: Michael C. <scu...@gm...> - 2008-07-23 11:02:20
|
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
>>>
>
>
|
|
From: David C. <dav...@gm...> - 2008-07-29 05:00:30
|
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
>
|
|
From: David C. <dav...@gm...> - 2008-07-29 05:02:18
|
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
>>
>
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X