Application Flow

Figure below describes the overall SteganRTP application flow.

**Figure:** SteganRTP application process flowchart.

When the SteganRTP application begins it performs an initialization phase by setting up internal memory structures and configuration information from the command-line. Next, it observes network traffic until it identifies an RTP session which falls within the constraints specified by the user on the command-line. These constraints are how the user controls selection of the RTP sessions between specific RTP endpoints to utilize as cover-medium and, by virtue, which remote SteganRTP application to communicate with. After identifying an RTP session, SteganRTP inserts hooks into the host's network stack in order to receive the desired packets upon transmission or arrival, or both if the SteganRTP application is operating in the active MITM scenario. From these hooks a packet queue is created which the application then reads individual packets from. Whether the packet is considered inbound or outbound determines the further course of the application. Whether a packet is considered inbound or outbound is determined by which RTP endpoint network address and port is defined as ``local'' or ``remote'', which in the case of the active MITM operation can be inferred as ``near'' or ``far'', respectively.

When an inbound RTP packet is read from the queue, it is copied for the application's use and the original packet is immediately sent as the SteganRTP application does not need to invasively modify it. All received inbound packets are assumed to be potential cover-medium for the covert channel, so potential message data is then extracted from each inbound packet. The potential message data is then decrypted, and the result is checked for a valid checksum value in the potential message's header. If the checksum is valid, the message data is sent to the message handler component for processing.

When an outbound RTP packet is read from the queue, the SteganRTP application immediately polls its outbound data queues for any message data waiting to be sent. If there is no data waiting to be sent, the packet is immediately sent unmodified. If there is message data waiting to be sent, as much of that data as will fit into the cover-medium packet's payload is read from its file descriptor, packaged as a formatted message, encrypted, and then steganographically embedded into the RTP packet's payload. The modified RTP packet is then sent in place of the original RTP packet.

Subsections