is there some thing wrong in KERNEL_FQ void m22400_init (KERN_ATTR_TMPS_ESALT (aescry

[hellohihi]

in KERNEL_FQ void m22400_init (KERN_ATTR_TMPS_ESALT (aescrypt_tmp_t, aescrypt_t)), I believe the following code is wrong.

......


  u32 w[80] = { 0 };

  for (u32 i = 0, j = 0; i < pw_len; i += 4, j += 1)
  {
    w[j] = hc_swap32_S (pws[gid].i[j]);
  }

  // sha256:

  sha256_ctx_t ctx;

  sha256_init  (&ctx);
  sha256_update (&ctx, s, 32);
  sha256_update (&ctx, w, pw_len);
  sha256_final  (&ctx);

  // set tmps:

  #ifdef _unroll
  #pragma unroll
  #endif
  for (int i = 127; i >= 0; i--) // create some space for the first digest without extra buffer
  {
    w[8 + i] = w[i];
  }

  w[0] = ctx.h[0];
  w[1] = ctx.h[1];
  w[2] = ctx.h[2];
  w[3] = ctx.h[3];
  w[4] = ctx.h[4];
  w[5] = ctx.h[5];
  w[6] = ctx.h[6];
  w[7] = ctx.h[7];


.....

The w size is 80, but for w[8 + i] = w[i] the i start from 127, this means i is out of the boundary.

[philsmd]

nice find, it really seems so that this commit https://github.com/hashcat/hashcat/commit/0a60805 did change more than just the way we do the "utf16 encoding". The buffer sizes were changed; and you are right it seems that buffers do overflow with the new code. We should ask atom/jsteube if it's enough to just keep the old/correct buffer size also for the updated utf16 encoding.

The original code seems to not have this problem (i.e. any version of the -m 22400 hash module before the urf16 encoding change).

Please open a new issue on github https://github.com/hashcat/hashcat/issues and mention these details (your observation about the buffer overflow and which commit seem to have broken it). Thx

[atom]

Problem was fixed with commit https://github.com/hashcat/hashcat/commi...fc9054a5a8 thanks for reporting. Indeed nice find!

Keeping the buffer size is fine, the UTF16 conversion is done inside the new gpu_utf8_to_utf16() kernel.