Discussion on Hidden Communication Between Trojan client and server

A successful Trojan must implement a reliable communication solution that is not easy to be detected by the host. The following describes the implementation methods and reliability of various solutions in my knowledge, security is discussed. There must be many mistakes in this article. You are welcome to point out that you may wish to write articles in this area with high Trojan development experience, which can be improved by hackers or common users. I will not talk much about any warnings. It is irrelevant to me to read articles and do bad things. Next, 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 TCP protocol, client listening, and server connection. 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 can hardly 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 on the machine where the firewall is installed still needs to trigger firewall alarms when connecting to the client, 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 an IP address 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. 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 the firewall problem. Whether the server listens passively or actively connects to the server, the firewall generates an alarm 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, ).

1 2 Next Page

[Content navigation]
Page 1st: Discussion on hidden communication methods between the trojan client and the server	Page 2nd: Discussion on hidden communication methods between the trojan client and the server