1.2.1 SQL injection attacks

SQL injection is one of the common tactics used by hackers to attack databases. Due to varying skill levels among programmers, some fail to validate the legitimacy of user input when writing code, which leads to security risks in applications. Users can submit a seemingly normal database query code and obtain certain desired data through the results returned by the program. This is known as SQL injection.

Since SQL injection utilizes normal HTTP requests, it appears indistinguishable from regular HTTP requests on the surface, making it highly covert and difficult to detect.

SQL injection is generally divided into the following steps:

Step one: Determine whether the current environment is vulnerable to SQL injection. If only web pages are accessed and no database operations are involved, then SQL injection is not a concern.

Step two: Identify SQL injection points. Once step one is successful, the next step is to search for SQL injection points. This is typically done by crafting specially formatted inputs and analyzing the browser’s responses to infer the data type. From there, efforts can be made to locate the exact injection point.

Step three: Guess the database username and password. Attackers can use many readily available injection tools found online to crack usernames and passwords.

Step four: Gain access to the website backstage admin panel, which is usually not open to regular users. Attackers can use scanning tools to locate possible admin entry points and then attempt to log in using trial and error until successful access is achieved.

1.2.2 DoS attacks

DoS attacks are also known as denial of service attacks. They can make the target system unable to provide normal services or even crash by exhausting its resources. The system resources under attack include CPU, memory, network bandwidth, and so on. This is a very common attack, with an average of 28 DoS attacks occurring every hour globally. The primary forms of DoS attacks are typically divided into the following three types:

The first type: Constructing a large number of useless connections, which saturates the network bandwidth to the target host, thereby preventing normal requests from communicating with the target host.

The second type: Taking advantage of vulnerabilities in the target host or the transport protocol and sending repeated requests at a high rate, thereby preventing the target host from processing normal requests in a timely manner.

The third type: Taking advantage of vulnerabilities in the target host or the transport protocol and repeatedly sending abnormal attack data to make the target host misallocate a large amount of system resources, thereby paralyzing the host.

Common DoS attack methods include Synflood, Smurf, Land_based, Ping of Death, Teardrop, PingSweep, and Pingflood. The specifics of each method are beyond the scope of this paper. Building upon the foundation of DoS attacks, DDoS attacks (distributed denial of service) have emerged. It refers to the manipulation of a large number of computers to simultaneously attack a target host through a distributed network based on DoS attacks. The number of computers attacked by DDoS attack can often reach million or even ten million, which greatly improves the efficiency and success rate of the attack.

It is worth mentioning that attackers typically obtain botnets by using Trojan horse viruses to infect and take control of a large number of computers and then manipulate these botnets to launch a DDoS attack simultaneously. This poses a significant threat.

1.2.3 Malicious code attacks

Malicious code attacks refer to code that can perform unauthorized operations on a computer, including various Trojan horses, viruses, and buffer overflow attacks. Malicious code attacks pose the greatest threat, encompass the most varieties, are highly transmissible, and are difficult to prevent. Take Trojan horse viruses as an example, they are divided into the controlling end and the controlled end. Once a user is infected with a Trojan horse virus, the attacker will obtain most operating privileges on the target host, including the ability to modify files, modify the registry, control the mouse and the keyboard, and so on. Meanwhile, because Trojan horse viruses are highly covert, attackers usually employ various methods to disguise Trojan horse viruses to make them look the same as normal software, so even if users realize they have been infected with a Trojan horse virus, it is difficult to find and delete it in time.

Malicious code attacks can cause severe consequences as they may steal important information from the victim’s computer, including online banking account details and passwords. They may also encrypt the entire disk for extortion. Moreover, new variants of malicious codes continuously emerge, making it nearly impossible to defend against new types of viruses. Consequently, malicious code attacks have become the greatest threat to cybersecurity.

1.2.4 Phishing websites

Phishing websites typically refer to “spoofed” websites that are disguised as legitimate banking and e-commerce websites, and are often used to steal information submitted by users, such as bank card details, account numbers, passwords, and other information. Phishing websites are generally spread through emails, which often contain a disguised link intended to entice users to click. The pages of phishing websites are usually designed to look identical to those of legitimate websites, with only slight differences in the URL, and they prompt users to submit sensitive information such as usernames and passwords. Generally speaking, phishing websites are relatively low-tech, and all an attacker needs to do is to create a few web pages and a URL that is very similar to that of a legitimate website. However, users can easily fall victim to these scams if they do not exercise caution.

