[cifs-protocol] [REG:110071868986368] unused bytes after while decoding bkrp requests
bburgin at microsoft.com
Sun Jul 18 17:06:43 MDT 2010
[Mark and dochelp to bcc]
[Adding case number & CaseMail]
I began looking at this for you to identify the trailing bytes you specified and to investigate tools to decode/parse the Backup Key request. I'll reply with more information as soon as I have more information to share.
From: Mark Miller (MBD)
Sent: Sunday, July 18, 2010 11:50 AM
To: mat at samba.org; Interoperability Documentation Help; pfif at tridgell.net; cifs-protocol at samba.org
Subject: RE: unused bytes after while decoding bkrp requests
Thank you for your question. A colleague will contact you to investigate this issue.
US-CSS DSC PROTOCOL TEAM
From: Matthieu Patou [mailto:mat at samba.org]
Sent: Sunday, July 18, 2010 2:27 PM
To: Interoperability Documentation Help; pfif at tridgell.net; cifs-protocol at samba.org
Subject: unused bytes after while decoding bkrp requests
Dear dochelp team,
I started to implement the backup key remote protocol for samba.
Right now I'm a bit suspicious I got the data structure ok as when I parse some bytes with ndrdump I have ~52 bytes unused.
From the attached capture called protected_storage.pcap I managed to extract and decrypt the payload (452 bytes + 12 bytes of padding) at packet 485.
The payload is also attached to this email as protected_xtr.
Here are the result of ndrdump
mat at ares:/usr/local/src/samba4/source4$ ./bin/ndrdump protected_storage bkrp_BakuprKey in ~/protected_xtr pull returned NT_STATUS_OK WARNING! 52 unread bytes
 8A E3 13 71 02 F4 36 71 02 40 28 00 30 7C DE 3D ...q..6q .@(.0|.=
 5D 16 D1 11 AB 8F 00 80 5F 14 DB 40 01 00 00 00 ]....... _.. at ....
 04 5D 88 8A EB 1C C9 11 9F E8 08 00 2B 10 48 60 .]...... ....+.H`
 02 00 00 00 ....
bkrp_BakuprKey: struct bkrp_BakuprKey
in: struct bkrp_BakuprKey
guidActionAgent : *
data_in: struct bkrp_client_side_wrapped
version : 0x00000002 (2)
encrypted_secret_len : 0x00000100 (256)
access_check_len : 0x00000058 (88)
encrypted_secret : DATA_BLOB length=256
access_check : DATA_BLOB length=88
data_in_len : 0x00000174 (372)
param : 0x00000000 (0)
To me the result looks sensible I'm just concerned that it seems to have some garbage at the end.
I tried to analyze the frames with netmon 3.4 but it says that it's encrypted (and I didn't find a way to tell him to decrypt ...).
So here is my question: is it normal that I found some trailing bytes ?
do you have the capacity to parse the protected_xtr file and give us the result of the parsing with your tools ?
Samba Team http://samba.org
More information about the cifs-protocol