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=0x5578d4d0, Buffer=0x55791560 "", 
Buffsize=-2147483648) at file.c:852
#1  0xb894 in HashratHashFile (Ctx=, 
Hash=0x5578d360, Type=0, Path=, FileSize=-2147483648) at 
files.c:202
#2  0xbb38 in HashratHashSingleFile (Ctx=0x55789080, 
HashType=, FileType=0, Path=0x7fffe1cb "../../test-2048M", 
FStat=0x7fffdbe0, RetStr=0x7fffdb70) at files.c:280
#3  0xbf0e in HashItem (Ctx=0x55789080, HashType=0x5578d200 
"sha512", Path=0x7fffe1cb "../../test-2048M", FStat=0x7fffdbe0, 
HashStr=0x7fffdb70) at files.c:400
#4  0xbfd2 in HashratAction (Ctx=0x55789080, 
Path=0x7fffe1cb "../../test-2048M", Stat=0x7fffdbe0) at files.c:436
#5  0xc55d in ProcessItem (Ctx=0x55789080, Path=0x7fffe1cb 
"../../test-2048M", Stat=0x7fffdbe0) at files.c:637
#6  0xeb1f in ProcessCommandLine (Ctx=0x55789080, 
argc=, argv=) at main.c:114
#7  0x7301 in main (argc=3, argv=0x7fffde68) at main.c:149

(gdb) up
#1  0xb894 in HashratHashFile (Ctx=, 
Hash=0x5578d360, Type=0, Path=, FileSize=-2147483648) at 
files.c:202
202 result=STREAMReadBytes(S,Tempstr,val);

(gdb) print val
$3 = -2147483648
(gdb) print FileSize
$4 = -2147483648
From e54af652164b5aec4d836d0fe9c11ba080b284c7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= 
Date: Sat, 27 May 2017 18:25:54 +0200
Subject: Avoid integer truncation on file size assignment if greater than 2G.

https://bugs.debian.org/863460
---
 files.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/files.c b/files.c
index 5c6de63..840e8d2 100644
--- a/files.c
+++ b/files.c
@@ -168,7 +168,8 @@ int HashratHashFile(HashratCtx *Ctx, THash *Hash, int Type, char *Path, off_t Fi
 {
 STREAM *S;
 char *Tempstr=NULL, *User=NULL, *Pass=NULL;
-int result, val, RetVal=FALSE;
+int result, RetVal=FALSE;
+off_t val;
 off_t bytes_read=0;
 
 switch (Type)
@@ -254,7 +255,7 @@ int HashratHashSingleFile(HashratCtx *Ctx, char *HashType, int FileType, char *P
 THash *Hash;
 struct stat XattrStat;
 char *ptr;
-int size=0;
+off_t size=0;
 
 		*RetStr=CopyStr(*RetStr,"");
 
-- 
2.11.0

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

[Andreas Moog]

Package: hashrat
Version: 1.8.3+dfsg-2
Priority: important

Hi there,

there's something wonky going on when using hashtag's sha512 hash for big
files (10 Gig in this case):

$ fallocate -l 10G sha512test
$ sha512sum sha512test 
0a9ed4396868700784918a83a595845d70e582eb0e625c48ace24f4ee94e705247e210339c5f5a55e597f00d2c3217b0c0797e1bfc617161e00de96eaee2d068
  sha512test

$ hashrat -sha512 sha512test 
hash='sha512:cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e'
 type='file' mode='100644' uid='1000' gid='1000' size='10737418240' 
mtime='1495871799' inode='12058626' path='sha512test'

$ echo 1 >> sha512test 
$ sha512sum sha512test 
ae6565b7a9761d6524262738fe252121393aa3fc4987794f5f10175407e212ca81cf04edca949b0316947342e85eca4902dbd445cd53b703c316e5b2979cc976
  sha512test

$ hashrat -sha512 sha512test 
hash='sha512:cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e'
 type='file' mode='100644' uid='1000' gid='1000' size='10737418242' 
mtime='1495871852' inode='12058626' path='sha512test'

It looks like some sort of caching is going on, despite the "-cache" option
is not being used.

For small files it works as expected:

$ fallocate -l 1M sha512-1M-test
$ hashrat sha512-1M-test -sha512
hash='sha512:d6292685b380e338e025b3415a90fe8f9d39a46e7bdba8cb78c50a338cefca741f69e4e46411c32de1afdedfb268e579a51f81ff85e56f55b0ee7c33fe8c25c9'
 type='file' mode='100644' uid='1000' gid='1000' size='1048576' 
mtime='1495872206' inode='12058627' path='sha512-1M-test'

$ echo 1 >> sha512-1M-test 
$ hashrat sha512-1M-test -sha512
hash='sha512:5fc50c214f3928dcdec8f4e3d7c765aadd08cf6de9d65c64f68d4945d4a9e320bae56437a637ded05788b6aedbf074fdc73969c5f513b3938da72ce0efba3728'
 type='file' mode='100644' uid='1000' gid='1000' size='1048578' 
mtime='1495872221' inode='12058627' path='sha512-1M-test'

Let me know if I should provide any more information.

Cheers,
 Andreas

-- 
PGP-encrypted mails preferred
PGP Fingerprint: 74CD D9FE 5BCB FE0D 13EE 8EEA 61F3 4426 74DE 6624


signature.asc
Description: PGP signature