2.1.1 Denial of service

First, denial of service: its goal is to overwhelm network bandwidth and exhaust system resources, such as CPU and memory space of IDS. In addition to generating large amounts of network traffic, the attack can also exploit weaknesses in the detection algorithm. In this type of attack, the attacker uses a backtracking method to attempt to cover all possible rule matches to get the algorithm to compute the worst case every time. In this case, experiments have demonstrated that: Just 4.0 kbps of bandwidth traffic is enough for a DoS attack. This type of attack, which leverages algorithmic complexity rather than overwhelming network bandwidth, is a typical example of a DoS attack.

2.1.2 Packet fragmentation

Packet fragmentation includes IP packet fragmentation and TCP packet segmentation, which divides IP packets or TCP streams into non-overlapping fragments or segments. If IDS is unable to completely reassemble the contents of the packets, it may overlook an attack against the destination host. As an example, IPS might look for the signature “/bin/sh” in a packet payload, but an attacker might split the packet into two fragments, one containing “/bin” and the other containing “/sh”. If the IPS is unable to reassemble these two segments, then it will fail to detect the signature, thus allowing the attacker to evade detection.

Because IDS is responsible for monitoring all network traffic, it must, in theory, reassemble all IP fragments and TCP segments in the network to prevent evasion. However, IDS has resource limitations regarding the information for each connection. As an example, the buffer used for reassembly may be insufficient. Therefore, IP fragmentation or TCP segmentation may be effective, if the IDS happens not to reassemble them.

2.1.3 Duplicate packet insertion

Duplicate packet insertion refers to the tactic of inserting duplicate packets or overlapping TCP segments or IP fragments to confuse IDS. This technique relies on the different methods for processing duplicate or overlapping fragments by IDS and the destination host, as IDS lacks relevant information such as the network topology and the operating system of the destination host. Figure 1 illustrates a specific example of how this technique works. In this example, the attacker inserts a segment with a small TTL value so it is discarded before reaching the destination host.

Overlapping IP fragments and TCP segments may be ambiguous to IDS. As an example, let’s suppose one TCP segment has a sequence number of 10 and a payload of ATTXYZ, while another segment has a sequence number of 13 and a payload of ACK. When both packets are received, the destination host may reassemble them into either ATTXYZ or ATTACK, depending on the operating system of the host. If IDS does not know the operating system of the host, it may process these two packets differently than the host. The attacker can exploit this to evade detection.

2.1.4 Payload transformation

Payload transformation refers to the process by which an attacker converts malicious payloads into semantically equivalent ones. The transformed payload appears different from the signatures that IDS expects, so the attacker can evade detection. Since the transformed payload is semantically the same, the attack remains effective. As an example, using the library libwhisker (www.wiretrip.net/rfp/txt/whiskerids.html), the URL header of an HTTP request can be transformed into an equivalent expression. This transformation can involve hexadecimal encoding. Using the hexadecimal encoding of URLs as an example, if a directory name “cgi-bin” is encoded as “%63%67%69%2d%62%69%6e”, IDS will fail to detect “cgi-bin”. A SQL injection attack can evade detection in the same way.

Similar to duplicate packet insertion, payload transformation is ambiguous for IDS as the processing method differs between the host and the IPS. For example, Apache does not accept backslashes as legitimate slashes, but Microsoft IIS does. As a result, administrators have to configure the IDS to make its processing method consistent with that of the host.

2.1.5 Shellcode transformation

Shellcode transformation involves encoding shellcode into a polymorphic form to evade detection by IDS. There are many methods to achieve this. For example, an attacker can encrypt or compress shellcode and preconfigure a decryption or decompression routine within the code. Attacker can also replace the original code with semantically equivalent code; a specific example is inserting a nop instruction to make the code look different. For example, the instruction mov eax, ebx can be replaced with push ebx, pop eax. This way, signature-based IPS will be unable to detect it, thus enabling evasion. This technique is also used in various types of malware, such as viruses and worms.

