sleuthkit-users

FW: Re: [sleuthkit-users] RE: Sleuthkit install problem

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

In-Reply-To: <B05...@sl...>
References: <B05...@sl...>


It really is late here - I sent this to Brian without copying it to the list. 
Apologies.

--forwarded message begins--

From: Angus Marshall <an...@n-...>
To: Brian Carrier <ca...@sl...>

On Tuesday 25 May 2004 18:41, Brian Carrier wrote:
> On May 25, 2004, at 11:35 AM, Drew Fahey wrote:
> > The problem is not 64-bit HW.  I have the same problem on my laptop
> > with
> > Fedora Core 2 as well.  The problem is in the Kernel headers and with
> > util-linux.  The kernel headers need to have the syscall5 macro fixed
> > or
> > util-linux needs to be patched to not use llseek.
>
> So are you saying that this is a general problem with all applications
> that use llseek and  Fedora Core 2 and they are working on a solution
> or that TSK needs to be fixed for Fedora Core specific things?

Not sure which is the case - but here's a thought (don't scream) - if 
src/makedefs is modified to change the "-DLINUX2" to read "-DOPENBSD3", 
sleuthkit seems to compile just fine. What the implications of doing this are 
- I really don't know - it's 2 minutes to midnight here and I've just closed 
off two cases for delivery to the investigation team tomorrow, so my brain is 
pretty well fried anyway. 

Brian, if I read the code correctly, this affects fs_tools.h and mm_tools.h 
and selects the OS-provided functions instead of the SK provided functions. 
Since SK seems to compile OK - could it be that Linux 2.6 now supports the 
functions better than 2.2/2.4 used to ? Of course, it looks like it will 
cause some problems with filesystem types, but maybe the workaround is for us 
Linux 2.6ers to patch src/fstools/fs_tools.h to make the LSEEK definition go 
to lseek instead of mylseek ?

Is there a reference test that someone could perform to see if this would work 
?
(I run Linux 2.4 on my desktop workstation and have a choice of 2.4 or 2.6 on 
my laptop so I'm happy to check one against the other if someone can suggest 
a valid test set)

Re: FW: Re: [sleuthkit-users] RE: Sleuthkit install problem

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

On Wednesday 26 May 2004 00:11, Angus Marshall wrote:
> In-Reply-To: <B05...@sl...>
> References: <B05...@sl...>
>
> Brian, if I read the code correctly, this affects fs_tools.h and mm_tools.h
> and selects the OS-provided functions instead of the SK provided functions.
> Since SK seems to compile OK - could it be that Linux 2.6 now supports the
> functions better than 2.2/2.4 used to ? Of course, it looks like it will
> cause some problems with filesystem types, but maybe the workaround is for
> us Linux 2.6ers to patch src/fstools/fs_tools.h to make the LSEEK
> definition go to lseek instead of mylseek ?

OK - just tried tweaking src/fstools/fs_tools.h and changed the LINUX section 
to the following : 

/*
  * Linux 2.whatever. We'll see how stable the interfaces are.
  */
#if defined(LINUX2)
#define SUPPORTED
#include <linux/types.h>
#define HAVE_LLSEEK
#define LSEEK           lseek
#define OFF_T           off_t
#define STRTOUL         strtoul
#define DADDR_T         daddr_t
#define DEF_FSTYPE              "linux-ext2"
#define HAVE_TIMEZONE   1
#endif /* LINUX */

This gives a clean compile (syscall5 is not producing the error btw - it's all 
lseek related as far as I can see), but I don't know if it actually works.

I'm going to go to bed to try to sleep (I will not hack other people's code at 
1:00 a.m. I will not hack other people's code at 1:00 a.m. I will not hack 
other people's code at 1:00 a.m. I will not hack other people's code at 1:00 
a.m. I will not hack other people's code at 1:00 a.m. ;-) 

Looking forward to the flames in the morning.

Re: [sleuthkit-users] RE: Sleuthkit install problem

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

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


