[cifs-protocol] [REG: 110080417580961] [MS-BKRP] 3.1.4.1 "misc" 0x00020000 value

[Edgar Olougouna]

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:metze at samba.org] 
Sent: Thursday, August 19, 2010 1:16 AM
To: Edgar Olougouna
Cc: mat at samba.org; pfif at tridgell.net; cifs-protocol at 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