> Would it be possible to show it as part of the stub only if the stub is
> encrypted? That way, it'd show up in the DCE RPC tree the same place it
> always did, if the stub isn't encrypted, rather than appearing to be
> part of the stub protocol.
I don't see why not. Of course, I'm starting to question whether this is "auth padding" or if perhaps this is really "stub padding". Bear with me for a second. In most cases of padding, I believe you pad AFTER a specific field. Since the authentication follows the stub, couldn't one argue that this is really padding to the stub, and not for the authentication? Is there something in a spec somewhere that refers specifically to it as "auth padding", or is this a name we assigned arbitrarily? If it is considered to be padding to the stub, then I do believe it would make sense to decode this after the stub.
Or perhaps I'm just debating symantecs.
> Also, if the stub *is* encrypted, is the *decrypted* stub also padded
> with that many bytes? If so, the relevant decrypted stub bytes should
> also be marked as padding.
Yes, and in encrypted traces, it does just this. In an encrypted trace, selecting the auth padding field highlights the last N bytes of the decrypted NTLMSSP block (which is zeros).
> (If doing so is easier if the stub bytes are marked as such the same way
> they are in your patch, rather than if it's done as per the suggestion in
> the previous paragraph, we might as well continue to do it the way it's done
> in your patch.)
I guess maybe I'm a little confused as to what you are proposing, and how it differs from the patch submitted. I should get a sample trace I can send to the list, and it becomes apparent pretty quickly what the problem is, and how the padding is represented in encrypted traces. I would have done this from the start except my testbed is messed up right now and the only traces I have that demonstrate the problem were off my live network with my real password.
I don't mean to sound argumentative. I tried the changes that got checked into CVS, and they do properly decode my trace. So in general, I'm happy. And, as always, the fixes Guy applied were correct and I'm kicking myself that I didn't think of them myself.
Devin Heitmueller
Senior Software Engineer
Netilla Networks Inc.
