Honeynet Project Reverse Challenge

Matt Messier, Bob Fleck, John Viega

Secure Software, Inc.

Identify and explain the purpose of the binary.

The binary is a distributed denial of service (DDoS) daemon to be installed on compromised Linux hosts. The daemon is controlled by commands received from a client program. It appears to be similar in design and function to the Tribe family of DDoS tools.

This particular binary is statically linked against Linux libc 5.3.12, but the code appears to be portable to a wider range of systems.

Identify and explain the different features of the binary. What are its capabilities?

Communication between the control client (a separate binary) and the daemon:

The control packets contain command codes which instruct the daemon which action it should take. The actions implemented in the daemon are: It can produce several types of network floods to deny service to targets: The daemon uses several processes: The binary uses a network data encoding process. Identify the encoding process and develop a decoder for it.

Network data is encoded using this function.

void encode_output(int len, char *src, char *dst)
    int i;

    dst[0] = '\0';
    sprintf(dst, "%c", src[0] + 0x17);
    for (i = 1;  i < len;  i++)
        dst[i] = src[i] + dst[i - 1] + 0x17;
Decoding is accomplished with this function.
void decode_input(int len, char *src, char *dst)
    int     c, i;
    char    *buf;

    buf = alloca((len + 3) & ~4);
    dst[0] = '\0';
    if (len < 1)

    for (i = len - 1;  i >= 0;  i--)
        c = (i ? src[i] - src[i - 1] : src[0]) - 0x17;
        while (c < 0)
            c += 0x100;

        memcpy(buf, dst, len);
        dst[0] = (char)c;
        memcpy(&(dst[1]), buf, len - 1);
        sprintf(dst, "%c%s", c, buf);
This encoding and decoding is performed on the IP payload only. Exactly how these functions are called can be seen in the included complete source.

Identify one method of detecting this network traffic using a method that is not just specific to this situation, but other ones as well.

This program communicates with the control client using an IP protocol-type that is not commonly used (NVP-II). This network traffic is much easier to detect than some other DDoS tools, which hide command traffic in the headers and payloads of ICMP or UDP packets.

Establishing filters to identify traffic consisting of protocols that are not in use on the monitored network will detect this tool. Other tools that use uncommon protocols can be detected this way as well. Any traffic that isn't of a protocol actually in use should raise suspicion.

Protocol analysis, supported by some IDS tools, can be used to inspect the content of protocols that are allowed through firewalls for malicious or improperly formatted contents. Protocol analysis systems currently focus on widely used protocols such as HTTP and FTP. But, if a protocol analysis module were developed for NVP-II it would likely detect the command packets this tool creates, as their contents are not formatted correctly for the NVP-II protocol.

Identify and explain any techniques in the binary that protect it from being analyzed or reverse engineered.

There is little done in this program to prevent analysis or reverse engineering. The primary protection implemented is the encoding of command and response packets. Additionally, the interactive shell is protected with a password that is encoded in the binary using an extremely simple caesar cipher.

If detection of the binary is considered part of analysis there is an attempt at hiding. The binary changes its name to "[mingetty]" to hide itself in process listings.

Identify two tools in the past that have demonstrated similar functionality.

There are strong resemblances between this tool and the Tribe Flood Network (TFN) and Tribe Flood Network 2000 (TFN2K) tools.

The program has a code structure very similar to TFN. The handling of processes and the main command interpretation code bear heavy resemblances.

While the program is structured similar to TFN, the contents of the command packets are closer to those of TFN2K. TFN passes entire strings to indicate commands, while TFN2K and this tool use binary command codes followed by parameters. This tool is not as advanced as TFN2K in its protection of the command packets however. TFN2K uses a preshared key to Blowfish encrypt the packet; this binary only obfuscates the command packet.

This tool also implements more types of attacks than TFN and TFN2K; it includes the two DNS based floods.

What kind of information can be derived about the person who developed this tool? For example, what is their skill level?

The creation of this tool seems to have required only moderate programming skill. It reuses sections of code and general structure from other tools, particularly TFN, but does contain modified and rearranged functionality. There are many programming mistakes, from misimplementation of algorithms to memory leaks and process coordination bugs. In general, this binary appears to be a hacked together mix of code from previous tools.

What advancements in tools with similar purposes can we expect in the future?

This tool is based on older techniques (circa. 2000) and does not use current methods for control channels. Many newer tools use IRC as a command channel. It is likely that Windows will be more frequently targeted now that XP is being deployed. Older tools targeted Linux systems in particular because of the difficulty of getting raw socket access on Windows. As Windows becomes a bigger target, we anticipate that more worms will be developed that contain better DoS implementations.