FLASHP2P Protocol RTMFP Parsing

1 Protocol Introduction

Real-time Media Flow Protocol (RTMFP) is a UDP-based point-to-point transfer Protocol between Flash and Flash, released by Adobe in Flash 10.0 in 2008. The groups feature is then added to the Flash10.1. 2 Common uses

The typical use scenario for RTMFP in Flash 10 is as follows:

It has the following characteristics:

L use Cirrus or open source cumulus to provide rendezvous services

L Cirrus or Cumulus does not provide a peer ID Exchange service and needs to provide other ways to exchange peer IDs between clients.

Flash clients use NetStream to make point-to-point transmissions, and publisher needs to transmit a single piece of data to each subscriber, which also limits the size of the cluster.

To solve this problem, Adobe presents the groups concept in Flash 10.1, which is typically structured as follows:

It has the following characteristics:

L Cirrus or Open source Cumulus provides rendezvous services and provides all connected client lists

After the client acquires the neighbor node from the Cirrus or the open source cumulus, it can form a complete peer-to architecture, and all audio, video, and data are interacted between peers. 3 Protocol resolution 3.1 Basic Concepts

L Session:session is a two-way pipeline between two UDP addresses.

L Flow:flow is a logical path from one entity to another. A session can include multiple flow.

L Packet: Data that is actually transferred in the network, a packet can contain multiple message. The data is encrypted with the AES bit

L Message:audio, video and data. 3.2 scrambled Session ID

The format of each package in the RTMFP protocol is as follows:

Packet: = Scrambled-session-id | Encrypted-part

Where Scrambled-session-id is 4 bytes, followed by an AES-encrypted data body.

The following rules are generated for Scramble-session-id:

Scrambled-session-id = a ^ b ^ C

Here ^ represents the XOR operation, A is session-id,b and C is the first 8 bytes of the Encrypted-part.

When the target receives this package, the unscramble operation is as follows:

Session-id = x ^ b ^ C

where x is Scrambled-session-id,b and C ibid.

The purpose of using Scramble-session-id is to reduce the interference of the data packets through the NAT device and LAYER-4 packet inspector to the data.

The Session-id is used to identify the connections established by the communication parties and to determine the encryption and decryption keys that are used in the communication, which are obtained through the DH key exchange algorithm. Before the session was established, however, both parties used a public encryption key, the string "Adobe System 02". 3.3 Raw part

The Encrypted-part is decrypted and then gets the Raw-part, which is in the following format:

Raw-part: = Checksum | Network-layer-data | Padding

Where checksum has 16 bytes, Network-layer-data is variable-length data, padding are 0xFF, and the network-layer-data is padded to a multiple of 16 bytes, because RTMFP uses a 16-byte encryption key.

Checksum is based on network-layer-data and padding calculations. 3.4 Network layer Data

The Network-layer-data format is as follows:

Network-layer-data = Flags | Timestamp | Timestamp-echo | Chunks

Where the flags are 1 bytes, the format is as follows:

7 6 5 4 3 2 1 0

TC TCR reserved reserved TS TSE mode

L MODE:11 represents handshake Packet, 01 for initiator send packet, 10 for responder send packet, 00 not legal value

L TSE: Whether the package contains Timestamp-echo domains

L TS: Whether the package contains timestamp domains

L Tcr:time critical Reverse notification indicates that the sender is receiving the timecritical package from somewhere else

L Tc:time critical Forward notification indicates that the sender sent the timecritical package

The timestamp domain has 2 bytes and the accuracy is 4ms, and he calculates the following:

timestamp = Int (time * 1000/4) & 0xFFFF

The Timestamp-echo domain is the timestamp that the server receives the packet, and the sender can calculate the RTT value when it receives the value.

The format of the chunk type is as follows:

Chunk = Type | Size | Payload

The Type field is 1 bytes, where 0xFF is not available, and this is a token used to differentiate between chunk data and padding data. The type is defined as follows:

type	meaning
0x30	Initiator Hello
0x70	Responder Hello
0x38	Initiator initial keying
0x78	Responder initial keying
0x0f	Forwarded Initiator Hello
0x71	Forwarded Hello response
0x10	Normal User Data
0x11	Next User Data
0x0c	Session failed on client side
0x4c	Session died
0x01	Reset KeepAlive Request
0x41	Reset KeepAlive Response
0x5e	Negative ACK
0x51	Some ACK

The size is a 2-byte payload length.

Payload have different data bodies depending on the type. 3.5 Message Flow

The session includes 3 types of messages:

L Handshake: Handshake package, including initiator Hello, responder Hello, initiator initial keying,responder initial keying, responder Hello Co Okie Change and Responderredirect

L Control: Controls package, including Ping, ping reply, rekeying initiate, rekeying response, Close, Closeacknowledge, forwarded initiator hell O.

Flow: Stream message, including user data, next user data, buffer probe, user data ack, user Dataack, Flow exception report.

The session is established by shaking hands (handshake), and the normal Messageflow is as follows:

In the case of a NAT hole, Cumulus Server, as a forwarder, forwards the Initiatro Hello packet to the other client:

In addition, Cumulus Server can also redirect client to another server:

The client here is Flash Player, and server is Cumulus server or Flash Media server. Of course, the server can also send a initiator hello request to the client, which is called the man in the middle Cumulus, but this feature is not stable.

