Reverse Engineering Win32 Trojans on Linux

slackrootcyc writes "A post (and previous article) give a detailed examination of the reversing process, using a trojan found in the wild. Later on in the story it discusses some techniques for reversing Windows-native code entirely under Linux."

Comments

Win32 Trojans...

[JessLeah]

...the condoms that bluescreen.

Where do you want to Put It Today?(TM)

The great thing about Security Focus...

[Anonymous Coward]

They're completely unbiased. New IIS hole? Here's the story. New Apache hole? Here's the story. All objective, no "M$ suX0rs!!!1".

Re:The great thing about Security Focus...

[PhysicsScholar]

The not-so-great thing about Security Focus is that their Web servers can't handle 10,000 hits in 10 minutes.

So, here's the text of the article just in case:


Reverse Engineering Hostile Code
by Jon Stewart
last updated October 23, 2002

Computer criminals are always ready and waiting to compromise a weakness in a system. When they do, they usually leave programs on the system to maintain their control. We refer to these programs as "Trojans" after the story of the ancient Greek Trojan horse. Often these programs are custom compiled and not widely distributed. Because of this, anti-virus software will not often detect their presence. It also means information about what any particular custom Trojan does is also not generally available, so a custom analysis of the code is necessary to determine the extent of the threat and to pinpoint the origin of the attack if possible.

This article outlines the process of reverse engineering hostile code. By "hostile code", we mean any process running on a system that is not authorized by the system administrator, such as Trojans, viruses, or spyware. This article is not intended to be an in-depth tutorial, but rather a description of the tools and steps involved. Armed with this knowledge, even someone who is not an expert at assembly language programming should be able to look at the internals of a hostile program and determine what it is doing, at least on a surface level.

Tools Required

As with most types of engineering, you'll need some tools. We'll cover tools native to both Unix and Windows. While Unix is the ideal platform to perform the initial reverse engineering process, you can still make do on Windows, especially if you install tools such as Cygwin, a Unix environment that runs on Win32 platforms. Most of these commands are also available for Windows when running Cygwin. However, when you get to the decompile/disassemble/debug steps ahead, going the Windows route will cost a lot of money, whereas the Unix solutions are all free. Be sure to weigh the costs of working on Windows versus the benefits before making it your reverse-engineering platform of choice.

Some useful commands are:

dd - byte-for-byte copying of raw devices. Useful to perform analysis on a compromised system's hard drive without affecting the integrity of evidence of the intrusion.
file - tries to identify the type of a file based on content
strings - outputs the readable strings from an executable program.
hexedit - allows you to read and edit binary files
md5sum - creates a unique checksum for a file for comparison
diff - outputs differences between files
lsof - shows all open files and sockets by process
tcpdump - network packet sniffer
grep - search for strings within a file
Compressed Executables

Trojans are often compressed with an executable packer. This not only makes the code more compact, it also prevents much of the internal string data from being viewed by the strings or hexedit commands. The most commonly used executable packer is UPX, which can compress Linux or Windows binaries. There are several other packers available, but they are typically Windows-only. Fortunately, UPX is one of the few that also provide a manual decompression to restore the original file. This prevents us from having to use advanced techniques to decompress the file into its original format.

In an ordinary executable, running the "strings" command or examining the Trojan with hexedit should show many readable and complete strings in the file. If you only see random binary characters or mostly truncated and scattered pieces of text, the executable has likely been packed. Using grep or hexedit, you should be able to find the string "UPX" somewhere in the file if it was packed by UPX. Otherwise you may be dealing with one of the many other executable packers. Dealing with these other formats is beyond the scope of this article, but you can find resources to help work with these files.

Decompiling

Occasionally you will get lucky and find that the Trojan was written in an interpreted or semi-interpreted language such as Visual Basic, Java or even compiled Perl. There are tools available to decompile these languages to varying degrees.

Visual Basic - There is a decompiler floating around the Net for VB version 3. For newer versions, there are no decompilers known, but you can use a tool such as Compuware's SmartCheck to trace calls in the program. While its output is not a source code listing, you can see just about everything the program is doing internally.
Java - There is the excellent decompiler jad, which decompiles to a complete source code listing which can be recompiled again. Several other java decompilers are also known to exist.
Perl - Perl programs compiled into Windows executables can be reduced to their bare script using exe2perl.
Disassembly

