RE: [sleuthkit-users] OS X Errors

[McMillon, M. <Mat...@qw...>]

The strings wrapper is installed, but I'll verify that autopsy is using =
it and not the other (not sure why it would, but you never know.)  =
Although with previous version of autopsy the queries wouldn't run at =
all--the negative byte offset error was not fatal in this case, i.e. =
some results were still returned.

My buddy ran an "extra super-duper" wiping program on the drive.  I =
believe the program changes the file names to something from /dev/random =
(or similar) before deleting them, which may explain the existence of =
the no-printable character in the fls data.  It also does funky things =
with the drive head placement while writing data, which could cause some =
additional weirdness.

> Errors:
>
> Error parsing string: -/- * 0:  =A9=A3'@`=DF  =A9=A3$@'2@?<@(=EDM
> Error parsing string: ^=E7=FF=BF=D5 @p%@`!      0000.00.00 00:00:00 =
(GMT)     =20
>  0000.00.00 00:00:00 (GMT)       0000.00.00 00:00:00 (GMT)       0     =

>   0       0

Wow!  What is happening is that the 'fls' tool is looking in the=20
directory for deleted file name entries.  The above data met its=20
requirements for a valid deleted structure.  There are currently no=20
name checks because it is possible to make file names with=20
non-printable ASCII.  Autopsy though, will only accept printable ASCII.=20
  Therefore, I must either update Autopsy so that it reads unprintable=20
ASCII (although you would never see it in the browser ..) or add some=20
constraints into 'fls'.  Either way, you can ignore the message.  It=20
processed the rest of the entries after it found the error.

> ERROR: Negative byte offset (-89) Your version of strings likely does
> not support large files

Did you install the strings script for OS X?  The strings that comes=20
with OS X doesn't support the same flags as binutils and this script=20
converts the syntax (if you put it in /usr/local/bin).

	http://prdownloads.sourceforge.net/autopsy/strings?download

brian