Eilam E.Reversing.Secrets of reverse engineering.2005

Listing 8.4 (continued)

The first thing you’ll notice about the this code sequence is that it is a loop, probably coded as an infinite loop (such as a while(1) statement). In its first phase, the loop repeatedly calls the InternetGetConnectedState API and sleeps for 30 seconds if the API returns FALSE. As you’ve probably guessed, the InternetGetConnectedState API checks whether the computer is currently connected to the Internet. In reality, this API only checks whether the system has a valid IP address—it doesn’t really check that it is connected to the Internet. It looks as if the program is checking for a network connection and is simply waiting for the system to become connected if it’s not already connected.

Once the connection check succeeds, the function calls another function, 004029B1, with the first parameter being a pointer to the hard-coded string g.hackarmy.tk, and with the second parameter being 0x1A0B (6667 in decimal). This function immediately calls into a function at 0040129C, which calls the gethostbyname WinSock2 function on that g.hackarmy.tk string, and proceeds to call the connect function to connect to that address. The port number is set to the value from the second parameter passed earlier: 6667. In case you’re not sure what this port number is used for, a quick trip to the IANA Web site (the Internet Assigned Numbers Authority) at www.iana.org shows that ports 6665 through 6669 are registered for IRCU, the Internet Relay Chat services.

Reversing Malware 297

0040151C JMP SHORT ZoneLock.00401535

0040151E CALL <JMP.&CRTDLL.rand>

00401523 MOV EDI,DWORD PTR SS:[EBP+8]

00401526 MOV ECX,1A

0040152B CDQ

0040152C IDIV ECX

0040152E ADD EDX,61

00401531 MOV BYTE PTR DS:[EDI+ESI],DL

00401534 INC ESI

00401535 CMP ESI,EBX

00401537 JLE SHORT ZoneLock.0040151E

00401539 MOV EAX,DWORD PTR SS:[EBP+8]

0040153C MOV BYTE PTR DS:[EAX+ESI],0

00401540 POP EDI

00401541 POP ESI

00401542 POP EBX

00401543 POP EBP

00401544 RETN

Listing 8.5 A random string-generation function.

This generates some kind of random data (with the random seed taken from the current tick counter). The buffer length is somewhat random; the default length is 5 bytes, but it can go to anywhere from 2 to 8 bytes, depending on whether rand produces a negative or positive integer. Once the primary loop is entered, the function computes a random number for each byte, calculates a modulo 0x1A (26 in decimal) for each random number, adds 0x61 (97 in decimal), and stores the result in the current byte in the buffer.

Observing the resulting buffer in OllyDbg exposes that the program is essentially producing a short random string that is made up of lowercase letters, and that the string is placed inside the caller-supplied buffer.

Notice how the modulo in Listing 8.5 is computed using the highly ineffiecient IDIV instruction. This indicates that the Trojan was compiled with some kind of Minimize Size compiler option (assuming that it was written in a high-level language). If the compiler was aiming at generating high-performance code, it would have used reciprocal multiplication to compute the modulo, which would have produced far longer, yet faster code. This is not surprising considering that the program originally came packed with UPX—the author of this program was clearly aiming at making the executable as tiny as possible. For more information on how to identify optimized division sequences and other common arithmetic operations, refer to Appendix B.

298 Chapter 8

The next sequence takes the random string and produces a string that is later sent to the IRC server. Let’s take a look at that code.

Considering that EAX contains the address of the randomly generated string, you should now know exactly what that string is for: it is the user name the backdoor will be using when connecting to the server.

The preceding sequence produced the following message, and will always produce the same message—the only difference is going to be the randomly generated name string.

NICK vsorpy USER vsorpy “x.com” “x” :x

If you look at RFC 1459, the IRC protocol specifications, you can see that this string means that a new user called vsorpy is being registered with the server. This username is going to represent this particular system in the IRC chat. The random-naming scheme was probably created in order to enable multiple clients to connect to the same server without conflicts. The architecture actually supports convenient communication with multiple infected systems at the same time.

Joining the Channel

After connecting to the IRC server, the program and the IRC server enter into a brief round of standard IRC protocol communications that is just typical protocol handshaking. The next important even takes place when the IRC server notifies the client whether or not the server has a MOTD (Message of the Day) set up. Based on this information, the program enters into the code sequence that follows, which decides how to enter into the communications channels inside which the attacker will be communicating with the Backdoor.

Reversing Malware 299

In the preceding sequence, the first sprintf will only be called if the server sends an MOTD, and the second one will be called if it doesn’t. The two commands both join the same channel: ##g##, but if the server has an MOTD the channel will be joined with the password grandad. At this point, you can start your initial communications with the program by pretending to be the attacker and joining into a channel called ##g## on the private IRC server. As soon as you join, you will know that your friend is already there because other than your own nickname you can also see an additional random-sounding name that’s connected to this channel. That’s the Backdoor program.

It’s obvious that the backdoor can be controlled by issuing commands inside of this private channel that you’ve established, but how can you know which commands are supported? If the information you’ve gathered so far could have been gathered using a simple network monitor, the list of supported commands couldn’t have been. For this, you simply must look at the command-processing code and determine which commands our program supports.

Communicating with the Backdoor

In communicating with the backdoor, the most important code area is the one that processes private-message packets, because that’s how the attacker controls the program: through private message. It is quite easy to locate the code in the program that checks for a case where the PRIVMSG command is sent from the server. This will be helpful because you’re expecting the code that follows this check to contain the actual parsing of commands from the attacker. The code that follows contains the only direct reference in the program to the

PRIVMSG string.

300 Chapter 8

After confirming that the command string is actually PRIVMSG, the program skips the colon character that denotes the beginning of the message (in the strstr call), and proceeds to compare the first character of the actual message with a character from 004050C5. When you look at that memory address in the debugger, you can see that it appears to contain a hard-coded exclamation mark (!) character. If the first character is not an exclamation mark, the program exits the function and goes back to wait for the next server transmission. So, it looks as if backdoor commands start with an exclamation mark. The next code sequence appears to perform another kind of check on your private messages. Let’s take a look.

The preceding sequence is important: It compares a string from [EBP-60], which is the nickname of the user who’s sending the current private message (essentially the attacker) with a string from a global variable. It also looks as if this is an array of strings, each element being up to 0x50 (80 in decimal)