Because there are so many ways to transform shellcode, it becomes particularly difficult for IDS to detect polymorphic code. An IDS may need to encrypt and decrypt code or even simulate code execution (e.g., run in a sandbox) to identify malicious behaviors. Thus, reconstructing shellcode becomes particularly computationally intensive, even overwhelming the IDS.

2.3.1 Prevention of DoS attacks

Generally, administrators can enhance resilience against DoS attacks by increasing available bandwidth and utilizing IDS clusters. When a DoS attack occurs, administrators can block specific malicious traffic and investigate the attack vector. Then they report to the IDS developer to check if the IDS is vulnerable to algorithmic complexity attacks.

2.3.2 Prevention of packet fragmentation and duplicate packet insertion

To combat this type of attack, the primary strategy relies on the IDS reassembling packets to restore the original packets. Many current studies have proposed signature matching algorithms instead of packet reassembly. The main idea of this algorithm is to divide the original signatures into smaller ones as well, and then use these smaller signatures to match instead of reassembling the packets. But this algorithm does not address other evasion methods, such as payload transformation.

Currently, there are two main techniques to address duplicate packet insertion. The first is stream modification, where a method is selected to interpret duplicate packets before they reach IDS, so that both the IDS and the target host see the same packet, thus eliminating ambiguity. However, a potential issue with this approach is that the standardization process may incur significant memory overhead, as it requires storing all unacknowledged packets in memory.

2.3.3 Prevention of payload transformation

To cope with payload transformation, an IDS must be capable of restoring the transformed payload. For example, when a hexadecimal encoding like “%20” is detected in a URI request, the IPS must be able to convert it back to a space. An IDS must be able to process encoding methods in different applications. Since target hosts support different encoding methods, IDS must be carefully configured to ensure that its processing method is consistent with that of the target host. Another protective method is host-based text scanning, where IDS must collaborate with the backend web server. When a request is received, the web server first decodes the URL and then returns the result to IDS for detection.

2.3.4 Prevention of shellcode transformation

There are many ways to detect polymorphic shellcode, such as using the range of return addresses to detect shellcode related to buffer overflow attacks. However, because this method requires manual configuration of the return address for each vulnerability, it is not applicable, even though it has a very high accuracy rate, with a false positive rate of 0.01% and a false negative rate of 0%.

There is also a neural network–based hybrid tool that can classify decomposed instructions. It uses the execution frequency of instructions as a feature for training and classification. Although this method works well, it cannot detect shellcode that has never been encountered before.

Detection of polymorphic shellcode at the network layer involves simulating the execution of shellcode in an emulator (e.g., a sandbox). This method treats the input stream as instructions and attempts to execute them. This detection is feasible because normally the execution of random bytes would stop very quickly (an illegal instruction is encountered), but polymorphic shellcode is only executed when the payload is fully decrypted. This detection follows the following strategy: If location-related instructions for the encrypted payload are found and there are a large number of reads and writes in a small block of memory, then it may indicate that the decryption processor is working.

3.2.1 Controller

The controller is the main part of the program and is responsible for handling everything from receiving a packet to sending it out after processing. Because of the need to implement a combination of evasion methods, a queue is designed to store packets. Initially, the queue contains all the packets that need to be processed. Whenever a packet is processed, the new packet obtained from the processing is added to the queue, while the original packet is removed from the queue. Once all evasion commands are completed, the remaining packets in the queue are the ones that have undergone evasion processing. The processing flow for an input packet is as follows:

3.2.2 Evasion methods

This system implements a total of eight TCP/IP evasion methods, namely: IP fragmentation, IP overlap, TCP segmentation, TCP segment overlap, modifying TTL, modifying MSS, modifying wscale, and modifying TCP flags. See the table below for details.

3.2.3 Configuration file

Since it is an advanced evasion system, the system supports the combination of different evasion methods. Users can configure the evasion methods to be executed, execution order, and evasion parameters in the configuration file on their own. The configuration file needs to be placed in the current directory and named AET.conf.

The command configuration rules in the configuration file are similar to commands in Linux, i.e., command + parameter. Specific commands and parameter descriptions are shown in the table below:

For example, for the following configuration file:

