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