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

Jax cybercorecentre at gmail.com
Fri Aug 6 02:36:37 MDT 2010


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 <edgaro at 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:
>
> 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.
>
>
> -----Original Message-----
> From: Bryan Burgin
> Sent: Wednesday, August 04, 2010 10:12 PM
> To: 'mat at samba.org'
> Cc: pfif at tridgell.net; cifs-protocol at 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" 0x00020000 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 at cifs.org
> https://lists.samba.org/mailman/listinfo/cifs-protocol
>


More information about the cifs-protocol mailing list