A problem encountered during the rtmp handshake

A similar article above found the time: Problems in rtmp handshake

In FFMPEG, rtmp is implemented. In handshake, C1 is, the time field is filled with 0, and the zero field is filled with client_ver. The generated 1528 is treated as follows: Enter the pseudo-random number first, then, encrypt a key in a certain location. Because we do not pay attention to the pseudo-random number generation algorithm and Encryption Algorithm for the time being, the ambiguity here is described.

This is two keys in FFMPEG.

#define PLAYER_KEY_OPEN_PART_LEN 30   ///< length of partial key used for first client digest signing/** Client key used for digest signing */static const uint8_t rtmp_player_key[] = {    'G', 'e', 'n', 'u', 'i', 'n', 'e', ' ', 'A', 'd', 'o', 'b', 'e', ' ',    'F', 'l', 'a', 's', 'h', ' ', 'P', 'l', 'a', 'y', 'e', 'r', ' ', '0', '0', '1',    0xF0, 0xEE, 0xC2, 0x4A, 0x80, 0x68, 0xBE, 0xE8, 0x2E, 0x00, 0xD0, 0xD1, 0x02,    0x9E, 0x7E, 0x57, 0x6E, 0xEC, 0x5D, 0x2D, 0x29, 0x80, 0x6F, 0xAB, 0x93, 0xB8,    0xE6, 0x36, 0xCF, 0xEB, 0x31, 0xAE};#define SERVER_KEY_OPEN_PART_LEN 36   ///< length of partial key used for first server digest signing/** Key used for RTMP server digest signing */static const uint8_t rtmp_server_key[] = {    'G', 'e', 'n', 'u', 'i', 'n', 'e', ' ', 'A', 'd', 'o', 'b', 'e', ' ',    'F', 'l', 'a', 's', 'h', ' ', 'M', 'e', 'd', 'i', 'a', ' ',    'S', 'e', 'r', 'v', 'e', 'r', ' ', '0', '0', '1',    0xF0, 0xEE, 0xC2, 0x4A, 0x80, 0x68, 0xBE, 0xE8, 0x2E, 0x00, 0xD0, 0xD1, 0x02,    0x9E, 0x7E, 0x57, 0x6E, 0xEC, 0x5D, 0x2D, 0x29, 0x80, 0x6F, 0xAB, 0x93, 0xB8,    0xE6, 0x36, 0xCF, 0xEB, 0x31, 0xAE};

Extract rtmp_validate_digest and related dependency functions from FFMPEG, and test S1 (fms4). The ciphertext contains rtmp_server_key, because Sha (secure hash algorithm) encryption is irreversible, therefore, you can only check whether the ciphertext exists in this sequence.

Problems encounteredYes, in some cases, the C1 sent by the client is completely random, and the rtmp_player_key is not encrypted, and then on the way (a node on the network, which is unknown here, the handshake cannot be linked successfully. After the ciphertext is added, the handshake is successful. This is indeed a little tricky.

Correction:

After testing, FME (Flash Media Encoder) is also used for streaming, and this problem is not encountered. Maybe there are multiple public and available keys, and Flash Player does not have any keys? Do you still know the key of Flash Player and limit it?