none
[MS-PPGRH] - Unknown preamble

    Question

  • Hi,

    below is a dump of the tcp payload of PPGRH as used by [MS-HGRP], starting with the very first Packet, having a new peer connect to the group.

    00000000  00 93 00 00 00 93 10 01  00 00 01 00 00 10 00 55  |...............U|
    00000010  00 93 64 36 64 33 38 30  65 64 35 35 37 61 34 37  |..d6d380ed557a47|
    00000020  38 38 61 35 63 39 36 38  39 39 37 39 63 38 31 33  |88a5c9689979c813|
    00000030  30 35 38 35 33 65 63 37  38 35 2e 48 6f 6d 65 47  |05853ec785.HomeG|
    00000040  72 6f 75 70 50 65 65 72  47 72 6f 75 70 43 6c 61  |roupPeerGroupCla|
    00000050  73 73 69 66 69 65 72 62  37 33 36 63 65 65 33 61  |ssifierb736cee3a|
    00000060  65 35 34 39 62 36 62 61  65 62 65 61 34 63 31 61  |e549b6baebea4c1a|
    00000070  33 37 37 37 34 30 62 39  36 64 33 35 39 66 36 2e  |377740b96d359f6.|
    00000080  48 6f 6d 65 47 72 6f 75  70 43 6c 61 73 73 69 66  |HomeGroupClassif|
    00000090  69 65 72 5f 31 00 63 00  00 00 63 16 03 01 00 5a  |ier_1.c...c....Z|
    000000a0  01 00 00 56 03 01 50 d2  3f c8 92 1e 67 f4 e4 23  |...V..P.?...g..#|
    000000b0  e7 b3 3a 36 e9 4c 56 0f  2c a5 db 2e 85 f5 c9 2a  |..:6.LV.,......*|
    000000c0  f2 89 a8 79 d1 67 00 00  18 00 2f 00 35 00 05 00  |...y.g..../.5...|
    000000d0  0a c0 13 c0 14 c0 09 c0  0a 00 32 00 38 00 13 00  |..........2.8...|
    000000e0  04 01 00 00 15 ff 01 00  01 00 00 0a 00 06 00 04  |................|
    000000f0  00 17 00 18 00 0b 00 02  01 00 04 79 00 00 04 79  |...........y...y|
    00000100  16 03 01 04 35 0b 00 03  25 00 03 22 00 03 1f 30  |....5...%.."...0|
    00000110  82 03 1b 30 82 02 84 a0  03 02 01 02 02 10 41 da  |...0..........A.|
    00000120  7e 84 0a 42 7a a6 47 53  71 24 5e 4f 54 7c 30 0d  |~..Bz.GSq$^OT|0.|
    00000130  06 09 2a 86 48 86 f7 0d  01 01 05 05 00 30 35 31  |..*.H........051|

    I just wanted to parse it.

    The first 2 bytes of every message seem to be prefixed with the Length - as big endian uint16_t

    Ignoring these 2 bytes for now, gives us:

     Message
      MessageSize 147
      Version 0x10
      MessageType 1
       AUTH_INFO
        GraphID d6d380ed557a4788a5c9689979c81305853ec785.HomeGroupPeerGroupClassifierb736cee3ae549b6baebea4c1a377740b96d359f6.HomeGroupClassifier_1 (off 16)
        SourcePeerID b736cee3ae549b6baebea4c1a377740b96d359f6.HomeGroupClassifier_1 (off 85)
        DestinationPeerID (null) (off 147)

    for the first message.

    Netmon does not give anything, for one the PPGRH decoder which is provided after signing up with Microsoft connect is not tied into the tcp.npl script, so it is not loaded.

    As it is not possible to modify "Internal" parsers in place ... and copying a decoder results in compile problems I was unable to have tcp decode PPGRH directly, but was able to modify the ppgrh.npl, adding a new protocol which uses a  2 byte frame size, instead of 4 byte as defined in the spec.

    So - I'd say ... maybe the first packet is right, we just need to figure out if the frame size is 2 bytes instead of 4.

    Second Packet, again ignore the unknown 2 bytes prefix.

    Message
      MessageSize 99
      Version 0x16
      MessageType 3

    Version is 0x16 - has to be 0x10 per the spec.

    I do not parse MessageType 3 now, but NetMon does - even having the same Version 0x16 instead of 0x10. As I'm not able to copy the parsing data from netmon and can't post screenshots here, you'll have to trust me the data in the WELCOME message does not make any sense.

    I'd be glad if somebody could re-check the specification, I got doubts it matches the implementation, and the NetMon script may need some tweaks too.

    Thanks for your assistance.

    Thursday, December 20, 2012 4:49 AM

Answers

  • Summary of resolution:

    We confirm that the Frame size is a WORD instead of DWORD as currently documented in [MS-PPGRH] 2.2.1.1 Message Framing.
    A future release of the document will reflect the update.

    We also communicated this information in a Netmon parser bug:
    The FrameSize is a WORD in front of the unencrypted TLSRecords of the handshake.
    The [MS-PPGRH] AUTH_INFO message is not encrypted, and message framing should  be parsed properly using the WORD as Frame Size.

    Regarding the frame size when the message is larger than the TLS Record, your approach appears to be correct.
    Windows TLS implementation also ignores trailing data and reads the correct length out of the TLS Record header.
    We will clarify that further as necessary in the document.

    Monday, February 11, 2013 8:45 PM
    Moderator

