App application identification method and device for tg framework, medium and product

Abstract

The embodiment of the application relates to the technical field of flow identification, and discloses an APP application identification method, equipment, medium and product for a TG framework. TCP flow is collected; a key and an initialization vector are extracted from a first uplink packet with a load of the TCP flow; data of the first uplink packet with the load is decrypted by using an aes algorithm according to the key and the initialization vector, and up_aes_key_id is obtained; data of the first downlink packet with the load is decrypted by using the aes algorithm according to the key and the initialization vector, and dn_aes_key_id is obtained; when the up_aes_key_id and the dn_aes_key_id are the same, it is determined that the TCP flow is an APP application using the TG framework. The technical problem of TG framework application flow identification can be solved at least.

Description

Technical Field

[0001] The present application relates to the field of traffic identification technology, and in particular to an APP application identification method, device, medium and product for a TG framework. Background Art

[0002] Telegram (TG) is a widely used instant messaging platform that supports end-to-end encrypted communications, file transfers, and other features, providing users with a secure and convenient way to communicate. With the open source implementation of the MTProto transmission protocol used by TG, developers can quickly build applications with similar communication capabilities based on the publicly available framework code. Applications developed based on the TG framework encrypt data traffic during network communications to ensure the security of communications.

[0003] Traditional application identification methods rely primarily on analyzing plaintext traffic features, such as port information, protocol fields, and data payload content. However, because the TG framework encrypts and encapsulates data traffic, traditional methods struggle to identify applications based on the framework by parsing plaintext features. This makes it impossible to accurately distinguish this encrypted traffic from other types of encrypted traffic in scenarios such as network traffic monitoring and application classification management.

[0004] To effectively identify applications developed using the TG framework, in-depth analysis of the specific protocol characteristics of their encrypted traffic is necessary. Currently, there is a lack of reliable technical solutions for identifying TG framework encrypted traffic. An identification method that can reverse-engineer traffic based on the encryption principles is urgently needed to address the limitations of traditional identification methods in encrypted traffic scenarios and provide technical support for network traffic management, application behavior analysis, and other applications. Summary of the Invention

[0005] One purpose of this application is to provide an APP application identification method, device, medium and product for the TG framework, at least to solve the technical problem of TG framework application traffic identification.

[0006] To achieve the above objectives, some embodiments of the present application provide the following aspects:

[0007] In the first aspect, some embodiments of the present application also provide an APP application identification method for the TG framework, including collecting TCP traffic; extracting a key and an initialization vector from the first loaded uplink packet of the TCP traffic; using the AES algorithm to decrypt the data of the first loaded uplink packet according to the key and initialization vector, and obtaining up_aes_key_id; using the AES algorithm to decrypt the data of the first loaded downlink packet according to the key and initialization vector, and obtaining dn_aes_key_id; when the up_aes_key_id and the dn_aes_key_id are the same, it is determined that the TCP traffic is an APP application using the TG framework.

[0008] In a second aspect, some embodiments of the present application further provide an electronic device comprising: one or more processors; and a memory storing computer program instructions, wherein the computer program instructions, when executed, cause the processor to perform the steps of the method described above.

[0009] In a third aspect, some embodiments of the present application further provide a computer-readable medium having computer program instructions stored thereon, wherein the computer program instructions can be executed by a processor to implement the method described above.

[0010] In a fourth aspect, some embodiments of the present application further provide a computer program product, comprising a computer program / instruction, which implements the steps of the above-described method when executed by a processor.

[0011] Compared with the related technologies, the solution provided in the embodiment of the present application proposes an APP application identification method developed for the TG framework through in-depth research on the TG framework transmission protocol. Based on the traffic encryption principle of the TG framework, it is reversely processed, which can accurately identify the TG framework application and provide strong support for the analysis of fraud-related APPs. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] One or more embodiments are exemplarily illustrated by pictures in the corresponding drawings. These exemplifications do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings are represented as similar elements. Unless otherwise stated, the figures in the drawings do not constitute proportional limitations.

