This section examines the packet format of the FTP protocol and demonstrates its implementation with code. To start, we need to perform an FTP server setup on our machine. I installed QuickFTP Server on my Mac, which I found as a suitable choice. I configured the connection port to 2100 and set up a username and password. This allows us to analyze the protocol packet format through packet capture, as shown below:
Then open Wireshark, enter ‘tcp.port==2100’ in the filter conditions, and start monitoring. This will allow you to capture the relevant FTP packets. Next, I used an FTP client from my phone to connect to the server and logged in using the set username and password. The packet capture results on Wireshark are as follows:
Note that the first three are the three-way handshake of the TCP connection, the fourth is some parameters for TCP data transfer communication that can be ignored. The real FTP protocol data is in the fifth packet sent by the server to the client. Click to view the details below:
We note its data part, which is the specific content of the FTP protocol. It begins with the reply code 220. In the previous section, we described the role of the three-digit reply code, which represents the server is ready to receive the client’s request. The following string is the server’s textual explanation of the reply code, which is not considered in protocol implementation. It is important to note that all packets containing protocol data correspond to [PSH, ACK], and if it only contains [ACK], it is just a response to the last received packet. So click on the next [PSH, ACK] to view the next packet content of the FTP protocol. Thus, we click to view the next protocol packet containing FTP data:
The data starts with the string “USER”, which indicates that the client submits the username to the server, and the username is represented by the plaintext string “chenyi”. Then continue to see the next [PSH, ACK] packet, its content is as follows:
The data starts with 331, which was explained in previous sections. It represents that the client’s request is accepted, and the request is being processed, and further steps are needed. It indicates that the username is correct but a password must still be submitted. So we continue to check the next [PSH, ACK] packet sent by the client to the server. Its content is as follows:
In the data part, it starts with the string “PASS”, which is an operational command, indicating that the client is providing a password to the server, and you can clearly see the password is 1111. Continue to see the server’s response to the client’s [PSH, ACK] data packet:
The data part starts with the reply code 230, which indicates the user has logged in successfully, and all operations will proceed. Then look at the next [PSH, ACK] packet sent from the client to the server, you can see the data content is only the string “PWD”, this is the client requesting the current directory from the server. Thus, check the server’s returned [PSH, ACK] data packet:
The response data first shows the reply code 257, which indicates the path name is established, followed by “\\” indicating the current root directory. Continue to see the next [PSH, ACK] packet sent by the client to the server:
The response data only includes the command “FEAT”, which asks the server to list the contents of the current directory. Next, look at the server’s response [PSH, ACK]:
The data contains the reply code 211, which indicates that the server will return content containing system information. Continue to see the client’s response [PSH, ACK] packet:
The data sent by the client to the server is “PASV”, indicating that the client will receive server data in passive mode, meaning allowing the server to wait for the client to initiate the data request. Thus, we look at the next [PSH, ACK] response from the server:
The data starts with 227, which is the response to the previous “PASV” request, indicating that transmission enters passive mode. It is particularly important to note that the data contains the IP and port number used for data transmission, with the IP being 192.168.2.243, which is the server address. The following two-byte data is used to calculate the data transfer port, calculated as 17*256+222, resulting in 4574. This means the client must connect to the server’s port 4574 to obtain data. The client will use this port number to access data content in the next step. Let’s continue checking the [PSH, ACK] packet sent by the client:
The data content is “TYPE A”, which sets the data transfer format to the server. Previously, we mentioned that FTP has mainly two data transfer formats, one is the ASCII-based text mode, and the other is the binary mode. This command indicates that data transmission uses ASCII text mode. Let’s see the next server-returned [PSH, ACK]:
The response code is 220, indicating the command request is completed. Meanwhile, in the explanation string, it indicates that data transmission will use the ASCII mode. Continue to check the next [PSH, ACK] from the client to the server:
The client sends a request command “LIST” to the server, which asks to enumerate file information in the current path, so let’s continue checking the server’s returned [PSH, ACK]:
The server’s reply code is 150, indicating that the request is accepted and the data channel is open. At this point, we need to monitor port 4574 to obtain data communication between the client and server, so in Wireshark, change the filter condition to ‘tcp.port==4574′. At this time, you can see the three-way handshake of both parties’ TCP, followed by information pushed by the server to the client:
The content shows the file information in the current path, adopting the Unix file listing format. The first byte indicates the file type, with ‘-‘ indicating a regular file, ‘s’ indicating socket, etc. Next, rw——- represents the file’s permissions, where the first three characters indicate user permissions, the next three indicate group permissions, and the last indicate other user permissions, with ‘-‘ indicating no operation allowed. The next is the number representing the link count. The following string represents the file’s owner and associated group, followed by the file size in bytes, modification time, and filename. For specific content, you can search.
After the data content transmission ends, the TCP connection is closed, and we return to the command transmission channel. You can see the server sends the following [PSH, ACK] data packet:
The reply code is 226, which means the data transmission connection is closed. From its accompanying text information, it indicates that the data transfer is complete.
The above is a packet analysis of the FTP protocol.