If the Trojan was written in a true compiled language, you'll have to bite the bullet and disassemble the code into assembly language. For Unix executables, objdump is the way to go. For Windows executables, you'll want IDA Pro or W32dasm There is a free version of IDA that is just as powerful as IDA Pro but has a console-based interface. These programs will disassemble your code, then match up strings in the data segment to where they are used in the program, as well as show you separation between subroutines. They will attempt to show you Windows API calls by name instead of by offset. This kind of output is known as a deadlisting, and can give you a good idea of what the program is doing internally. The GNU objdump program does not provide such useful features, but there is a perl-based wrapper for objdump called dasm, which will give you much of the same functionality as the Windows disassemblers.

Debuggers

While a deadlisting can be quite valuable, you will still want to use a debugger to step through the program code, especially if the Trojan is communicating via network sockets. This gives you access to the memory and temporary variables stored in the program, as well as all data it is sending and receiving from socket communications. On Unix, gdb is the debugger of choice. It has a long history on Unix, is well documented, and best of all, is available free of charge. Under Windows, the choices are far more varied, but most tutorials on reverse engineering under Win32 assume you are using SoftICE. It does cost a fair amount of money, but is worth getting if you can afford it.

Preparing to Debug

You must take precautions when running hostile code, even under a debugger. You should never debug a Trojan on a production network. Ideally, you should set up a lab network, as shown in figure 1.

Figure 1: A typical debugging network

The debug system should have a clean install of whatever OS the Trojan is intended for, with a second box acting as a firewall. A third system on the network allows you to emulate services and capture the network traffic generated by the Trojan. Capturing this traffic can be invaluable in tracing the source of the infection. Ensure that you firewall all outbound connections, allowing only the Trojan's control connection through. If you don't want the master controller to know your lab network is running the Trojan, you can set up services to mimic the resources the Trojan needs, such as an IRC or FTP/TFTP server.

Stepping Through the Code

Now that we have constructed a proper quarantined lab environment, we can begin debugging the code. Using the deadlisting, we look for key functions in the program, such as Winsock and file I/O calls. The debugger allows us to set breakpoints in the program based on offset values, so we can interrupt the flow of the program and examine the program memory and CPU registers at that point. The remainder of this article will look at an example of how such a debugging session might look on an x86 Linux platform.

Running the Debugger

We want to know how the Trojan communicates with its controller. Often, sniffing the network traffic will be sufficient. However, many newer Trojans are incorporating encryption into their network traffic, making network sniffing a lost cause. However, with some cleverness we can grab the messages from memory before they are encrypted. By setting a breakpoint on the "send" socket library call, we can interrupt the code just prior to the packet being sent. Then, by getting a stack trace, we can see where we are in the program. For example, the Trojan source code might look something like: /* encrypt output to master */
elen = encrypt(crypted,buf,len); /* write crypted output to socket */
send(s, crypted, elen, 0);

Examining the compiled Trojan in gdb might give us the following output [note that the bolded statement represent the author's comments on the output]:

[test@debugger test]$ gdb ./Trojan
GNU gdb 5.2.1-2mdk (Mandrake Linux)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of
it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty"
for details.
This GDB was configured as "i586-mandrake-linux-gnu"...
(no debugging symbols found)...
(gdb) set disassembly-flavor intel [Switch syntax output from AT&T]
(gdb) b send [Set a breakpoint on the "send" library call]
Breakpoint 1 at 0x400f5c10
(gdb) run
Starting program: /home/test/Trojan

Breakpoint 1, 0x400f5c10 in send () [We hit a breakpoint]
(gdb) where [Do a stack trace to see where we are at in the program]
#0 0x400f5c10 in send () from /lib/i686/libc.so.6
#1 0x080487fa in socket ()
#2 0x40040082 in __libc_start_main () from /lib/i686/libc.so.6

The above output from the "where" command in gdb shows us the offset each subroutine will return to after execution. Since we know that the "send" call was right after our encrypt call, we need only to examine the previous subroutine, which encompasses the return offset 0x080487fa. We are interested in the assembly language code just prior to this offset. Using gdb, we can disassemble the code at this point.

(gdb) disas 0x080487d2 0x080487fa
Dump of assembler code from 0x80487d2 to 0x80487fa:
0x80487d2 : call 0x8048804
0x80487d7 : add esp,0x10
0x80487da : mov DWORD PTR [ebp-836],eax
0x80487e0 : push 0x0
0x80487e2 : push DWORD PTR [ebp-836]
0x80487e8 : lea eax,[ebp-824]
0x80487ee : push eax
0x80487ef : push DWORD PTR [ebp-828]
0x80487f5 : call 0x8048534
End of assembler dump.

We see that just prior to the call to "send", there was a call to 0x8048804 . In reality, this is our "encrypt" subroutine. When programs are stripped of their symbols, gdb is often confused about where subroutines begin and end, so it continues the name of the last one it recognizes for all following subroutines, often the previous dynamic library call. In this case, it is mislabeled as being part of the "socket" function.

To examine the contents of the unencrypted packet, we need only know how the "call" instruction works. The arguments to our subroutine were pushed onto the "stack", a place where temporary data and return offsets are stored. We can access the contents of the variables by setting a breakpoint on the call and then using an offset from an internal CPU register known as the stack pointer, ESP. ESP+4 will be a pointer to the first argument, ESP+8 will be a pointer to the second argument, ESP+12 will be a pointer to the third argument, and so forth. Just keep poking at the stack until something useful comes up. In this case, the useful information (the plaintext data) is in the second argument to "encrypt". Let's set a breakpoint at the encrypt call, and examine the stack [Again, the bolded statement represent the author's comments on the output.]