[0013] Figure 1 Schematic diagram of a flow chart of an APP application identification method for the TG framework provided according to an embodiment of the present application;

[0014] Figure 2 Schematic diagram of a flow chart of another APP application identification method for the TG framework provided according to an embodiment of the present application;

[0015] Figure 3 The figure is a schematic diagram of the structure of an electronic device provided according to an embodiment of the present application. DETAILED DESCRIPTION

[0016] To make the purpose, technical solutions, and advantages of the embodiments of this application more clear, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0017] First embodiment

[0018] The first embodiment of this application relates to a method for identifying APP applications for TG framework. Figure 1 As shown, the method may include the following steps:

[0019] S101, collects TCP traffic:

[0020] By collecting two-way TCP traffic, a network communication data foundation is provided for subsequent analysis, ensuring coverage of the entire upstream and downstream process data of the interaction between the client and the server, avoiding identification bias caused by data missing; at the same time, TCP traffic is clearly used as the analysis object, and the communication characteristics of the TG framework based on the TCP protocol are adapted to ensure the matching of data collection with the target scenario.

[0021] S102: Extract the key and initialization vector from the first uplink packet with payload of the TCP traffic:

[0022] By accurately locating the specific byte interval of the first uplink packet with a payload to extract the AES key (aes_key) and initialization vector (aes_iv), the problem of the key parameters in the TG framework encrypted traffic being difficult to obtain directly is solved; by utilizing the payload characteristics of the initial uplink packet, it is ensured that the extracted encryption parameters are the original key pair negotiated by the communicating parties, providing a reliable key basis for subsequent decryption operations and avoiding decryption failures caused by key errors.

[0023] S103: Decrypt the data of the first uplink packet with payload using the AES algorithm according to the key and the initialization vector to obtain up_aes_key_id:

[0024] The uplink packet data is decrypted by AES based on the extracted key aes_key and initialization vector aes_iv. Combined with the TG framework's unique encrypted data length negotiation logic (determining the message length and offset through the decrypted value), the uplink direction feature identifier (up_aes_key_id) can be accurately extracted from the encrypted payload. This feature identifier is a unique key-associated value generated during the TG framework communication process, providing a quantifiable uplink feature basis for subsequent two-way traffic comparison, solving the problem that traditional methods cannot extract effective features from encrypted traffic.

[0025] S104: Decrypt the data of the first downlink packet with payload using the AES algorithm according to the key and the initialization vector to obtain dn_aes_key_id:

[0026] The downlink packet data is decrypted using the key aes_key and initialization vector aes_iv that are consistent with the uplink packet. Combined with the offset rule of the downlink packet payload, the feature identifier (dn_aes_key_id) of the downlink direction is extracted. Through bidirectional symmetric decryption logic, the downlink features are ensured to be comparable with the uplink features, laying the foundation for subsequent consistency comparison and avoiding feature mismatches caused by differences in decryption logic.

[0027] S105: When the up_aes_key_id and the dn_aes_key_id are the same, it is determined that the TCP traffic is an APP application using the TG framework:

[0028] By verifying the consistency of up_aes_key_id and dn_aes_key_id, and taking advantage of the fact that uplink and downlink traffic in TG framework communication share the same key association value, accurate identification of encrypted traffic is achieved; this judgment logic is based on the feature association of bidirectional traffic, avoiding the possible randomness or misjudgment risks of single-directional features, significantly improving the accuracy and reliability of the identification results, and providing effective technical support for scenarios such as network traffic management and application classification.

[0029] Second embodiment

[0030] The second embodiment of this application relates to a method for identifying APP applications for the TG framework. The second implementation is an improvement based on the first embodiment, and the specific improvements are:

[0031] Furthermore, extracting the key and the initialization vector from the first uplink packet with a payload of the TCP traffic includes:

[0032] For the first upstream packet with load of the TCP traffic, the 9th to 40th bytes of the load are extracted as the key, and the 41st to 64th bytes of the load are extracted as the initialization vector.