All replies

  • Hi Msosilover:

    I have alerted the Open Specifications Team regarding your inquiry. A member of the team will be in touch soon.

    Regards


    Tarun Chopra | Escalation Engineer | Open Specifications Support Team

    Thursday, December 20, 2012 2:27 PM
  • Hi,

    I will assist you in investigating this and reviewing the technical document as well.

    Please send the network trace to my attention at this address: dochelp at microsoft dot com

    Also mention this thread, and the version of the parser you have been using.

    The following blog entry provides information on how to customize Netmon parsers and make your own changes.

    Customizing In-Box Netmon Parsers. How to edit and deploy updated Netmon Parsers.

    http://blogs.msdn.com/b/openspecification/archive/2011/08/08/customizing-in-box-netmon-parsers-how-to-edit-and-deploy-updated-netmon-parsers.aspx 

    Thanks,

    Edgar

    Thursday, December 20, 2012 4:43 PM
    Moderator
  • I already figured the values besides the 2 & 4 byte length are garbage as they are part of the TLS handshake initiated as part of PPSEC.

    Which brings me to an additional question - where to find information on the TLS handshake of PPSEC in HGRP.

    While seems like the complete TLS handshake is (double) length prefixed, I was unable to find and documents on this - I'd expect this to be part of PPSEC.

    Thanks for your assistance.

    Friday, December 21, 2012 7:28 AM
  • 00000000  00 93 00 00 00 93 10 01  00 00 01 00 00 10 00 55  |...............U|

    To my current understanding

    00 93 is the WORD Frame Size

    00 00 00 93 is the DWORD Message Size

    During the TLS handshake for PPSEC TLS data is Frame Size and Message Size prefixed. The PPGRH documentation needs an adjustment, as it documents the Frame Size as DWORD. Some words on message encapsulation during TLS handshake would make things easier too.

    Friday, January 11, 2013 10:05 AM
  • As it is related to TLS framing - and this is still an open issue - I have to extend this ticket.

    When in state > Initial, so after a successful TLS handshake, we start to get packets via TLS from the remote.

    Messages are framed as follows

    | WORD FrameSize | DWORD MessageSize | TLS Data |

    Problem is - the Message is larger than the TLS Record - so there are additional bytes after the TLS record.

    For state "Hello Sent" when getting the mygmc message when connecting with password, this garbage? suffix is 2 bytes, in state Password Sent it is 10 bytes.

    The garbage is always 0x00, size varies as mentioned.

    Feeding these additional bytes to the TLS state machine - breaks the state machine, as they are not TLS Records.

    My current workaround is to parse the TLS Record header and grab the correct size from the header and feed my TLS state machine with the correct data, and discard the remaining bytes, but - I'd love to have documentation on this.

    As an example - no idea in which state this message was sent - I grabbed it from a win7-win7 homegroup conversation:

    0000   00 47 00 00 00 47 17 03 01 00 30 6d c3 30 73 6c  .G...G....0m.0sl
    0010   74 34 62 76 d7 ab a2 35 b7 ca ba 29 9a a6 d2 bf  t4bv...5...)....
    0020   df 19 80 4e 1a de 96 b4 e2 16 3f b5 24 1c a8 de  ...N......?.$...
    0030   39 90 6d f9 7b 18 15 e1 75 d9 0c 00 00 00 00 00  9.m.{...u.......
    0040   00 00 00 00 00 00 00 00 00                       .........

    FrameSize == MessageSize = 0x47 == 71

    Actual Message Size is 71 - 4 = 67 (4 is sizeof header)

    TLSRecordSize = 0x30 == 48

    Size of the TLS Record = 48 + 5 = 55 (5 is sizeof header)

    Garbage = 67 - 55 = 12 bytes

    Exactly the 12 bytes zero suffix.

    Thursday, January 17, 2013 5:29 AM
  • Hi,

    Thank you for this new observation. Since I have been working with you on the previous question, I will continue working with you offline on this question and post a summary once we have resolved the issue.

    Regards,

    Edgar

    Thursday, January 17, 2013 5:36 PM
    Moderator
  • Summary of resolution:

    We confirm that the Frame size is a WORD instead of DWORD as currently documented in [MS-PPGRH] 2.2.1.1 Message Framing.
    A future release of the document will reflect the update.

    We also communicated this information in a Netmon parser bug:
    The FrameSize is a WORD in front of the unencrypted TLSRecords of the handshake.
    The [MS-PPGRH] AUTH_INFO message is not encrypted, and message framing should  be parsed properly using the WORD as Frame Size.

    Regarding the frame size when the message is larger than the TLS Record, your approach appears to be correct.
    Windows TLS implementation also ignores trailing data and reads the correct length out of the TLS Record header.
    We will clarify that further as necessary in the document.

    Monday, February 11, 2013 8:45 PM
    Moderator