Completed backdoor and c2 section

docs/chapters/chapter4.tex

@@ -1002,7 +1002,7 @@ Figure \ref{fig:c2_summ_example} illustrates this expalantion by showing how the
 As we can observe in the figure, the XDP program at the backdoor is responsible of sniffing the network for a backdoor trigger to authenticate an attacker and start the phantom shell or, afterwards, a phantom shell header. Once the XDP program or the rootkt user program write into the shared eBPF map that a phantom shell packet is needed to be sent, the TC egress program hijacks the first TCP packet that an user application requests to send through the network. TCP retransmissions ensure that this packet is eventually delivered.
 
 
-\textbf{Backdoor commands}
+\textbf{Backdoor commands}\\
 Apart from supporting the remote execution of commands via the shell-like connections we have covered in this section, the backdoor also enables two other backdoor commands which modify the behaviour of the rootkit. As we can observe in table \ref{table:k3_values}, these commands consist on enabling or disabling eBPF programs remotely.
 
 These commands are launched from the rootkit client, and get sent to the backdoor in the form of either a pattern-based trigger or any of the two forms of multi-packet trigger. As with any other backdoor trigger, the XDP program checks the value of K3 contained in the trigger and issues the corresponding action.
@@ -1011,9 +1011,46 @@ In the case of these commands, the order needs to be transmitted to the rootkit
 
 
 \subsection{Backdoor internals}
-This section offers detailed insight into the functioning of the XDP and TC programs composing our backdoor. In particular, we will analyse their life cycle and operation, from when they are loaded and attached until they 
+This section offers insight into the functioning of the XDP and TC programs composing our backdoor. In particular, we will analyse their life cycle and operation, starting from the point when they are loaded and attached, and describing how they interact with the network traffic at the infected machine.
+
+\textbf{XDP}\\
+The XDP program is responsible of sniffing incoming network traffic and detecting backdoor triggers sent by the rootkit client. For this, it acts as a filter, where packets get passed to the kernel or go to the next filter depending on whether they meet certain criteria. Figure \ref{fig:c2_summ_xdp} illustrates the complete life cycle of the XDP program.
+
+\begin{figure}[htbp]
+	\centering
+	\includegraphics[width=15cm]{c2_summ_xdp.png}
+	\caption{Life cycle of the backdoor XDP program.}
+	\label{fig:c2_summ_xdp}
+\end{figure}
+
+As we can observe in the figure, the XDP program must be attached to a network interface of the infected machine (eth0, wlan0...). Once attached, it will repeatedly sniff the incoming network traffic.
+
+For any packet received, a filtering routine will be applied, whose purpose is to discard any packet the backdoor will not work with, only keeping TCP/IP packets. Moreover, these initial checks done with the purpose of determining the protocol must always been made, otherwise the eBPF verifier may consider any access to the packet as invalid (since it will not be sure about the type and bounds of the fields it is accessing). We can also appreciate that the XDP program filters according to the destination port. The reason is that we have designed our backdoor trigger so that they are always directed to this port number.
+
+After the initial filtering routine, the XDP program will check for any of the triggers or headers it could be receive to support the C2 capabilities of the backdoor. For this, more filters will be implemented, usually checking for the payload or packet size first, and later checking for the actual contentsm since the verifier forbids accessing payload data if its length is not assured. Also, in the case of working with multi-packet triggers, the related eBPF maps must be updated with the log of the latest packets received, as we described in section \ref{subsection:triggers}.
+
+Once the type of trigger is detected, XDP proceeds to perfom the actions related to the value of K3 found inside each trigger. As we described in section \ref{subsection:c2}, these include writing into the ring buffer or communicating with the TC program via the shared eBPF map.
+
+Note that in this diagram it has been omitted the section related with modifying incoming packets, used for the PoC shown in section \ref{TODO}. The reason is that its functionality is identical to that being shown in figure \ref{fig:c2_summ_tc} implemented by the TC program.
 
 
+\textbf{TC}\\
+The TC egress program is responsible for sniffing outgoing network traffic and modifying those packets needed for the C2 functionality, like the phantom shell. Similarly to the XDP program, it is composed of multiple layers of filters, whose purpose is to determine the packet protocol and the correctness of the data. Figure \ref{fig:c2_summ_tc} shows the complete life cycle of the TC program.
+
+\begin{figure}[htbp]
+	\centering
+	\includegraphics[width=13cm]{c2_summ_tc.png}
+	\caption{Life cycle of the backdoor TC program.}
+	\label{fig:c2_summ_tc}
+\end{figure}
+
+As we can observe in the figure, the TC program will ignore any packet until some data arrives at the shared eBPF map. At that point, it will proceed to overwrite the packet with the data it has been sent by the XDP or rootkit user process. In particular, it must redirect the destinatary of the original packet (thus changing the IP address and destination port) and modify the payload of the packet. Therefore, it approaches the packet modification in two steps:
+\begin{itemize}
+\item Modifying the IP and TCP headers of the packet with the new destination data.
+\item Modifying the payload. Most of the times, this payload will be of different length compared to that of the original TCP packet, and therefore the TC program must modify the packet bounds. This is done using the bpf\_skb\_change\_tail helper, which we covered in section \ref{subsection:tc}. Note that, once we modify the packet bounds, the eBPF verifier will no longer trust our original checks with respect to the packet protocol and the validity of the payload. Therefore, all checks must be repeated before being able to overwrite the payload of the packet.
+\end{itemize}
+
+After the requested modifications are made, the TC program passes the packet to the next layer in the kernel.