On May 25, 2004, at 6:11 PM, Angus Marshall wrote:
> Not sure which is the case - but here's a thought (don't scream) - if
> src/makedefs is modified to change the "-DLINUX2" to read "-DOPENBSD3",
> sleuthkit seems to compile just fine.

What happens when you examine a >2GB disk?  The custom lseek was added 
in TCT because the lseek with Linux did not seek beyond the 2GB limit.  
So, I guess the test is to see if the syscall was fixed and it now 
works for large files or that change has reverted the code back to the 
limited version.

Test it with the following:

# dls -e -f FILESYSTEM /dev/hdaX > /dev/null

on a large partition.

thanks,
brian



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFAs+6DOK1gLsdFTIsRAmtiAJ9AO/4nNDvRD0qFlw1VNBr+p95c3gCfVa76
FOVV9Xg4AMHBkRBFI0ASINg=
=uUaL
-----END PGP SIGNATURE-----

Re: [sleuthkit-users] RE: Sleuthkit install problem

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

On Wednesday 26 May 2004 02:10, you wrote:
> On May 25, 2004, at 6:11 PM, Angus Marshall wrote:
> > Not sure which is the case - but here's a thought (don't scream) - if
> > src/makedefs is modified to change the "-DLINUX2" to read "-DOPENBSD3",
> > sleuthkit seems to compile just fine.
>
> What happens when you examine a >2GB disk?  The custom lseek was added
> in TCT because the lseek with Linux did not seek beyond the 2GB limit.
> So, I guess the test is to see if the syscall was fixed and it now
> works for large files or that change has reverted the code back to the
> limited version.
>
> Test it with the following:
>
> # dls -e -f FILESYSTEM /dev/hdaX > /dev/null
>
> on a large partition.
>
> thanks,
> brian

Thanks Brian - I'll try it this evening when I have created a fresh image for 
testing. Presumably the error message will be obvious if it doesn't work ?

Re: [sleuthkit-users] RE: Sleuthkit install problem

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

On Wednesday 26 May 2004 09:11, Angus Marshall wrote:

Ok - ignore EVERYTHING I have said on this issue up to this point. Having done 
some more work on it -  it looks (to me - and I could be wrong, I frequently 
am) like the problem is being caused by the definition of syscall5 moving 
into a different header file. Adding a

#include <linux/unistd.h> 

to mylseek.c immediately after the #include <syscall.h> line
seems to work for me (testing on SK1.67 currently).

I get a successful compilation after doing this and a good dls on a 8Gb 
partition - no errors visible at all.

This still uses the custom lseek, which I prefer since it has been accepted in 
court, unlike the Linux 2.6 kernel.

Re: [sleuthkit-users] RE: Sleuthkit install problem

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

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


On May 26, 2004, at 3:16 PM, Angus Marshall wrote:
> Ok - ignore EVERYTHING I have said on this issue up to this point. 
> Having done
> some more work on it -  it looks (to me - and I could be wrong, I 
> frequently
> am) like the problem is being caused by the definition of syscall5 
> moving
> into a different header file. Adding a
>
> #include <linux/unistd.h>
>
> to mylseek.c immediately after the #include <syscall.h> line
> seems to work for me (testing on SK1.67 currently).

So, to confirm.  You are using the original makedefs and fs_tools.h 
file.  All you did was add linux/unistd.h to mylseek.c?

brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFAtXm4OK1gLsdFTIsRAldYAJ9C11lWaM6BDf6cYXhae0ZTDoULSQCfbaFp
hKEMe/BRtGfS44dM94umez0=
=7gum
-----END PGP SIGNATURE-----

Re: [sleuthkit-users] RE: Sleuthkit install problem

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

On Thursday 27 May 2004 06:16, Brian Carrier wrote:
> So, to confirm.  You are using the original makedefs and fs_tools.h
> file.  All you did was add linux/unistd.h to mylseek.c?
>
> brian

That is correct.