ip_frag 4
modify_ttl 64
modify_tcp_flags syn

It means that each packet passing through will first undergo IP fragmentation with a fragment size of 4, then the TTL will be modified to 64, and finally, the TCP options will be changed to syn.

3.2.4 SAPP interaction

The SAPP platform is a large-scale real-time stream processing platform, and because of its full protocol stack parsing capabilities, in essence, SAPP shields the system from protocol stack details. For its upper-layer services, SAPP provides an encapsulated API for invoking. Its advantage is that when implementing the evasion system, data sending and receiving can be directly managed by invoking SAPP’s interfaces, allowing the focus to remain on evasion processing.

In terms of receiving traffic, SAPP provides a variety of interfaces, including IP-layer traffic (after fragment reassembly), TCP-layer traffic (after TCP stream reconstruction), and even raw traffic at the Ethernet layer. In our system, we get the IP-layer traffic. The entry function for IP-layer traffic is as follows:

char business_ip_entry(struct streaminfo*f_stream, unsigned char routedir, int thread_seq, const void* entry_ip_pkt);

Where:

fstream

Information on the current stream

routedir

Upstream or downstream direction

thread_seq

Current thread

entry_ip_pkt

Pointer to an IP packet, which is the packet to be processed

In terms of sending packets: SAPP provides various encapsulated functions for sending packets, including sending IP packets, TCP packets, Ethernet frames, etc. Here we use the function for sending IP packets. SAPP provides the following function for sending IP packets:

MESA_sendpacket_iplayer(int thread_index,const char* ip_pkt,int buf_len,int dir);

Where:

thread_index

Current thread

ip_pkt

Pointer to the IP packet to be sent

buf_len

Length of the IP packet to be sent

dir

Upstream or downstream direction

3.3.1 IP fragmentation

IP fragmentation is one of the most common and traditional evasion methods, and its main principle is to eliminate the signatures of malicious codes by dividing IP packets into very small fragments. Since most IDSes are signature-based matching, this method can effectively evade detection by IDS. The following shows how IP fragmentation works.

Then how can we implement IP fragmentation? We need to have an understanding of the structure of IP header. Below is a diagram illustrating the structure of an IP message.

In Linux’s tcp.h, the structure of the IP message header is defined as follows:

struct ip {
    u_int ip_hl:4,  //Header Length
          ip_v:4;   //Version
    u_char ip_tos;  //Type of Service
    u_short ip_len; //Total Length of IP Packet
    u_short ip_id;  //16-bit Identification
    u_short ip_off; //Offset
    u_char ip_ttl;  //Time to Live
    u_char ip_p;    //8-bit Protocol
    u_short ip_sum; //Checksum
    struct in_addr ip_src,ip_dst; //Source and Destination Addresses
};

In the IP header, there are 4 bytes used for fragmentation, which include the 16-bit Identification, the 13-bit Offset, and 3 flag bits: DF (Don’t Fragment), MF (More Fragments), and RF. These correspond to the ip_id and ip_off fields in the IP header. The 16-bit Identification belonging to the same fragment is identical. The 13-bit Offset refers to the offset of the fragmented message relative to the original message, measured in units of 8 bytes. As for the other 3 flags, DF represents Don’t Fragment; if this bit is set to 1, the IP layer will not fragment the message. MF indicates that there are More Fragments, and all fragments except the last one have an MF of 0. RF is a reserved bit that is not used for the time being.

Therefore, we can establish the following correspondence:

The portion that requires fragmentation is the payload of the IP packet. For each newly created IP fragment, we need to populate the fields including ip_len (total IP packet length), ip_off (offset), and ip_sum (IP header checksum). The other fields should just remain the same as those in the original IP header before fragmentation.

ip_len: The total length of the IP packet, which includes both the header and the payload. Generally, the header length is 20 bytes, so ip_len would be the payload + 20. But this approach is not very safe, because in some cases, some IP packet headers also have contain IP options. So the correct way to do this is ip_len=payload+ip_hl*4. Because the IP header has a field called ip_hl that indicates the length of the IP header. It is important to multiply by 4 because ip_hl is calculated in units of 4 bytes.