[0033] Furthermore, the use of the AES algorithm to decrypt the data of the first uplink packet with a payload includes:

[0034] Perform an AES decryption operation on the 65th byte of the payload using the key and initialization vector to obtain the value len;

[0035] When the value len!=0x7F, the length of the encrypted data is msg_len=len×4, and the offset value offset=1 is recorded;

[0036] When the value len=0x7F, the 65th to 68th bytes of the payload are decrypted using aes to obtain the value len1, and the length of the encrypted data is msg_len=len1×4, and the offset value offset=4 is recorded.

[0037] Furthermore, obtaining up_aes_key_id includes:

[0038] The data after the payload offset 64+offset is decrypted by the key and initialization vector, and the value of the first 8 bytes of the decrypted data is taken as up_aes_key_id.

[0039] Furthermore, the decryption of the first downlink packet with a payload using the AES algorithm includes:

[0040] Perform an AES decryption operation on the first byte of the payload using the key and initialization vector to obtain the value len;

[0041] When the value len!=0x7F, the length of the encrypted data is msg_len=len×4, and the offset value offset=1 is recorded;

[0042] When the value len=0x7F, the aes decryption operation is performed on the 1st to 4th bytes of the payload to obtain the value len1, and the length of the encrypted data is msg_len=len1×4, and the offset value offset=4 is recorded.

[0043] Furthermore, obtaining dn_aes_key_id includes:

[0044] The data after the payload offset is decrypted using the key and initialization vector, and the value of the first 8 bytes of the decrypted data is taken as dn_aes_key_id.

[0045] Furthermore, collecting TCP traffic includes: collecting bidirectional TCP traffic through a network traffic monitoring device, and recording load data and timestamps of uplink packets and downlink packets of each TCP connection.

[0046] like Figure 2 As shown, TCP traffic is collected. Bidirectional TCP traffic is collected through network traffic monitoring equipment (such as traffic analysis gateways, intrusion detection systems, etc.), focusing on recording the load data and timestamps of the uplink packets (client→server) and downlink packets (server→client) of each TCP connection.

[0047] TCP traffic was chosen as the analysis object because the MTProto protocol of the TG framework defaults to communicating over the TCP transport layer. The acquisition range needs to cover the entire connection cycle (from establishment to disconnection), but only the first uplink / downlink packet with a load needs to be focused on (i.e., the first message carrying valid data after the connection is established) to avoid redundant data interference.

[0048] Extract the key and initialization vector. The first uplink packet with a payload is the encrypted data sent for the first time after the client and server establish a connection. Its payload contains the AES encryption parameters negotiated by the communicating parties.

[0049] The payload's [9, 40] bytes (32 bytes total) are selected as the AES key (aes_key) because the TG framework uses the AES-256 symmetric encryption algorithm (a 256-bit key corresponds to 32 bytes). Bytes [41, 64] bytes (24 bytes total) are used as the initialization vector (aes_iv), meeting the IV length requirements for AES-CBC mode (or similar modes) (typically 16 or 24 bytes, as defined by the protocol specification). The deterministic extraction position (fixed byte interval) stems from the TG framework's standardized encapsulation rules for encryption parameters, ensuring consistent key extraction logic across different connections.

[0050] The AES algorithm is used to decrypt the first byte of buf (byte 65) after the payload offset of 64 bytes to obtain the value len. The first 64 bytes ([1,64]) of the uplink packet payload are used to extract the key and IV. Bytes 65 and beyond contain the metadata field for the encrypted data. By decrypting the 65th byte with AES, the value len, which indicates the length of the encrypted data, is obtained.

[0051] The 65th byte is the "length identification field" defined by the TG framework, which is used to indicate the length of the subsequent encrypted data; the decryption operation must strictly use aes_key and aes_iv to ensure consistency with the encryption logic of the communicating parties.

