Analyze the concealed communication between the client and the server

The implementation of Trojans is based on a communication solution that is reliable and hard to be detected by the host. This article describes the implementation methods and reliability of various solutions, security has been discussed theoretically. A thorough understanding of how the client and server of a Trojan are hidden not only helps you understand the principles of network communication, but also provides effective security measures. Based on this, we have compiled this article. Next we will go to the topic.

First, we should make it clear that the trojan program running on the victim's machine is called the server, and that running on the controller is called the client. (In fact, it is hard to say who is the customer for modern Trojans, who is the service, but we still use this method ). In addition, although Windows 9x still has a huge user base, migrating Windows 9x to Windows XP is only a matter of time. Therefore, the discussion here focuses on the NT/2000/XP platform.

1. Use TCP protocol, server listening, and client connection.

This is the simplest, earliest, and most widely used communication solution. If you have used a glacier or been swept by a glacier client, you will not be unfamiliar with this. In this communication scheme, the server opens a TCP port on the host machine and waits for the client to connect. After the client passes authentication, the client can control the server. Because it is based on the TCP protocol, the communication reliability is guaranteed. However, communication security is very problematic. First, tools like fport and tcpview pro can easily find the processes listening on a port and the executable files corresponding to the processes. Second, when the client is connected to the server on a machine installed with the firewall, it is easy to cause firewall alarms.

2. Use the TCP protocol.

The client listens and connects to the server. This is the so-called reverse connection technology. To overcome the disadvantage that the server is easy to discover when listening on a port, the server no longer listens on the port, but connects to a port on which the client is listening. In this way, the server cannot be found by using the common port scheme or fport. To better paralyze the host, the client listens on ports, 80, and 23. Although the server connects to the client on a machine installed with the firewall, it still causes firewall alarms, but a careless user may ignore "application xxxxx tries to access xxx. xxx. xxx. xxx sends a warning through port 80.

This reverse connection technology solves the problem of how the server finds the client. Generally, clients use dial-up Internet access without a fixed IP address. Therefore, the Client IP address cannot be hard-coded in the server program. Of course, because the IP addresses of dial-up Internet users are generally within a fixed IP address range, the server can also scan this range, and then determine whether it is its own client based on the feedback from the host to be scanned, however, the range of IP addresses scanned by the server is too large. Another method is that the client publishes its own IP address through a third party with a fixed IP address or a fixed domain name. There are many implementation methods, for example, through a public mailbox, through a personal homepage, it depends on how much imagination you have.

3. Use the UDP protocol.

Server listening, client connection, client listening, and server connection. The method and security are similar to the TCP protocol. Note that UDP is not a reliable protocol. Therefore, you must design a reliable packet transmission protocol based on the UDP protocol.

4. Solve firewall problems.

Whether the server listens passively or actively connects to the server, firewall alarms are triggered when the server and client attempt to establish a connection. After all, there are not many users with rough experiences. Therefore, solving firewall alarms is a problem that must be solved by the server. One method is code injection. The server injects itself into a process that can communicate with the outside world legally (such as IE, ICQ, OICQ, TELNTED, FTPD, IIS, etc) or you can run it in the form of a new thread, or just modify the host process to intercept the network system call (WinSock) of the host process ). The implementation of the latter may be troublesome. If it is running in the form of a new thread, it can then passively listen or actively connect.

In either case, firewall alarms are not triggered (of course, not ). But it should be noted that if it is passive listening, such as parasitic in IE, using fport will find IE listening on a certain port, which may cause careful user attention. Therefore, the better way is to actively connect to the client in the new thread, and connect to port 80 of the client; if it is parasitic in OICQ, why not connect to port 8000 of the client. Code injection requires the server to have several privileges. Considering that normal users start NT as Admin, this should not be a problem (if the server is started as a service, no problem.