ip_off: The offset of the IP packet, which refers to the offset of the IP fragment relative to the original message. The offset is measured in units of 8 bytes, so after fragmenting the original message, the offset must be divided by 8 before being filled into the IP header. It is important to note that the IP offset is the last 13 bits of ip_off. The first 3 bits of ip_off are the flag bits for the fragment. As shown in the table above, for fragments that are not the last one, both DF and MF should be set to 0. For the last fragment, DF should be set to 0, while MF should be set to 1.

ip_sum: It refers to the checksum of the IP header. The algorithm for calculating the checksum of the IP header is as follows:

1. Set the Checksum field of the IP header to zero.
2. Convert the IP header into binary.
3. Perform a one’s complement sum of the IP header in 16-bit (2-byte) units.
4. The result is the IP checksum.

Below is code for calculating the checksum:

SHORT checksum(USHORT* buffer, int size)
{
    unsigned long cksum = 0;
    while(size>1)
    {
        cksum += *buffer++;
        size -= sizeof(USHORT);
    }
    if(size)
    {
        cksum += *(UCHAR*)buffer;
    }
    cksum = (cksum>>16) + (cksum&0xffff); 
    cksum += (cksum>>16); 
    return (USHORT)(~cksum);
}

3.3.2 IP overlap

IP overlap is done on the basis of IP fragmentation and refers to the overlap between IP fragments. While IP fragmentation can evade detection, most modern IDSes typically reassemble IP fragments to restore the original message. In this case, IP fragmentation becomes ineffective, necessitating the use of IP overlap. IP overlap exploits a vulnerability arising from the inconsistency in how hosts and IDS process fragment reassembly. In general, there are two common solutions when it comes to IP overlap: either the later packet overwrites the earlier packet or the earlier packet overwrites the later packet. The following diagram graphically explains how IP overlap works:

As illustrated in the diagram, there is now a malicious code called ATTACK, which is now split into two fragments: ATTX and ACK. An IP overlap occurs at the fourth position, where the first fragment contains X and the second fragment contains A. When the host or IDS attempts to reassemble these IP fragments, ambiguity arises, as different operating systems or protocol stacks handle this situation inconsistently. If we assume that IDS processes the packets by allowing the earlier packet to overwrite the later one, then the IP packet would be reassembled as ATTXCK, which is not the original message and does not contain the attack signature, thus it is able to evade detection by IDS. After the IP fragments arrive at the target host, the IP packet will successfully be reassembled as ATTACK if the host’s reassembly method is to allow the later packet to overwrite the earlier packet. This is the original malicious code, and the target host is successfully attacked while IDS fails to detect it.

This attack actually exploits the ambiguity in processing during IP overlap. Typically, there are many hosts behind an IDS, and these hosts are unlikely to have identical operating systems and protocol stacks. Therefore, discrepancies between how IDS and hosts process packets will always exist. That is, attackers can always exploit IP overlap to carry out attacks.

The difference between IP overlap and IP fragmentation lies solely in the overlapping payload portion of IP overlap; the generation method of the rest of the IP header is exactly the same as that of IP fragmentation. Therefore, when designing the IP overlap method for the system, we only need to generate the overlapping data and then directly invoke the IP fragmentation module. For example, if an IP packet is ABCDEF with a fragment size of 4 and an overlap size of 2, and the overwrite mode is that the later packet overwrites the earlier packet, then we first transform the data portion into AB**CD**EF**. Then, by invoking the IP fragmentation module, the data will be divided into three fragments: AB**, CD**, and EF**.

3.3.3 TCP segmentation

Similar to IP fragmentation, TCP segmentation works by segmenting the TCP payload so that the original signature of the malicious code is broken up, thereby evading detection by IDS. The difference between IP fragmentation and TCP segmentation is that IP fragmentation occurs at the network layer, while TCP segmentation occurs at the transport layer. Due to the complexity of the TCP protocol, there are more factors to consider in TCP segmentation.

To segment TCP, we need to know something about TCP headers. The diagram below illustrates the structure of a TCP header.

As shown above, the basic TCP header contains 20 bytes without additional TCP options. The TCP header contains source port, destination port, seq value, ack value, header length, TCP flags, window size, TCP header checksum, urgent pointer, etc.

