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

[Stefan (metze) Metzmacher]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20100819/048eb3d3/attachment.pgp>