The session is set up to include 4 handshakes:

1 Initiator-Target:initiator Hello

2 Target-Initiator:responder Hello

3 Initiator, Target:initiator initial keying

4 target-Initiator:responder initial keying

This 4-time handshake process can block DOS and syn-flooding attacks.

Each session has a session-id to uniquely identify the session, and each packet in the session will contain this session-id, but in the 4 handshake package created by the session, Initiator-hello, The Session-id fields for responder Hello and initiator initialkeying are 0, and when the last packet is sent responder initial keying, The session is established successfully and Session-id determined, so responderinitial keying contains the legal session-id.

Let's take a detailed look at these 4 handshake packs 3.5.1 Initiator Hello

The format of the initiator Hello package, as described above, shows only the format of the payload section:

Initiator-hello Payload = First | EPD Type | EPD value| Tag

which

L First:1 byte magic number

L EPD type:1 Byte, only two valid values:

n 0x0a:client-server mode, EPD value is the RTMFP URL of the server you want to connect to

n 0x0f:peer-to-peer mode, EPD value is the peer ID of the client you want to connect to, typically a fixed 32-byte

L EPD Value:varlen + body

L tag:16 bytes Random number 3.5.2 Responder Hello

The payload format of the responder Hello package is as follows:

Responder Hello payload = Tag-echo | Cookies | Responder-certificate

which

L Tag-echo: Consistent with tag in initiator Hello, but unlike initiator Hello, there is a varlen in front to indicate the length of the tag

L bytes Random number of cookie:responder output to prevent syn-flooding attack

L Responder Certificate:diffie-hellman key exchange algorithm exchange information, which is in the following format:

Certificate= \0x01\0x0a\0x41\0x0e | Dh-public-num | \0x02\0x15\0x02\0x02\0x15\0x05\0x02\0x15\0x0e

The Dh-public-num is a random number of byte (byte).

The generation rule for Dh-public-num is

y2 = g ^ x2% p

where G and P are public two numbers, where G equals 2,p is a number of bits, X2 is responder randomly generated number, y2 is the dh-public-num that is transmitted in the network. 3.5.3 Initiator Initial keying

The payload format of the initiator initial keying package is as follows:

Payload = Initiator-session-id | Cookie-echo | initiator-certificate| initiator-component | X

which

L Initiator-session-id:initiator selected Session-id,responder use it to send data to initiator (generate scrambled session ID)

L Cookie-echo: Consistent with the cookie in the previous package

L Initiator-certificate: The format is consistent with the above responder certificate

As in the above, the Dh-public-num rule here is as follows:

y1 = g ^ X1% p

Where the definition of G and P and the same as above, X1 is initiator randomly generated number, y1 is the transmission of dh-public-num. At this time initiator know y2 and x1, you can generate Sharedsecret:

Shared secret = y2 ^ x1% p

At this point, you can generate the corresponding decryption key for this session:

Decode key = hmac-sha256 (Shared-secret, hmac-sha256 (responder Nonce,initiator nonce))

Encode key = hmac-sha256 (Shared-secret, hmac-sha256 (initiator Nonce,responder nonce))

These decryption keys use only the low 128bit

L Initiator-component: Initiator nonce used in the DH algorithm. 3.5.4 Responder Initial keying

The format of the payload of responder initial keying is as follows:

Payload = Responder Session ID | Responder ' s Nonce | X

which

L Responder Session Id:responder generated session Id,initiator use it to generate the scrambled session ID, which is not the same as the initiator session ID.

L Responder ' s nonce:

At this time responder know Y1 and x2, you can generate Sharedsecret:

Shared secret = y2 ^ x1% p

The DH algorithm guarantees that the responder Sharedsecret and initiator shared secret are the same.

At this point, you can generate the corresponding decryption key for this session:

Encode key = hmac-sha256 (Shared-secret, hmac-sha256 (responder Nonce,initiator nonce))

Decode key = hmac-sha256 (Shared-secret, hmac-sha256 (initiator Nonce,responder nonce))

These encryption and decryption keys use only the low 128bit.

You can see that the responder encode key and initiator's decode key are the same, and responder decode key and initiator key are the same.

Note Responder initial keying still uses "Adobe System 02" As the symmetric key to decrypt, instead of using the newly generated asymmetric key to decrypt, the asymmetric key is only used after the session is established. 3.5.5 User Data

This session is established, the subsequent transmission is the data message, mainly consists of two categories:

L Normal User data: normal flow messages

L Next User data: And normal user data are transmitted in a packet and cannot be used alone.

The payload format for the normal user data package is as follows:

Payload = Flags | Flow-id | Seq | Forward-seq-offset | Options |data

which

L flags:1 Byte, the meaning of each bit is as follows:

bit	meaning
0x80	Whether the options field exists
0x40
0x20	There's a bag in front of this bag.
0x10	There's a bag behind this bag.
0x08
0x04
0x02	Discard Package
0x01	End Package

L flow-id:flow identification, Varlen type

L Forward-seq-offset: Identification for sliding window, varlen type

Options: Some

L Data:audio, video and data

The payload format of the next user data package is as follows:

Payload = Flags | Data

field definition Ibid.

Transferred from: http://blog.csdn.net/vinowan/article/details/45934627