In Linux’s tcp.h, tcp is defined as follows:

Since TCP is a stream-based, reliable network transmission protocol, when segmenting TCP, the only values that need to be changed are the seq value and the TCP checksum, as the seq value alone can represent a TCP segment, as explained below:

struct tcphdr {
    unsigned short th_sport; //Source Port
    unsigned short th_dport; //Destination Port
    unsigned int th_seq;     //seq Value
    unsigned int th_ack;     //ack Value
    unsigned int th_off:4,   //tcp Header Length
                 th_x2:4;
    unsigned char th_flags;  //tcp Flags
    unsigned short th_win;   //Window Size
    unsigned short th_sum;   //tcp Checksum
    unsigned short th_urp;   //Urgent Pointer
};

th_seq: It is the TCP sequence number, which is a 32-bit integer. After TCP segmentation, the sequence number of the new TCP message is the sequence number before TCP segmentation plus the offset of the segment.

th_sum: It is the TCP checksum. The TCP checksum is a simple verification method used to ensure that the TCP message has not been modified. The TCP checksum is populated by the sender and verified by the receiver. If the TCP checksum is incorrect, the TCP packet will be discarded directly.

Unlike the checksum at the IP layer, the checksum at the TCP layer and the TCP checksum algorithm are as follows:

1. Set the TCP checksum field to 0.
2. Convert the entire TCP message segment to binary.
3. Perform a one’s complement sum of the binary data in 16-bit units.
4. The resulting sum is the TCP checksum.

Below is the code for calculating the TCP checksum:

void modify_tcp_checksum(struct iphdr* ip_pkt){
    int ip_hdr_len=ip_pkt->ihl*4;
    int ip_tot_len=ntohs(ip_pkt->tot_len);
    int size=ip_tot_len-ip_hdr_len;
    u_int16_t* buffer=(u_int16_t*)(((char*)ip_pkt)+ip_hdr_len);
    uint32_t saddr=ip_pkt->saddr;
    uint32_t daddr=ip_pkt->daddr;
    ((struct tcphdr*)buffer)->check=0;
    uint32_t sum;
    uint16_t *w;
    int nleft;
    sum = 0;
    nleft = size;
    w = buffer;
    while (nleft > 1){
        sum += *w++;
        --nleft;
        --nleft;
    }
    if (nleft)
        sum += *w & ntohs(0xFF00);
    sum += (saddr & 0x0000FFFF) + (saddr >> 16);
    sum += (daddr & 0x0000FFFF) + (daddr >> 16);
    sum += htons(size);
    sum += htons(IPPROTO_TCP);
    sum = (sum >> 16) + (sum & 0xFFFF);
    sum += (sum >> 16);
    sum = ~sum;
    ((struct tcphdr*)buffer)->check=(uint16_t)sum;
}

It is important to note that after modifying the information in the TCP segment, the tot_len and checksum in the IP layer must also be modified, because modifying the information in the TCP segment also affects these two fields at the IP layer.

3.3.4 TCP segment overlap

TCP segment overlap works on the same principle as IP packet overlap, with the difference being that one occurs at the network layer and the other at the transport layer. Therefore, no further details will be elaborated here.

3.3.5 Modifying TTL

TTL (time to live) refers to the maximum number of network segments that IP packets are allowed to pass through before they are discarded by a router. The unit of TTL is the hop. Each time an IP packet passes through a router, its TTL value is decremented by one. If an IP packet reaching a certain router has a TTL of 0, then that packet will be discarded. A clever evasion can be achieved by subtly modifying the TTL value.

The following diagram graphically shows how to evade IDS detection by modifying the TTL value.

As shown in the diagram above, there are 64 hops in total from the attacker to the target host. Now there is a malicious code ATTACK. If ATTACK is directly sent to the target host, it will certainly be detected by IDS. At this time, if the TTL value is modified, evasion can be cleverly achieved.

