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" 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: > > 00000000 00 00 02 00 44 00 00 00 00 00 00 00 8d 65 cd e4 > |....D........e..| > 00000010 6c 93 62 22 48 e7 04 ff 0c 8f 0e 83 7a e4 dd d4 > |l.b"H.......z...| > 00000020 4b d1 8e 74 95 67 4f 85 be a5 9c b7 7f fd 39 2c > |K..t.gO.......9,| > 00000030 54 bc a7 60 e4 e0 13 26 49 6f ca 35 ee bb 23 24 > |T..`...&Io.5..#$| > 00000040 51 d4 4e c9 37 1d f0 9e 83 69 bd 10 44 00 00 00 > |Q.N.7....i..D...| > 00000050 00 00 00 00 |....| > 00000054 > > 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 : 0x00020000 (131072) > secret : DATA_BLOB length=68 > data_out_len : 0x00000044 (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