[0052] If the decrypted value len is not 0x7F, Msg_len and offset are determined. The value of len directly represents the "basic length unit" of the encrypted data (defined by the TG framework). The byte length of the actual encrypted data can be calculated using Msg_len = len × 4. An offset of 1 indicates that the length identifier field occupies only 1 byte, and subsequent encrypted data begins at byte 65 + 1 = 66. This rule is suitable for scenarios with short encrypted data lengths and complies with the TG framework's efficient encapsulation design for small data packets.

[0053] When the decrypted value len is 0x7F, Msg_len and offset are expanded. Since the encrypted data length exceeds the representation range of the short field, further parsing using the extended field is required. In this case, the AES algorithm is used to decrypt the first four bytes of buf (bytes 65-68) to obtain the extended length value len1. The actual length is calculated by taking Msg_len = len1 × 4. Offset = 4 indicates that the length identifier field is extended to 4 bytes, and subsequent encrypted data begins at byte 65 + 4 = 69. This design solves the length representation issue for large data packets in the TG framework, ensuring complete parsing of long data.

[0054] After decrypting the msg_len length bytes of buf, the data is offset to obtain the up_aes_key_id. After determining the starting position of the encrypted data (64 + offset bytes), the payload data at that position is decrypted using AES. The first 8 bytes of the obtained plaintext data are the uplink key association identifier (up_aes_key_id). The up_aes_key_id is a unique identifier generated during the TG framework communication process and is used to associate the encryption key for uplink and downlink traffic. It is highly distinctive.

[0055] The payload structure of the downlink packet (server → client) is different from that of the uplink packet. The metadata field of the encrypted data begins at the first byte of the payload. AES is used to decrypt the first byte of the payload to obtain the downlink length indicator value, len. The downlink packet does not need to extract the key and IV (it shares the same aes_key and aes_iv as the uplink packet), so the metadata is parsed directly from the first byte.

[0056] The decryption logic is consistent with the uplink packet (using the same aes_key and aes_iv), ensuring comparability between two-way decryptions. The decrypted value len is evaluated: if len is not 0x7F, Msg_len = len × 4, with offset = 1. If len is 0x7F, decrypt the [1, 4] bytes to obtain len1, Msg_len = len1 × 4, with offset = 4.

[0057] Downlink and uplink packets use the same length calculation rules to ensure symmetric parsing logic for bidirectional traffic and avoid feature mismatches due to rule differences. After decrypting the downlink offset, the data is retrieved to obtain the dn_aes_key_id. After determining the starting position (offset byte) of the encrypted downlink packet, the payload at that position is decrypted using AES. The first 8 bytes of the obtained plaintext data are the downlink key association identifier (dn_aes_key_id).

[0058] dn_aes_key_id and up_aes_key_id have the same origin (generated by the same aes_key and aes_iv). They are the "key binding identifiers" for upstream and downstream traffic in TG framework communication and should theoretically be completely consistent.

[0059] If up_aes_key_id is the same as dn_aes_key_id, it means that the uplink and downlink traffic use the same set of encryption parameters to generate key association identifiers, which meets the communication characteristics of the TG framework's "bidirectional traffic shared key" and can be determined to be APP traffic developed based on the TG framework.

[0060] This judgment logic utilizes the "two-way key binding" feature of the TG framework encrypted traffic, avoiding the misjudgment caused by traditional methods that only analyze one-way traffic or plaintext features; it can be combined with other auxiliary verifications (such as whether the target port is a commonly used TG port, whether the traffic contains framework-specific fields) to further improve accuracy.

[0061] The step division of the above various methods is only for the purpose of clear description. During implementation, they can be combined into one step or some steps can be split and decomposed into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this application; adding insignificant modifications or introducing insignificant designs to the algorithm or process without changing the core design of the algorithm and process are all within the scope of protection of this application.

[0062] In addition, some embodiments of the present application further provide an electronic device. The electronic device may be various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, etc. The electronic device may also be various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices.