We assume that the ATTACK attack packet has a sequence number of seq=x and a time to live of TTL=64. Before sending this ATTACK attack packet, we can construct a normal TCP packet called NORMAL. This NORMAL packet will have the same sequence number of seq=x but TTL=25. Then we send this NORMAL packet first. Since it is a normal packet, it will not be detected by the IDS. However, since the TTL of this NORMAL packet is only 25 but the TTL from the sender to the target host is 64, the NORMAL packet will be discarded before it reaches the target host. At this point, we send the ATTACK packet. When the ATTACK packet reaches IDS, IDS finds that the packet with seq=x has already been detected (from the NORMAL packet), and will therefore allow it to pass through. Therefore, evasion of IDS detection can be achieved by cleverly modifying the TTL.

The key to this evasion method lies in choosing an appropriate TTL so that the IP packet can reach IDS but not the target host. To achieve this, we can continuously modify the TTL to measure the number of hops from the source to IDS.

It is worth noting that modifying the TTL is still essentially constructing a new IP packet. Therefore, after modifying the TTL, it is necessary to modify the tot_len and checksum at the IP layer, and the checksum at the TCP layer, to make them conform to the rules.

3.3.6 Modifying TCP flags

TCP Flags form one of the most important fields in the TCP header. They represent the attributes of a TCP message. A TCP message has a total of five TCP flags: SYN, ACK, FIN, PSH, and RST. Below is an explanation of each of these flags:

SYN

Synchronization, used to synchronize sequence numbers during TCP connection establishment

ACK

Acknowledgment, used to acknowledge receipt of a TCP message

FIN

Finish, used to terminate a connection at the end of the transmission

PSH

Push, used to indicate that data is being transmitted

RST

Reset flag, used to reset a TCP connection

If you want to modify the flag of a particular TCP message, you only need to set the value of the flag to 1. It is worth noting that modifying the flags of TCP is still essentially constructing a new IP packet. Therefore, after modifying the flags of the TCP, it is necessary to modify the tot_len and checksum at the IP layer, and the checksum at the TCP layer, to make them conform to the rules.

3.3.7 Modifying MSS

MSS: Maximum Segment Size, which refers to the maximum length of a TCP message segment. Before discussing MSS, it is important to understand MTU (Maximum Transport Unit), which is determined by the Ethernet frame, typically 1500. The MSS size is usually determined when TCP establishes a connection. Because both TCP and IP packet headers are 20 bytes, the MSS is typically 1460.

If you want to modify the MSS of a particular TCP message, you only need to change the MSS field corresponding to the TCP message to the desired value. It is worth noting that modifying the flags of TCP is still essentially constructing a new IP packet. Therefore, after modifying the flags of the TCP, it is necessary to modify the tot_len and checksum at the IP layer, and the checksum at the TCP layer, to make them conform to the rules.

3.3.8 Modifying wscale

wscale is a window scale factor option. Before discussing the window scale factor option, it is necessary to understand the concept of window size. In the TCP transmission process, the sliding window protocol is used to enable faster data transmission. The size of the sending window indicates the rate at which packets can be sent or received. The window scale factor represents the multiplier by which the window size is scaled. For example, if the original window size is w and the window scale factor is x, then the new window size is calculated as w*2^x. Since wscale is only one byte, the maximum value of wscale is 255.

It should be noted that the window scale factor can only be carried in SYN/ACK packets and takes effect only when enabled in both packets.

Additionally, modifying TCP’s wscale is still essentially constructing a new IP packet. Therefore, after modifying the flags of TCP, it is necessary to modify the tot_len and checksum at the IP layer, and the checksum at the TCP layer, to make them conform to the rules.

4.1.1 AET_test.c

It is the entry file for the entire system and contains three functions:

AET_init

Plugin initialization function, which is executed when the platform loads the plugin for the first time.

AET_destory

Plugin destructor function, which is executed when the plugin stops running.

business_ip_entry

The entry for the plugin to obtain traffic from the platform

The diagram below illustrates these functions:

/* Plugin initialization */
int AET_init(){
printf("AET: succeed to init\n");
    init_command_set_system(); //Initialize evasion commands
    init_command_set_user();
}

/* Plugin destructor function */
void AET_destroy(){
    printf("AET: succeed to destroy\n");
}

/* Traffic entry point */
char business_ip_entry(struct streaminfo*f_stream,unsigned char routedir,int thread_seq,const void* entry_ip_pkt){
    printf("Succeed: businiss_ip_entry called");
    exec_command_set(&send_queue); //Execute evasion commands
    return APP_STATE_GIVEME;
}

