View the concept of Xixiang plan from the Linux protocol stack code and RFC

The Xixiang program was finally completed. Since the kernel module was unable to be downloaded, I had to write it myself. After understanding the principle of the Xixiang program, writing this module is not very troublesome (in fact, it is not simply to write the module, but to directly modify the kernel protocol stack Code). let's first talk about the principle and then talk about the kernel modification suggestions.
Sequence. Xixiang plan

The Xixiang plan is a method to cheat GFW named after historical novels, which has many implementations. To tell the truth, I really don't know what is different from the guy in the West Chamber. I have time to take a look. The Xixiang plan is nothing more than a solution that leverages some of the weaknesses of the firewall and passes through the sea. Essentially, the author uses a deep understanding of the TCP protocol specifications and the firewall itself to develop this scheme.
The specific technical details refer to the three-way handshake of TCP, where the server executes the plan based on the particularity of the server's processing of the syn-cached ed status. In the tcp syn-forwarded ed status, the server wants to receive the ACK from the client. However, the client does not send the ACK as scheduled, instead, a two-phase custom message is sent. The first stage is to send a message with the FIN flag and without the ACK flag; the second stage is to send an ACK message. In this way, the two phases successfully fool the firewall and trick the server into doing what the client wants it to do.
I. How to do it from the Linux source code