[0063] The electronic device includes: one or more processors; and a memory storing computer program instructions, wherein the computer program instructions, when executed, enable the processor to perform the steps of the method provided in any one or more of the above embodiments. Figure 3 An exemplary structural diagram of the electronic device is disclosed. Figure 3As shown, the electronic device includes: one or more processors 1101, memory 1102, and interfaces for connecting various components, including high-speed and low-speed interfaces. The various components are interconnected using different buses and can be mounted on a common motherboard or in other ways as needed. The processor can process instructions executed within the electronic device, including instructions stored in or on the memory for displaying graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In some other embodiments, if desired, multiple processors and / or multiple buses can be used with multiple memories and multiple storage devices. Similarly, multiple electronic devices can be connected, with each device providing some of the necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present application described and / or claimed herein.

[0064] The electronic device may further include: an input device 1103 and an output device 1104. The processor 1101, the memory 1102, the input device 1103 and the output device 1104 may be connected via a bus or other means. Figure 3 The bus connection is taken as an example.

[0065] Input device 1103 can receive input digital or character information and generate key signal input related to user settings and function control of the electronic device. Examples include a touch screen, keypad, mouse, trackpad, touchpad, pointing stick, one or more mouse buttons, trackball, joystick, and other input devices. Output device 1104 may include a display device, auxiliary lighting devices (e.g., LEDs), and tactile feedback devices (e.g., vibration motors). The display device may include, but is not limited to, a liquid crystal display (LCD), a light-emitting diode (LED) display, and a plasma display. In some embodiments, the display device may be a touch screen.

[0066] To provide user interaction, the electronic device may be a computer. The computer includes a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user, as well as a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other types of devices may also be used to provide user interaction; for example, feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback), and input from the user may be received in any form, including acoustic input, voice input, or tactile input.

[0067] In the embodiments of the present application, a computer program / instruction is stored on a computer-readable medium. When executed by a processor, the computer program / instruction implements the steps of the method provided in any one or more of the above embodiments. The computer-readable medium may be included in the electronic device described in the above embodiments, or it may exist independently and not be incorporated into the device. The computer-readable medium carries one or more computer-readable instructions.

[0068] The memory 1102 can be used as a non-transitory computer-readable storage medium to store non-transitory software programs, non-transitory computer executable programs, and modules. The processor 1101 executes the non-transitory software programs, instructions, and modules stored in the memory 1102 to execute various functional applications and data processing of the server, thereby implementing the program instructions / modules corresponding to the method provided in any one or more of the above embodiments of the present application.

[0069] The memory 1102 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device, etc. In addition, the memory 1102 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some embodiments, the memory 1102 may optionally include a memory remotely located relative to the processor 1101, and these remote memories may be connected to the electronic device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0070] It should be noted that the computer-readable medium described in this application may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. Computer-readable media may include, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or components, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to, an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this application, a computer-readable medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, device, or component.

[0071] Computer-readable media includes both permanent and non-permanent, removable and non-removable media, and can be implemented using any method or technology for information storage. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc-read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device.

[0072] Computer program code for performing the operations of the present application can be written in one or more programming languages, or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0073] In the above embodiments, all or part of the embodiments may be implemented using software, hardware, firmware, or any combination thereof. For example, implementation may be achieved using an application-specific integrated circuit (ASIC), a general-purpose computer, or any other similar hardware device. In some embodiments, the software program of the present application may be executed by a processor to implement the above steps or functions. Similarly, the software program of the present application (including related data structures) may be stored in a computer-readable recording medium, such as a RAM memory, a magnetic or optical drive, a floppy disk, or the like. In addition, some steps or functions of the present application may be implemented using hardware, for example, as a circuit that cooperates with a processor to perform the various steps or functions.

[0074] The computer program product provided in the embodiments of the present application includes one or more computer programs / instructions, which, when executed by a processor, generate, in whole or in part, the processes or functions described in the embodiments of the present application. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server or data center that includes one or more available media. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state disk (SSD)).

