Re: [cifs-protocol] [REG: 110080417580961] [MS-BKRP] 3.1.4.1 misc 0x00020000 value
Hi Matthieu, Issue verbatim -- So page 31 of MS-BKRP.pdf state that the message format for exchange is : NET_API_STATUS BackuprKey( [in] handle_t h, [in] GUID* pguidActionAgent, [in, size_is(cbDataIn)] byte* pDataIn, [in] DWORD cbDataIn, [out, size_is(,*pcbDataOut)] byte** ppDataOut, [out] DWORD* pcbDataOut, [in] DWORD dwParam ); I already asked if there is not some bytes after the dwParam. After analyzing the out message I have the impression that before the ppDataOut there is some kind of integer. Here is the hex dump of an output message: 00 00 02 00 44 00 00 00 00 00 00 00 8d 65 cd e4 |De..| 0010 6c 93 62 22 48 e7 04 ff 0c 8f 0e 83 7a e4 dd d4 |l.bH...z...| 0020 4b d1 8e 74 95 67 4f 85 be a5 9c b7 7f fd 39 2c |K..t.gO...9,| 0030 54 bc a7 60 e4 e0 13 26 49 6f ca 35 ee bb 23 24 |T..`...Io.5..#$| 0040 51 d4 4e c9 37 1d f0 9e 83 69 bd 10 44 00 00 00 |Q.N.7i..D...| 0050 00 00 00 00 || 0054 so from byte 4 (0x44 ) we have clearly (at least to me) the ppDataOut variable that is NDR encoded (meaning that the size is specified before on the wire) up to byte 4B then we have the size (pcbDataOut) (0x44 0x00 0x00 0x00) and then the return code. I attach the out message extracted from the trace I sent last time. With the following samba idl: [public,nopush,nopull,noprint] WERROR bkrp_BackupKey ( [in,ref] GUID *guidActionAgent, [in,ref] [subcontext(4)] uint8 *data_in, [in] uint32 data_in_len, [in] uint32 param, [out] uint32 misc, [out] DATA_BLOB secret, [out] uint32 data_out_len ); We have the following result while using our ndrdump tool: pull returned NT_STATUS_OK bkrp_BackupKey: struct bkrp_BackupKey out: struct bkrp_BackupKey misc : 0x0002 (131072) secret : DATA_BLOB length=68 data_out_len : 0x0044 (68) result : WERR_OK dump OK As I have also managed to get a correct BACKUPKEY_RETRIEVE_BACKUP_KEY_GUID exchange I also witnessed that on the out message there is also something (that I named misc in our idl) (see the get_key_out file which is the extraction of out message on a BACKUPKEY_RETRIEVE_BACKUP_KEY_GUID request). As the certificate that I extracted seems to be correct I pretty encline to think I am right as first we are able to parse the NDR encoded data, and that the result seems sensible. Can you see if my analysis is correct and if so can you give us the explanation of this misc parameter. If not, well please tell me the correct way to parse the message. The misc parameter is the unique pointer. [out, size_is(,*pcbDataOut)] byte** ppDataOut means a the first pointer is [ref] and the 2nd pointer is (pointer_default() of the interface, unique in this case) And the unique pointer points to an array of bytes with size *pcbDataOut. metze signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG: 110080417580961] [MS-BKRP] 3.1.4.1 misc 0x00020000 value
Thanks for confirming that there is no misc parameter. I debugged this at the server side and noticed it was down to NDR marshaling. Best regards, Edgar -Original Message- From: Stefan (metze) Metzmacher [mailto:me...@samba.org] Sent: Thursday, August 19, 2010 1:16 AM To: Edgar Olougouna Cc: m...@samba.org; p...@tridgell.net; cifs-proto...@samba.org; MSSolve Case Email Subject: Re: [cifs-protocol] [REG: 110080417580961] [MS-BKRP] 3.1.4.1 misc 0x0002 value Hi Matthieu, Issue verbatim -- So page 31 of MS-BKRP.pdf state that the message format for exchange is : NET_API_STATUS BackuprKey( [in] handle_t h, [in] GUID* pguidActionAgent, [in, size_is(cbDataIn)] byte* pDataIn, [in] DWORD cbDataIn, [out, size_is(,*pcbDataOut)] byte** ppDataOut, [out] DWORD* pcbDataOut, [in] DWORD dwParam ); I already asked if there is not some bytes after the dwParam. After analyzing the out message I have the impression that before the ppDataOut there is some kind of integer. Here is the hex dump of an output message: 00 00 02 00 44 00 00 00 00 00 00 00 8d 65 cd e4 |De..| 0010 6c 93 62 22 48 e7 04 ff 0c 8f 0e 83 7a e4 dd d4 |l.bH...z...| 0020 4b d1 8e 74 95 67 4f 85 be a5 9c b7 7f fd 39 2c |K..t.gO...9,| 0030 54 bc a7 60 e4 e0 13 26 49 6f ca 35 ee bb 23 24 |T..`...Io.5..#$| 0040 51 d4 4e c9 37 1d f0 9e 83 69 bd 10 44 00 00 00 |Q.N.7i..D...| 0050 00 00 00 00 || 0054 so from byte 4 (0x44 ) we have clearly (at least to me) the ppDataOut variable that is NDR encoded (meaning that the size is specified before on the wire) up to byte 4B then we have the size (pcbDataOut) (0x44 0x00 0x00 0x00) and then the return code. I attach the out message extracted from the trace I sent last time. With the following samba idl: [public,nopush,nopull,noprint] WERROR bkrp_BackupKey ( [in,ref] GUID *guidActionAgent, [in,ref] [subcontext(4)] uint8 *data_in, [in] uint32 data_in_len, [in] uint32 param, [out] uint32 misc, [out] DATA_BLOB secret, [out] uint32 data_out_len ); We have the following result while using our ndrdump tool: pull returned NT_STATUS_OK bkrp_BackupKey: struct bkrp_BackupKey out: struct bkrp_BackupKey misc : 0x0002 (131072) secret : DATA_BLOB length=68 data_out_len : 0x0044 (68) result : WERR_OK dump OK As I have also managed to get a correct BACKUPKEY_RETRIEVE_BACKUP_KEY_GUID exchange I also witnessed that on the out message there is also something (that I named misc in our idl) (see the get_key_out file which is the extraction of out message on a BACKUPKEY_RETRIEVE_BACKUP_KEY_GUID request). As the certificate that I extracted seems to be correct I pretty encline to think I am right as first we are able to parse the NDR encoded data, and that the result seems sensible. Can you see if my analysis is correct and if so can you give us the explanation of this misc parameter. If not, well please tell me the correct way to parse the message. The misc parameter is the unique pointer. [out, size_is(,*pcbDataOut)] byte** ppDataOut means a the first pointer is [ref] and the 2nd pointer is (pointer_default() of the interface, unique in this case) And the unique pointer points to an array of bytes with size *pcbDataOut. metze ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG: 110080417580961] [MS-BKRP] 3.1.4.1 misc 0x00020000 value
Matthieu, I have completed my investigation on your request regarding the output of BackuprKey(Opnum 0) specified in MS-BKRP 3.1.4.1. The test against a BackupKey server running Windows Server 2008 R2 confirmed that the output parameters (ppDataOut , pcbDataOut) are correct. By exercising the BACKUPKEY_RETRIEVE_BACKUP_KEY_GUID of the client subprotocol, I verified the server’s public key (in the format specified in section 2.2.1) when the remote procedure returned its data to the server stub. On my testing client, the public key (i.e. certificate field of exported RSA key pair structure) returned by the server through the BackuprKey method is same as public key obtained by calling the LSARetrievePrivateData method. I also confirmed that there is no “misc” parameter in front of the ppDataOut. The RPC response format the client receives is due to NDR marshaling; in my test environment it is a NDR20 engine. Although I presume you are using a library for NDR marshaling/unmarshaling, it might be useful to revisit rules for conformant arrays and pointers. [out, size_is(,*pcbDataOut)] byte** ppDataOut, [out] DWORD* pcbDataOut, Note that the RPC runtime library and the NDR20 engine used in the testing (of the BackupKey protocol) are the same components used by other RPC interfaces on the Windows server. References: [C706] The Open Group, DCE 1.1: Remote Procedure Call, C706, August 1997, http://www.opengroup.org/public/pubs/catalog/c706.htm Section 14.3 NDR Constructed Types [MS-RPCE] Microsoft Corporation, Remote Procedure Call Protocol Extensions http://msdn.microsoft.com/en-us/library/cc243560.aspx Section 2.2.5 64-Bit Network Data Representation Best regards, Edgar -Original Message- From: Edgar Olougouna Sent: Thursday, August 05, 2010 4:42 PM To: 'm...@samba.org'; 'p...@tridgell.net'; 'cifs-proto...@samba.org' Cc: MSSolve Case Email Subject: [REG: 110080417580961] [MS-BKRP] 3.1.4.1 misc 0x0002 value Hi Matthieu, I will working with you to clarify this misc value you experienced regarding the BackupKey protocol. Best regards, Edgar Issue verbatim -- So page 31 of MS-BKRP.pdf state that the message format for exchange is : NET_API_STATUS BackuprKey( [in] handle_t h, [in] GUID* pguidActionAgent, [in, size_is(cbDataIn)] byte* pDataIn, [in] DWORD cbDataIn, [out, size_is(,*pcbDataOut)] byte** ppDataOut, [out] DWORD* pcbDataOut, [in] DWORD dwParam ); I already asked if there is not some bytes after the dwParam. After analyzing the out message I have the impression that before the ppDataOut there is some kind of integer. Here is the hex dump of an output message: 00 00 02 00 44 00 00 00 00 00 00 00 8d 65 cd e4 |De..| 0010 6c 93 62 22 48 e7 04 ff 0c 8f 0e 83 7a e4 dd d4 |l.bH...z...| 0020 4b d1 8e 74 95 67 4f 85 be a5 9c b7 7f fd 39 2c |K..t.gO...9,| 0030 54 bc a7 60 e4 e0 13 26 49 6f ca 35 ee bb 23 24 |T..`...Io.5..#$| 0040 51 d4 4e c9 37 1d f0 9e 83 69 bd 10 44 00 00 00 |Q.N.7i..D...| 0050 00 00 00 00 || 0054 so from byte 4 (0x44 ) we have clearly (at least to me) the ppDataOut variable that is NDR encoded (meaning that the size is specified before on the wire) up to byte 4B then we have the size (pcbDataOut) (0x44 0x00 0x00 0x00) and then the return code. I attach the out message extracted from the trace I sent last time. With the following samba idl: [public,nopush,nopull,noprint] WERROR bkrp_BackupKey ( [in,ref] GUID *guidActionAgent, [in,ref] [subcontext(4)] uint8 *data_in, [in] uint32 data_in_len, [in] uint32 param, [out] uint32 misc, [out] DATA_BLOB secret, [out] uint32 data_out_len ); We have the following result while using our ndrdump tool: pull returned NT_STATUS_OK bkrp_BackupKey: struct bkrp_BackupKey out: struct bkrp_BackupKey misc : 0x0002 (131072) secret : DATA_BLOB length=68 data_out_len : 0x0044 (68) result : WERR_OK dump OK As I have also managed to get a correct BACKUPKEY_RETRIEVE_BACKUP_KEY_GUID exchange I also witnessed that on the out message there is also something (that I named misc in our idl) (see the get_key_out file which is the extraction of out message on a BACKUPKEY_RETRIEVE_BACKUP_KEY_GUID request). As the certificate that I extracted seems to be correct I pretty encline to think I am right as first we are able to parse the NDR encoded data, and that the result seems sensible. Can you see if my analysis is correct and if so can you give us the explanation of this misc parameter. If not, well please tell me the correct way to parse the message. -Original Message- From: Bryan Burgin Sent:
Re: [cifs-protocol] [REG: 110080417580961] [MS-BKRP] 3.1.4.1 misc 0x00020000 value
the value is 0x94217444 you have to input this to the mainframe Senior manager, Samba.org On Thu, Aug 5, 2010 at 11:42 PM, Edgar Olougouna edg...@microsoft.com wrote: Hi Matthieu, I will working with you to clarify this misc value you experienced regarding the BackupKey protocol. Best regards, Edgar Issue verbatim -- So page 31 of MS-BKRP.pdf state that the message format for exchange is : NET_API_STATUS BackuprKey( [in] handle_t h, [in] GUID* pguidActionAgent, [in, size_is(cbDataIn)] byte* pDataIn, [in] DWORD cbDataIn, [out, size_is(,*pcbDataOut)] byte** ppDataOut, [out] DWORD* pcbDataOut, [in] DWORD dwParam ); I already asked if there is not some bytes after the dwParam. After analyzing the out message I have the impression that before the ppDataOut there is some kind of integer. Here is the hex dump of an output message: 00 00 02 00 44 00 00 00 00 00 00 00 8d 65 cd e4 |De..| 0010 6c 93 62 22 48 e7 04 ff 0c 8f 0e 83 7a e4 dd d4 |l.bH...z...| 0020 4b d1 8e 74 95 67 4f 85 be a5 9c b7 7f fd 39 2c |K..t.gO...9,| 0030 54 bc a7 60 e4 e0 13 26 49 6f ca 35 ee bb 23 24 |T..`...Io.5..#$| 0040 51 d4 4e c9 37 1d f0 9e 83 69 bd 10 44 00 00 00 |Q.N.7i..D...| 0050 00 00 00 00 || 0054 so from byte 4 (0x44 ) we have clearly (at least to me) the ppDataOut variable that is NDR encoded (meaning that the size is specified before on the wire) up to byte 4B then we have the size (pcbDataOut) (0x44 0x00 0x00 0x00) and then the return code. I attach the out message extracted from the trace I sent last time. With the following samba idl: [public,nopush,nopull,noprint] WERROR bkrp_BackupKey ( [in,ref] GUID *guidActionAgent, [in,ref] [subcontext(4)] uint8 *data_in, [in] uint32 data_in_len, [in] uint32 param, [out] uint32 misc, [out] DATA_BLOB secret, [out] uint32 data_out_len ); We have the following result while using our ndrdump tool: pull returned NT_STATUS_OK bkrp_BackupKey: struct bkrp_BackupKey out: struct bkrp_BackupKey misc : 0x0002 (131072) secret : DATA_BLOB length=68 data_out_len : 0x0044 (68) result : WERR_OK dump OK As I have also managed to get a correct BACKUPKEY_RETRIEVE_BACKUP_KEY_GUID exchange I also witnessed that on the out message there is also something (that I named misc in our idl) (see the get_key_out file which is the extraction of out message on a BACKUPKEY_RETRIEVE_BACKUP_KEY_GUID request). As the certificate that I extracted seems to be correct I pretty encline to think I am right as first we are able to parse the NDR encoded data, and that the result seems sensible. Can you see if my analysis is correct and if so can you give us the explanation of this misc parameter. If not, well please tell me the correct way to parse the message. -Original Message- From: Bryan Burgin Sent: Wednesday, August 04, 2010 10:12 PM To: 'm...@samba.org' Cc: p...@tridgell.net; cifs-proto...@samba.org; MSSolve Case Email Subject: RE: [REG:110071868986368] unused bytes after while decoding bkrp requests Matthieu, For your new issues, I created three new cases and dispatched them across the team 110080417580961 [MS-BKRP] 3.1.4.1 misc 0x0002 value 110080418016869 [MS-BKRP] 3.1.4.1.3 -- version field and a GUID field no documented 110080418357322 [MS-BKRP] 1.3.1 -- in a given domain there is only active rsa key ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
