ReadAndX Response Signing Failure

[Michael B Allen]

I have an SMB signing verification problem with my client. Maybe someone
can tell me what's happening?

Actually I just fixed a bunch of signing verification errors:

  o didn't decode a field so the byte count passed to the message digest
  was short by 2 bytes
  o was reading directly from the socket into a user supplied buffer so
  the digest was passed a bogus payload
  o had a concurrency error where the sign and verify routines could be
  called at the same time

These were all easily tracked down and repaired but I have one more
verification failure that has some bazarr properties:

It's always a readandx response after a writeandx when reading and writing
to the same host (different transports or multiplexed over the same one
doesn't matter). If the ACKs of a response piggie-back on the next SMB,
verification is ok. Meaning, if there's a quick succession of read,
write, read, write, ... after about 20 there's enough delay that an ACK
get's in there and verification fails. If I add a 100ms delay between
each message, signature verification fails reproducibly after the second
readandx It looks like this:

  <tcon preamble>
  send: readandx
  recv: readandx resp
  ACK
  send: writeandx
  recv: writeandx resp
  ACK
  send: readandx
  recv: readandx resp <- Unverifiable signature

Every time.

Of course I've been through the obvious stuff like double checking the
byte counts passed to the digest. I've designed the test program so
it just reads 32 bytes of 'I' and writes 32 bytes of 'O' so it's not
the payload.  If I ignore that readandx response verification failure
the program completes without error. So the sequence counter or other
long term state isn't getting mixed up.

Is there anything funning about signing with NT4 sp6?

Thanks for any hints or advice,
Mike