(gdb) b * 0x80487d2 [Set a breakpoint on the "encrypt" call]
Breakpoint 2 at 0x80487d2
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /home/test/Trojan
(no debugging symbols found)...
Breakpoint 2, 0x080487d2 in socket ()
(gdb) x/x $esp+8 [Get the offset of the second argument ESP+8]
0xbffff5e4: 0x0806fe20
(gdb) x/fs 0x0806fe20 [Examine the contents of the memory at 0x0806fe20]
0x806fe20: "root pts/0 Oct 11 14:22\n"

From this output we can see that the Trojan is reporting back on who is currently logged on to the system. Of course, it could send any kind of data; network packet captures, keystroke logs, etc. Fortunately, we have our network set up so this traffic will be redirected to the sniffer host instead.

Conclusion

The Trojan above is not real. Had it been an actual Trojan, we might have followed additional courses of action. Often times a Trojan will use established channels such as IRC to reach its master. We can take advantage of this fact, and use it to track down the source of the attack, even gaining control of the entire network of Trojaned hosts if the Trojan writer has been careless. If the Trojan uses FTP to update itself, you might find additional code on the FTP server and possibly clues to the identity of the Trojan writer.

Although we've only scratched the surface of reverse engineering, you should be able to take the basic information above and put it to work. Read the documentation for your debugger; you'll be surprised at how powerful it can be, and how much it can tell you; even if you're not the best at reading assembly code. If it seems overwhelming at first, don't give up hope. The payoff can be quite gratifying. During one reverse-engineering session the author of this article found the real name of the Trojan author unintentionally embedded in the program's source code (hint: don't write Trojans in VB when logged in to your NT workstation at work). With a quick trip to Google the author's email address and picture was available, posted to a VB discussion site. One "whois" later and his home address and phone number was found. Somewhere in Brazil, a Trojan writer slaps his forehead and says (in Portuguese), Doh!

Violation of the DMCA!!

[SuperDuG]

hehehehe wonder if Symantec and Network Associates will sue for having their code reverse engineered ...

wait a minute anti-virus software makers don't make virii, what was I thinking

Uh Oh...

[nothing safe]

*GASP* Does this mean that the cat is out of the bag with that top secret trojan known as 'Sub7'?

On Mac OS-X

[Anonymous Coward]

I know a Windows underground group which is converting M$ Windows trojans to Mac OS-X. They just think it's cool - that's their motivation. I don't see what's so cool in it..

Make Win32 Trojans Open Source

[Slashdotess]

This is why we should be coding everything in Open Source. The fact being is, in this highly dynamic internet society today Trojans can hide their code to prevent security professionals from doing their job. When we finally open source these trojans, our software will become more secure because programmers from around the world can work on making the trojans and the programs the effect faster, better, and more secure.

Currently, trojans are badly written because of their inherent proprietary nature. Using something like sourceforge a multitude of coders can be simultaneously working on different parts of a trojan while the open source community can review, debug and test the code for infectioness effectiveness.

Only when we make Trojans open source will we realize that our computer controlled Oil tankers accross the world will be safe from Da Vinci.

Too bad no one here cares about ASM...

[SexyKellyOsbourne]

This is some pretty neat stuff: the author details how to find a needle in a haystack for a virus establishing a TCP connection from nothing more than raw dissassembly, and then how to use breakpoints in the WINE program to get gdb to work with it.

Though you can do that with a simple netstat, it opens up ways to find everything else about the trojan, too, without the risk of raping your native environment Windows system.

Too bad most nu-geek slashdotters would rather hear about someone putting a neon rope light inside their computer case.

Magic Patch

[taviso]

I made this little patch a few days ago to /etc/magic, it can detect when an executable has been packed with upx (works against latest 1.90 release)