In addition to the RFC, the easiest way to get started is the Linux source code. The tcp_rcv_state_process function can see why the Xixiang plan is successful. I don't know what the firewall has done for the moment. The so-called "fail" means that the TCP connection of the server has not been broken.
In the implementation of the Linux protocol stack, the tcp_rcv_state_process function is responsible for processing the state machine of the TCP connection/release. Due to the particularity of the state transition at the beginning of the connection (three-way handshake, it is recommended that we focus on three handshakes instead of the establish State. In the establish State, most seemingly abnormal packets can be repaired through the mechanism of TCP, but not during the three handshakes, because the TCB facilities of TCP control blocks are being built, so many mechanisms are not available, so if you want to toss about TCP in this status, let's take a look at tcp_rcv_state_process:

Int tcp_rcv_state_process (struct sock * SK, struct sk_buff * SKB, struct tcphdr * th, unsigned Len) {struct tcp_opt * TP = tcp_sk (SK); int queued = 0; TP-> saw_tstamp = 0; Switch (SK-> sk_state) {Case tcp_close :... case tcp_listen :... case tcp_syn_sent :...}... /* Step 1: Check Sequence Number */If (! Tcp_sequence (TP, tcp_skb_cb (SKB)-> seq, tcp_skb_cb (SKB)-> end_seq) {If (! Th-> RST) tcp_send_dupack (SK, SKB); goto discard;}/* Step 2: Check rst bit */If (Th-> RST) {tcp_reset (SK ); goto discard ;}... /* Step 5: Check the ACK field */If (Th-> ACK) {// This is the key point int Acceptable = tcp_ack (SK, SKB, flag_slowpath ); switch (SK-> sk_state) {Case tcp_syn_recv: If (acceptable ){...} else {// If the ACK number is incorrect and 1 is returned, auto-Reset return 1;} break; Case tcp_fin_wait1 :... case tcp_closing :.... Case tcp_last_ack:...} else // if there is no ACK mark, the message is discarded. Whether the message contains fin is irrelevant to the server, just to cheat the firewall. Goto discard;/* Step 6: Check the URG bit */tcp_urg (SK, SKB, th);/* Step 7: process the segment text */switch (SK-> sk_state ){...} /* tcp_data cocould move socket to time-wait */If (SK-> sk_state! = Tcp_close) {tcp_data_snd_check (SK); tcp_ack_snd_check (SK);} If (! Queued) {discard: _ kfree_skb (SKB);} // If 0 is returned, it is normal. If 1 is returned, auto-Reset is sent, this reset does not operate on local connections, but silently sends return 0 in the reverse direction of bad packets ;}

Do not explain the above Code more. From the code logic of this function, we can clearly see what the client needs to do, that is, sending two bad packets before the last three-way handshake.
2. Understand the first stage of the Xixiang plan from the TCP State Machine

Let's take a look at the TCP state machine. This figure is from RFC. Other sources are floating clouds:

It can be seen that there is no explicit "receive fin" action in the syn-forwarded ed state (only the application calls the close and then sends the fin action), although this involves TCP details, but it can still be used. In most implementations, the unspecified behavior is simply "discard the package ". But if you really want the server to discard this fin package, you must make it not contain ack. This is because the rfc tcp state machine says that as long as you receive ACK, the server will enter the establish State, this will cause the second-stage failure of the Xixiang plan (the second stage is to cause the server to send a reset, but in the establish State, this Reset is not easy to cause ). Therefore, we only need to send an ack-free FIN packet after the client sends the SYN Packet and receives the server's syn-ack. When the packet passes through the wall, the wall will think that this is a termination package from the client to the server.
Iii. Understand the second stage of the Xixiang plan from RFC

Since the self-built fin has cheated the firewall from the client to the server, the next step is the second stage of the task, and the firewall is deceived from the server to the client. The server is expected to adopt a normal and elegant fin method, which is not feasible, because the connection is broken, so an exception is required, that is, the server sends a reset packet, the RFC specifies a variety of methods for triggering reset. The Xixiang plan obviously adopts the following method (You Need To Know why sending a reset will not cause the connection to be released on your own side, please go on to the next step ):
RFC 793 [page 35]
Reset generation
2. if the connection is in any non-Synchronized State (Listen, SYN-SENT, SYN-RECEIVED), and the incoming segment acknowledges something not yet sent (the segment carries an unacceptable ACK ), or if an incoming segment has a security level or compartment which does not exactly match the level and compartment requested for the connection, a reset is sent.

So how can we know that the reset packets sent by the server can reach the client smoothly and the server does not release the connection? If the RFC is really difficult to understand, as a programmer, it will be much more comfortable to look at the code. We know that the Linux protocol stack source code is a good choice, which implements the vast majority of RFC recommendations. In Linux, reset packets are divided into auto-reset and active-reset packets. Auto-Reset only constructs a TCP reply packet with the RST bit based on the packets that cause the reset, it is not associated with any socket. After a reset packet is sent, it does not perform any operations on the local connection. In this way, the reset packet has an assumption that, that is, it will cause the generation of "bad packets" of auto-reset to two points:
1. remote Host "abnormal behavior" or someone has not followed the TCP specification, for example, received a SYN when establish status; 2. the local end does not have a TCP connection that can be associated with the bad packet. For example, a non-existent or unopened port is connected.

For Active-reset, the message is sent when a bad message and a predictable event with established connections can be sent. For example, the retransmission timer times out continuously more than a certain number of times, after such an active-Reset is sent, the local connection also disappears. In Linux, auto-Reset is executed by tcp_v4_send_reset. I think its annotations are clear:

/* *    This routine will send an RST to the other tcp. * *    Someone asks: why I NEVER use socket parameters (TOS, TTL etc.) *              for reset. *    Answer: if a packet caused RST, it is not for a socket *        existing in our system, if it is matched to a socket, *        it is just duplicate segment or bug in other side's TCP. *        So that we build reply only basing on parameters *        arrived with segment. *    Exception: precedence violation. We do not implement it in any case. */static void tcp_v4_send_reset(struct sk_buff *skb){    ...}

Because of this auto-Reset Mechanism (which is also the meaning of RFC), The Xixiang plan was successful. The Xixiang plan used a bad message to make the server generate an auto-Reset message, when the reset packet passes through the firewall, it will be considered as the "termination" message initiated by the server to the client. However, the client can ignore this message... in this way, the other half is successful.
We cannot use the active-Reset packet because the reset packet is associated with a connection. once sent, the TCP connection record (TCB) of the local end will be released at the same time ). The two phases are all completed. The interaction diagram is as follows:

4. A little extension

In summary, can we use a fin package to trigger the server to send a reset at the same time? The answer is yes, that is, after receiving the server's syn-ack, send a message with a fin and ACK serial number error, because: 1. the syn-forwarded ed status does not check the received FIN flag, so it only deceives the wall at no cost; 2. because the ACK serial number is incorrect, the server sends an auto-reset to cheat the wall in the opposite direction.
5. Two Books

Finally, if you think the RFC is not good, and the Linux source code is complicated, we recommend a simple protocol stack implementation, that is, the xinu system's protocol stack implementation, and the code is rarely clear. It is also used in the well-known explanation of "using TCP/IP for Internet connection (Volume 2)". After reading "using TCP/IP for Internet connection (Volume 2) compared with TCP/IP xiangjie (Volume 2), it will give you more understanding of the Protocol and will not get lost in the vast BSD code. In fact, they are the same thing.
After reading "using TCP/IP for Internet connection (Volume 2)", your idea will be refreshed. The xinu kernel is completely a microkernel design, and almost all modules are an independent process, communication by IPC, of course, the protocol stack is no exception. The xinu IP layer is completed by an IP process. The IP process is designed to be uniform, so that you can easily understand the processing of the IP layer. In particular, it abstracts the local interface, in this way, IP data packets sent locally to the IP layer and packets received from the physical network adapter can be processed in a more unified manner. If netfilter is implemented on xinu, for the filter table, xinu cut down the input and output chains at once, because xinu does not distinguish where the datagram comes from. For xinu IP processes, they all come from a "interface", as shown below:

Another highlight is the design of its timer-list, which is filled with relative time and sorted by relative time of the distance header. It is efficient to manage. You only need to modify the header, it also greatly increases the cache hit rate. Moreover, the implementation of the xinu TCP state machine is completely different from that of Linux.
6. kernel protocol stack Modification

Modify the following code snippet of tcp_rcv_state_process:

case TCP_SYN_SENT:...

Send two bad packets before tcp_rcv_synsent_state_process in the tcp_rcv_synsent_state_process function. We have analyzed how to construct these two bad packets.