[jcifs] SMB Signing Sequence Counters
Michael B Allen
mba2000 at ioplex.com
Tue Sep 16 15:31:02 EST 2003
>> What would the sequence numbers be for the below 3 SMBs? From looking at
>> your code it looks like it should be something like the following:
>> send: SMB1 sign 0
>> send: SMB2 sign 2
>> send: SMB3 sign 4
>> recv: SMB3 vrfy 5
>> recv: SMB1 vrfy 1
>> recv: SMB2 vrfy 3
>> Is the verify sequence number of the response always 1 more than the
>> sequence number used to sign it's request (as shown above)?
> I *think* so; I'm not sure if there was coverage for that scenario in the
> I did or not (I know it tested multiple requests in a row, i.e. not just
> alternating request-response, but I don't know if it encountered
I think it's right too. Here's some real output from from sign() and
verify() mehtods with ThreadedSmbCrawler and 8 threads (note VRFY: 643
corresponds to SIGN: 642 b/c verifySequence is always 1 more than
>> initialize things as necessary from within this lock as well. That will
>> give us the concurrency we need and considering snd_buf and rcv_buf are
>> static it prevents their contents from changing during signing/verifying
>> (which I think might be a problem with the current code).
> That sounds preferable (assuming it works properly); if you have this
> I can test it here.
It appears to work properly. I removed the lock and I move things around a
little. After I fixup SmbFile.equals() I'll upload something for you to
look at before I release it as 0.7.13.
Good work Eric. It's nice to have an "advanced" feature.
A program should be written to model the concepts of the task it
performs rather than the physical world or a process because this
maximizes the potential for it to be applied to tasks that are
conceptually similar and, more important, to tasks that have not
yet been conceived.
More information about the jcifs