Starbound SHA256 Bug

UPDATE: This has been fixed now.

There’s a bug with the SHA256 code in Starbound which produces bad hashes in certain circumstances.

The bug comes from the first if statment in sha256_final (or whatever they’ve called it in their code).

Theirs looks like OpenSSL’s, except the if statement on line 375 of md32_common.h in OpenSSL (https://github.com/openssl/openssl/blob/master/crypto/md32_common.h#L375) evaluates to if (n > 56), whereas theirs evaluates to the equivalent of if (n > 55), producing erroneous hashes for data of length 55.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
int HASH_FINAL (unsigned char *md, HASH_CTX *c)
{
  unsigned char *p = (unsigned char *)c->data;
  size_t n = c->num;

  p[n] = 0x80;
  n++;
    
  if (n > (HASH_CBLOCK-8)) /* <================ Here! */
  {
    memset (p+n,0,HASH_CBLOCK-n);
    n=0;
    HASH_BLOCK_DATA_ORDER (c,p,1);
  }
  memset (p+n,0,HASH_CBLOCK-8-n);
  
  // ...

HASH_BLOCK is defined as 64 (see https://github.com/openssl/openssl/blob/master/crypto/sha/sha256.c#L77 and https://github.com/openssl/openssl/blob/master/crypto/sha/sha.h#L94)

This causes issues for people making asset database readers, and people making server wrappers.

Examples

1
2
3
4
5
6
7
8
9
10
11
data      = /objects/generic/aviandungeonpod/aviandungeonpod.object
expected  = 5ec605bc23efe4cf33c908acf39765ea747184c45685ba0882faaaabf65faedb
starbound = d382a309d24d1744019a0e411b261650a4759888d941bf96ac77d2b93809812f

data      = /animations/muzzleflash/bulletmuzzle2/bulletmuzzle2.png
expected  = ee26c2aae2611f452fa14599b2dc603f97d9d3fa90d904c310daad2940776290
starbound = 01296632e13403df27a08222159c4336365c52b60cbd55c9be2b3581799dd8e6

data      = /animations/muzzleflash/bulletmuzzle3/bulletmuzzle3.png
expected  = 884907c6f49d362f9baf2055e070b559a5c1342ef25130ab7d8eb297d08f87e7
starbound = 5f3e5a249d9788ca534e02b314578ff1ba9a2b8caadc0b166a65f350958badb4