--- magic.orig 2002-11-16 20:43:02.000000000 +0000
+++ magic 2002-11-13 12:54:09.000000000 +0000
@@ -1793,6 +1793,7 @@
>>16 leshort 1 relocatable,
>>16 leshort 2 executable,
>>16 leshort 3 shared object,
+>>0x79 string UPX UPX compressed,
# Core handling from Peter Tobias <tobias@server.et-inf.fho-emden.de>
# corrections by Christian 'Dr. Disk' Hechelmann <drdisk@ds9.au.s.shuttle.de>
>>16 leshort 4 core file

example output:
$ file ./counter
./counter: ELF 32-bit LSB executable, UPX compressed, Intel 80386, version 1 (Linux), statically linked, stripped

Trojan Writers

[Dakisha]

And in further news, trojan writers worldwide file a DMCA suit against linux users for circumventing there security and reverse compiling there intelectual property ;)

Reverse engineering with WINE

[jeroenb]

I've used WINE quite extensively and I would say if you want to reverse engineer a piece of Win32 code WINE might be the best way to do it on Linux. On the other hand, so much is either not implemented or only implemented halfway, I wouldn't really consider my WINE-based findings to be an objective assessment of what a piece of code would do once actually run on a system based on an original version of Windows.

I don't really see why you'd go through all the trouble of using Linux to reverse a Win32-trojan. The only argument the author of the two linked articles gives is that all related development tools on Linux/Unix are free. However, if you just want to poke around some code without producing optimized binaries, you can get cheap versions of MS Developer Studio (so-called "Learning Editions") as well.

I mean, this kind of stuff is complicated enough without the possible hassle of having your environment messed up because of some incomplete emulator.

Re:Reverse engineering with WINE

[IamTheRealMike]

Actually the missing parts of Wine are now mostly common controls or desktop components. For debugging low level stuff, Wine is invaluable as it can show you exactly what API calls a program is making, with parameters, filtered according to type.

Some useful RE links...

[Anonymous Coward]

Those wishing to learn more about Reverse Engineering software may find the following pages useful:

Fravia's pages - A huge, sprawling resource of RE information. Chances are, any info you need is in here somewhere. It's just a matter of finding it...

The Art of Assembly and other essential ASM programming links. If you want to learn RE, sooner or later you're going to have to learn assembly. Get to it.

Mammon's Tales to his Grandson and other useful RE classics by a G.O.M. of the genre. Oh, and an older mirror, possibly with extra/different stuff on it.

Google's directory listing for Disassemblers, which you'll be wanting at least one of...
...and the listing for Testing tools, which may come in handy.

Finally, Compuware's SoftIce page - SoftIce being the single most popular RE tool for Win32 software... Not that you're likely to be paying for it, you warez monkey, you.

Have fun, kids, and release Open Source.

(Posting Anon because I don't need the Karma or the implication of knowledge =)...

Re:Not a big deal. But could get expensive.

[Ninja Master Gara]

Reverse engineering is protected indirectly by laws in other countries that override the EULAs, since those clauses are not valid under the state laws.

Russian crackers would happily tell you all about this, just like they happily tell the owners of the software they've cracked when they're slapped with Cease and Desists.

no hysteria, please

[g4dget]

But, referring to doing this on native Windows code is not a good idea at all. Remember the EULA, simply having the Windows code on your disk constitutes acceptance of the EULA and reverse engineering by assembly dumps is explicitly defined as a violation of the EULA. In other words you are setting yourself in a position for major legal problems.

Don't believe everything you read. Just because Bill Gates writes into the EULA that you'll work as his towel boy if you open the box doesn't mean you are actually legally obligated to.

The only legitimate way to reverse engineer software is the method used by the Samba team. You must look at the input and look at the output and then determine your OWN method of achieving the same result.

Sorry, but you don't know what you are talking about. That is not "the only legitimate way".

Thus ANYTHING that you produce afterwards the even vaguely resembles the operation of the original software will place you in a losing position, legally

Oh, please, stop the hysteria. These things need to judged on a case-by-case basis. I frankly doubt that reverse engineering a trojan/virus will get you into hot water with Microsoft's EULA.

Debugging in vmware using softice

[seudafed]

A coworker was able to succesfully debug in vmware by looping a serial cable out one port and back in the other, giving one port to vmware and using softice's remote serial debugging to debug from the vmware host computer.

Re:Reverse Engineering

[jericho4.0]

RE is the process of looking at how software or hardware works, and trying to replicate it, without looking at the source code. ie, trying to build a car by looking at a car, rather than blueprints.