Continued with c2, bit i didnt like the structure, so it needs to be reformatted

docs/bibliography/bibliography.bib

@@ -727,6 +727,11 @@ AMD64 Architecture Processor Supplement},
 	title={Cyclic redundancy check},
 	organization={Wikipedia},
 	url={https://en.wikipedia.org/wiki/Cyclic_redundancy_check}
+},
+
+@online{file_descriptors,
+	title={File Descriptor},
+	url={http://www.cse.cuhk.edu.hk/~ericlo/teaching/os/lab/11-FS/fd.html}
 }
 
 

docs/chapters/chapter4.tex

@@ -76,7 +76,7 @@ This program is also responsible of creating the shared map which the backdoor w
 
 
 
-\section{Library injection module}
+\section{Library injection module} \label{section:lib_injection}
 In this section, we will discuss how to hijack an user process running in the system so that it executes arbitrary code instructed from an eBPF program. For this, we will be injecting a library which will be executed by taking advantage of the fact that the GOT section in ELFs is flagged as writable (as we introduced in section \ref{subsection:elf_lazy_binding} and using the stack scanning technique covered in section \ref{subsection:bpf_probe_write_apps}. This injection will be stealthy (it must not crash the process), and will be able to hijack privileged programs such as systemd, so that the code is executed as root.
 
 We will also research how to circumvent the protections which modern compilers have set in order to prevent similar attacks (when performed without eBPF), as we overview in section \ref{subsection:hardening_elf}.
@@ -668,7 +668,7 @@ Apart from the XDP and TC eBPF programs which compound the core of the backdoor
 
 Note that IDSs and firewalls are usually located outside of the host, in the middle point between the router which connects to the Internet and the host. Therefore, it is not enough that we hide our rootkit packets from the kernel using XDP as we explained in section \ref{section:abusing_networking}, but rather we must aim to design packets which are not suspicious to be malicious even from the perspective of software that sits in the middle of all of our transmissions through the network.
 
-\subsection{Backdoor triggers}
+\subsection{Backdoor triggers} \label{subsection:triggers}
 After a machine is infected by the rootkit, the rootkit client program will be used by the attacker to initiate a connection with the backdoor. However, first and foremost the backdoor needs to be able to detect whether a packet corresponds to common traffic generated by the host applications, or if it is coming from the rootkit client. This is because the attacker may be launching the rootkit client from any IP address, and listening at any port, so the backdoor must learn this parameters from the rootkit client, whose identity must be "authenticated" before establishing a connection with it. The first packet or group of packets whose purpose is to instruct the backdoor about who is the rootkit client and initiate a connection is known as a "trigger".
 
 Although there exist a wide variety types of triggers, each type offers different advantages and drawbacks. In our rootkit, we have implemented multiple triggers with the purpose of discussing multiple authentication options, ranging from simple keywords inserted on packets, to complex packet streams that are based on triggers found in real-world rootkits.
@@ -822,8 +822,91 @@ By using the previous maps, the XDP program will first wait until 3 (or 6) packe
 If the previous checks do not fail, it means the packet stream was a multi-stream trigger and the XDP program proceeds to execute the action corresponding to K3.
 
 
-\subsection{Rootkit protocols}
-The backdoor and the rootkit client program will exchange messages contianing commands and information. For this, both programs need to agree on a common protocol which is mutually understood, defining the format and content of these transmissions.
+
+%TODO INTRODUCE IMAGES OF SHELLS
+\subsection{Command and Control} \label{subsection:c2}
+%TODO REFORMAT ALL THIS SECTION. I WAS NOT SATISFIED WITH THE STRUCTURE, SO A REMODEL MUST BE MADE.
+The backdoor and the rootkit client will exchange messages containing commands and information. For this, both programs need to agree on a common protocol which is mutually understood, defining the format and content of these transmissions.
+
+The first and most important message in the protocol is the trigger, which has been explained in section \ref{subsection:triggers}. As we mentioned, depending on the value of K3 in the trigger, a different rootkit action will be executed. Some of these actions, as we saw in table \ref{table:k3_values}, involve the creation of shell-like connections, which may involve the execution of a real shell program (bash, sh), or a user space program on the infected machine (requesting its creation from the backdoor to the rootkit user space program via the ring buffer). 
+
+In this section, we will explore 
+
+the different shell-like connections that we can find in our rootkit, from the simplest to the most complex. In the end, all of them have a common purpose: enabling the attacker to introduce commands from the remote rootkit client and to be executed in the infected machine, returning the output of the command back to the client. 
+
+
+
+\textbf{Reverse shell}\\
+This is the simplest and most automated shell we can obtain from an infected machine. This is the shell that is spawned when we inject the malicious library of the library injection module (section \ref{section:lib_injection}), therefore the parties involved in the transmission are the rootkit client and the malicious library.
+
+A reverse shell is initiated from the infected machine to the attacker, that is, the infected machine initiates the connection. It is usually created in three steps:
+\begin{enumerate}
+\item Open a socket and setting a TCP connection with the attacker IP and listening port (other protocols may be used too).
+\item Readjusting the three standard POSIX file descriptors in the infected machine (stdin, stdout, stderr) \cite{file_descriptors} so that they refer to the same file descriptor of the socket.
+\item Executing a shell program (bash, sh).
+\end{enumerate}
+
+With the above setup, any command received in the socket (which is now a duplicate of file descriptor stdin) will be used by the shell program as an input. The shell program will execute the command and return the output in stdout, which since it is now a duplicate of the socket, it will be written into the socket, sending the message to the attacker through the network.
+
+The attacker, for its part, can accept the TCP connection requested by the infected machine, opening a socket and writing to it to send commands, and reading from the socket to receive the output of the commands' execution on the victim.
+ 
+ 
+ 
+\textbf{Plaintext pseudo-shell}\\
+This shell-like connection enables the attacker to send commands, execute them in the infected machine and receive back the output without the execution of any shell program, and with all transmissions being sent in plaintext over the network.
+
+As we will cover more extensively in section \ref{}, this is the type of shell that is obtained by running the malicious program of the execution hijacking module of the rootkit. The rootkit currently does not incorporate a backdoor trigger that launches this module, but rather it is started automatically (see table \ref{table:k3_values}, we have not included a K3 for running an unencrypted pseudo-shell).
+
+For starting a plaintext pseudo-shell, the rootkit client and the malicious program from the execution hijacking module (hereafter called the rootkit, since it is part of it) will make use of a master/slave protocol where the rootkit client acts as the master (sending commands) and the rootkit acts as the slave (it only sends data in response of a client message). On each transmission, the rootkit client will send a single TCP packet (without a preceeding 3-way handshake) in which the command is embedded as the payload. The rootkit will execute this command and answer back with the output in another single TCP packet.
+
+Apart from the data being transmitted (the command and the output of that command), we will find a protocol header embedded in the packet payload too. This header will be positioned starting at the first byte of the packet payload, preceeding any other data, which is written in the next byte right after the header ends. Figure \ref{fig:ups_packet_struct} shows the overall structure of one of the TCP packets being used in the protocol. Table \ref{table:ups_headers} shows the different headers and their meaning in the protocol.
+
+\begin{figure}[htbp]
+	\centering
+	\includegraphics[width=7cm]{ups_packet_struct.png}
+	\caption{Packet structure in a plaintext rootkit pseudo-shell.}
+	\label{fig:ups_packet_struct}
+\end{figure}
+
+\begin{table}[htbp]
+\begin{tabular}{|c|>{\centering\arraybackslash}p{8cm}|}
+\hline
+\textbf{Header} & \textbf{Description}\\
+\hline
+\hline
+CC\_SYN & Sent by the rootkit client to the rootkit, requests to initiate a connection. Expects a packet with CC\_ACK in response.\\
+\hline
+CC\_ACK & Sent by the rootkit to the rootkit client, indicates readiness to initiate a connection.\\
+\hline
+CC\_MSG\# & Packet with data. If sent by the rootkit client, it contains a command. If sent by the rootkit, it contains the command execution output.\\
+\hline
+CC\_FIN & Sent by the rootkit client. Requests to terminate the pseudo-shell connection.\\
+\hline
+CC\_ERR & Sent by the rootkit. Indicates that the rootkit failed to parse the packet that the rootkit client sent.\\
+\hline
+\end{tabular}
+\caption{Protocol headers in the plaintext rootkit pseudo-shell.}
+\label{table:ups_headers}
+\end{table}
+
+Figure \ref{fig:ups_transmission} illustrates a common transmission following the described protocol.
+
+\begin{figure}[htbp]
+	\centering
+	\includegraphics[width=11cm]{ups_transmission.png}
+	\caption{Execution of a command using a plaintext rootkit pseudo-shell.}
+	\label{fig:ups_transmission}
+\end{figure}
+
+As we can observe in figure \ref{fig:ups_transmission}, packets containing CC\_SYN and CC\_ACK act as a custom 2-way handshake. This step could be considered redundant and has been included only to share a resemblance with the TCP protocol.
+
+Also, note that after a successful CC\_SYN-CC\_ACK exchange there is no need to repeat it after a CC\_MSG, the transmission will consist on consecutive CC\_MSG packets until the pseudo-shell is closed from the rootkit client.
+
+
+\textbf{Encrypted pseudo-shell}
+Similarly to plaintext pseudo-shells, encrypted pseudo-shells enable the attacker to send commands, execute them in the infected machine and receive back the output, but all transmissions will be contained in the context of a secure encrypted connection using TLS.
+
+In our rootkit, this type of shells are spawned after the rootkit client requests such an action to the network backdoor by setting the appropiate value of K3 (see table \ref{table:k3_values}) on either a pattern-based backdoor trigger or a multi-packet trigger.