4.1.2 makefile

The makefile specifies the compilation rules and dependencies among various files in the system. Since the system will eventually run as a plugin, it needs to be compiled as a .so dynamic link library. The contents of the makefile are shown below:

cc=gcc
objects = AET_test.o module_ip_frag.o module_ip_overlap.o
AET_test.so : $(objects)
    cc -g -Wall -shared -o AET_test.so $(objects)
AET_test.o : AET_test.c
    cc -g -Wall -fPIC -c AET_test.c
module_ip_frag.o : module_ip_frag.c
    cc -g -Wall -fPIC -c module_ip_frag.c
module_ip_overlap.o : module_ip_overlap.c
    cc -g -Wall -fPIC -c module_ip_overlap.c
.PHONY : clean
clean :
    rm AET_test.so $(objects)

It should be noted that the above makefile is not complete; it is only a partial excerpt provided to illustrate the purpose of the makefile.

4.1.3 configuer.c

This file is the controller file responsible for the entire process of evasion processing, including reading the configuration file, obtaining input traffic, executing evasion commands, sending the processed packets, etc. It is the most important part of the entire program. This file contains the following main functions.

/* Initialize the system command set; i.e., the evasion commands
   supported by the system */
void init_command_set_system();

/* Initialize the user command set; i.e., read the evasion commands
   configured by the user */
void init_command_set_user();

/* Execute the evasion commands specified in the configuration
   in sequence */
void exec_command_set();

4.1.4 Utils.c

This file is a set of functional functions required by the system. It extracts common functions that are needed across various modules and places them in the Utils.c file. This file contains the following functions.

/* Copy the header of another IP packet */
void copy_ip_header();

/* Copy the header of another TCP packet */
void copy_tcp_header();

/* Modify the checksum of an IP packet */
void modify_ip_checksum ();

/* Modify the checksum of a TCP packet */
void modify_tcp_checksum();

/* Custom strcpy function */
void mystrcpy();

4.1.5 module_ip_frag.c

This is the IP fragmentation module that takes packets to be fragmented as input and stores the fragmentation results in the send_queue. Please refer to the source code for the exact program.

4.1.6 module_ip_overlap.c

This is the IP overlap module that takes packets to be processed as input and stores the results obtained after IP overlap packet processing in the send_queue. Please refer to the source code for the exact program.

4.1.7 module_tcp_segment.c

This is the TCP segmentation module that takes packets to be processed as input and stores the results obtained after TCP segmentation processing in the send_queue. Please refer to the source code for the exact program.

4.1.8 module_tcp_segment.c

This is the TCP segment overlap module that takes packets to be processed as input and stores the results obtained after TCP segment overlap processing in the send_queue. Please refer to the source code for the exact program.

4.1.9 module_modify_ttl.c

This is the module modifying TTL of IP that takes packets to be processed as input and stores the packets with modified TTL in the send_queue. Please refer to the source code for the exact program.

4.1.10 module_modify_tcp_flags.c

This is the module modifying the flags in the TCP header that takes packets to be processed as input and stores the packets with the modified flags in the TCP header in the send_queue. Please refer to the source code for the exact program.

4.1.11 module_modify_mss.c

This is the module modifying the Maximum Segment Size (MSS) in the TCP header that takes packets to be processed as input and stores the packets with modified MSS in the send_queue. Please refer to the source code for the exact program.

4.1.12 module_modify_wscale.c

This is the module modifying the window factor option of TCP that takes packets to be processed as input and stores the packets with modified wscale in the send_queue. Please refer to the source code for the exact program.

4.1.13 module_send_packet.c

This is the module sending the processed packets in send_queue. Please refer to the source code for the exact program.

4.1.14 Various header files

In order to decouple the modules and facilitate better modular design, the system has created separate header files for each corresponding module. The header files for the system are listed below:

AET_test.h

The header file of AET_test.c, which includes the definitions of the functions inside AET_test.c.

configure.h

The header file of configure.c, which includes the definitions of the functions inside configure.c.

module.h

The header file of module.c, which includes the definitions of the functions inside module.c.

utils.h

The header file of utils.c, which includes the definitions of the functions inside utils.c.