Bug#863460: hashrat: Seems to produce wrong results on big files

[Bernhard Übelacker]

Hello,
it seems that the value that start to lead to wrong values is 2048M.
Also the returned hash from there is always the same as for an empty file.

I first thought it has something to do with large file support, but it
looks like that is already enabled.

  (gdb) print sizeof(off_t)
  $1 = 8                                                                                                                                                                            

So I think this is caused by using default int for variable val and size.
That way the read buffer size is not determined correctly and then
STREAMReadBytes called with a negative buffer size.

  int result, val, RetVal=FALSE;
  ...
  val=FileSize;
  if ((val==0) || ( val > BUFSIZ)) val=BUFSIZ;
  result=STREAMReadBytes(S,Tempstr,val);

At the end it is not checked if read bytes matches the file size.
Therefore always the hash for an empty file is printed.


Attached patch modifies just as much to get a result matching
the 'sha256sum' utility.


Kind regards,
Bernhard




(gdb) bt
#0  STREAMReadBytes (S=0x55555578d4d0, Buffer=0x555555791560 "", Buffsize=-2147483648) at file.c:852
#1  0x000055555555b894 in HashratHashFile (Ctx=<optimized out>, Hash=0x55555578d360, Type=0, Path=<optimized out>, FileSize=-2147483648) at files.c:202
#2  0x000055555555bb38 in HashratHashSingleFile (Ctx=0x555555789080, HashType=<optimized out>, FileType=0, Path=0x7fffffffe1cb "../../test-2048M", FStat=0x7fffffffdbe0, RetStr=0x7fffffffdb70) at files.c:280
#3  0x000055555555bf0e in HashItem (Ctx=0x555555789080, HashType=0x55555578d200 "sha512", Path=0x7fffffffe1cb "../../test-2048M", FStat=0x7fffffffdbe0, HashStr=0x7fffffffdb70) at files.c:400
#4  0x000055555555bfd2 in HashratAction (Ctx=0x555555789080, Path=0x7fffffffe1cb "../../test-2048M", Stat=0x7fffffffdbe0) at files.c:436
#5  0x000055555555c55d in ProcessItem (Ctx=0x555555789080, Path=0x7fffffffe1cb "../../test-2048M", Stat=0x7fffffffdbe0) at files.c:637
#6  0x000055555555eb1f in ProcessCommandLine (Ctx=0x555555789080, argc=<optimized out>, argv=<optimized out>) at main.c:114
#7  0x0000555555557301 in main (argc=3, argv=0x7fffffffde68) at main.c:149

(gdb) up
#1  0x000055555555b894 in HashratHashFile (Ctx=<optimized out>, Hash=0x55555578d360, Type=0, Path=<optimized out>, FileSize=-2147483648) at files.c:202
202     result=STREAMReadBytes(S,Tempstr,val);

(gdb) print val
$3 = -2147483648
(gdb) print FileSize
$4 = -2147483648
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Avoid-integer-truncation-on-file-size-assignment-if-.patch
Type: text/x-patch
Size: 946 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/forensics-devel/attachments/20170527/1f24cd7b/attachment.bin>