[0075] The flowcharts or block diagrams in the accompanying drawings illustrate the possible architectures, functions and operations of the devices, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, program segment or part of code, and the module, program segment or part of code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, as well as the combination of boxes in the block diagram and / or flowchart, can be implemented with a dedicated hardware-specific system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0076] The scope of this application is defined by the appended claims rather than the foregoing description and is therefore intended to encompass within this application all changes that come within the meaning and range of equivalents of the claims. Any reference signs in the claims should not be construed as limiting the claims to which they relate. In addition, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices stated in a device claim may also be implemented by one unit or device through software or hardware. Words such as "first" and "second" are only used to distinguish the description and do not indicate any particular order, nor should they be understood as indicating or implying relative importance.

[0077] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any person skilled in the art may easily propose variations or substitutions within the technical scope disclosed in the present application, and such variations or substitutions shall be encompassed within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be subject to the scope of protection of the claims, and the above embodiments shall be regarded as exemplary and non-limiting.

Claims

1. A method for identifying APP applications based on the TG framework, characterized in that: The method comprises: Collect TCP traffic; Extracting a key and an initialization vector from the first upstream packet with a payload of the TCP traffic; Decrypt the data of the first uplink packet with payload using the AES algorithm according to the key and initialization vector to obtain up_aes_key_id; According to the key and initialization vector, the AES algorithm is used to decrypt the data of the first downlink packet with load to obtain dn_aes_key_id, where the up_aes_key_id and the dn_aes_key_id are key association values ​​generated during the TG framework communication process; When the up_aes_key_id and the dn_aes_key_id are the same, it is determined that the TCP traffic is an APP application using the TG framework.

2. The method according to claim 1, characterized in that Extracting the key and initialization vector from the first upstream packet with payload of the TCP traffic includes: For the first upstream packet with load of the TCP traffic, the 9th to 40th bytes of the load are extracted as the key, and the 41st to 64th bytes of the load are extracted as the initialization vector.

3. The method according to claim 2, characterized in that The data of the first uplink packet with a payload decrypted using the AES algorithm includes: Perform an AES decryption operation on the 65th byte of the payload using the key and initialization vector to obtain the value len; When the value len!=0x7F, the length of the encrypted data is msg_len=len×4, and the offset value offset=1 is recorded; When the value len=0x7F, the 65th to 68th bytes of the payload are decrypted using aes to obtain the value len1, and the length of the encrypted data is msg_len=len1×4, and the offset value offset=4 is recorded.

4. The method according to claim 3, characterized in that The acquisition of up_aes_key_id includes: The data after the payload offset 64+offset is decrypted by the key and initialization vector, and the value of the first 8 bytes of the decrypted data is taken as up_aes_key_id.

5. The method according to claim 2, characterized in that The method of using the AES algorithm to decrypt the data of the first downlink packet with a payload includes: Perform an AES decryption operation on the first byte of the payload using the key and initialization vector to obtain the value len; When the value len!=0x7F, the length of the encrypted data is msg_len=len×4, and the offset value offset=1 is recorded; When the value len=0x7F, the aes decryption operation is performed on the 1st to 4th bytes of the payload to obtain the value len1, and the length of the encrypted data is msg_len=len1×4, and the offset value offset=4 is recorded.

6. The method according to claim 5, characterized in that The obtaining of dn_aes_key_id includes: The data after the payload offset is decrypted using the key and initialization vector, and the value of the first 8 bytes of the decrypted data is taken as dn_aes_key_id.

7. The method according to any one of claims 1 to 6, characterized in that The collecting of TCP traffic includes: collecting bidirectional TCP traffic through a network traffic monitoring device, and recording the load data and timestamps of the uplink packets and downlink packets of each TCP connection.

8. An electronic device, characterized in that: The electronic device comprises: one or more processors; and A memory storing computer program instructions, which, when executed, cause the processor to perform the steps of the method according to any one of claims 1 to 7.

9. A computer-readable medium having a computer program / instruction stored thereon, characterized in that: When the computer program / instructions are executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instructions are executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images