On Sun, Jul 20, 2003 at 02:18:39PM -0400, Devin Heitmueller wrote:
> Attached is a patch containing a change to move the display of the
> DCE/RPC auth padding field into the stub dissection.
Checked in (with fixes to the problems mentioned below).
> This is because when NTLMSSP decryption is used, the auth padding is
> part of the encrypted stub. If the auth padding is not included in the
> decryption, subsequent frames will not decrypt properly.
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.
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. (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.)
> Please let me know if any problems are found with this patch.
1) The code that puts "Auth Padding (N byte(s))" into the protocol tree
first needs to check whether "auth_info" is null before using it, and
also needs to check whether there *is* any padding.
2) In "dissect_dcerpc_cn_auth()", if we don't have the full packet, or
we don't have an auth len, or it's not valid, we need to set
"auth_info->auth_pad_len" to 0.
