Slashdot Mirror

← Back to Stories (view on slashdot.org)

Reverse Engineering Win32 Trojans on Linux

Posted by michael on from the clean-room dept.

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."

86 comments

  1. Win32 Trojans... by JessLeah · · Score: 4, Funny

    ...the condoms that bluescreen.

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

    --
    Honey, I shrunk the Cygwin
  2. on a related note by Anonymous Coward · · Score: 0, Flamebait

    on a related note:

    http://news.com.com/2100-1001-965916.html CNET reports hackers infest tcpdump distribution with trojan.

    This just goes to show that Windows is just as vulnerable as Linux.

    1. Re:on a related note by Luke-Jr · · Score: 2, Interesting

      Maybe, except that these things are rare on Linux and when they happen, they're nearly always a trojan. They happen alot more often on Windoze and most of them there are chaotic viruses.

      --
      Luke-Jr
    2. Re:on a related note by Anonymous Coward · · Score: 0

      Linux comes with a lot of applications that aren't generally considered a "part" of the OS. If you count vulnerabilities in those applications as being vulnerabilities in Linux then you must count vulnerabilities in third-party applications for Windows as being vulnerabilities in Windows.

  3. The great thing about Security Focus... by Anonymous Coward · · Score: 5, Informative

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

    1. Re:The great thing about Security Focus... by PhysicsScholar · · Score: 5, Informative

      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!

      --

      Department of Physics and Atmospheric Science, Dalhousie University, Halifax, N.S., Canada, B3H 3J5
    2. Re:The great thing about Security Focus... by Istealmymusic · · Score: 2
      Using grep or hexedit, you should be able to find the string "UPX" somewhere in the file if it was packed by UPX.
      This is unreliable. The "UPX" signature can be changed to anything; perhaps "DLL", and UPX will refuse to unpack it. Furthermore, it may be difficult to identify that the executable was packed with UPX, therefore hindering decompression once more. Security through obscurity does not work!
      --
      "The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare
    3. Re:The great thing about Security Focus... by Anonymous Coward · · Score: 0

      wow, what a pointless comment.

    4. Re:The great thing about Security Focus... by Anonymous Coward · · Score: 0

      I don't mean to be rude here, but anyone who knows enough to be able to be attempting to manually unpack an EXE in the first place is going to be able to tell what it's compressed with, "signature" changed or not. And where, exactly, did you hear that changing the "signature" would still allow the program to run? You know, being that it has to decompress itself when you run it, and thus would be looking for said string to identify where it's supposed to start? Do a little research, please.

    5. Re:The great thing about Security Focus... by Istealmymusic · · Score: 2

      I've done my research. The signature-verification-check routine in the main UPX unpacker can be altered to allow the check to pass if the signature-verification-check routine does in fact exist, but it does not. Thank you for your time.

      --
      "The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare
  4. Violation of the DMCA!! by SuperDuG · · Score: 5, Funny
    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

    --
    Ignore the "p2p is theft" trolls, they're just uninformed
    1. Re:Violation of the DMCA!! by Anonymous Coward · · Score: 1, Interesting

      They actually do make some of the viruses. (Which is plural of virus.) But they don't make the trojans. The trojans are made so that people can gain remote access to your computer for a few reasons. Either they want your hdd space or they want personal information about you. Even something as benign as VNC or Radmin can be turned to the "dark side."

    2. Re:Violation of the DMCA!! by Istealmymusic · · Score: 2, Funny
      Even something as benign as VNC or Radmin can be turned to the "dark side."
      As well as a benign utility such as SubSeven or NetBus.
      --
      "The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare
    3. Re:Violation of the DMCA!! by Anonymous Coward · · Score: 1, Funny

      and several cows (that is plural of cow) roamed the farms.

    4. Re:Violation of the DMCA!! by Anonymous Coward · · Score: 1, Insightful

      "virii" is perfectly acceptable hacker speak

    5. Re:Violation of the DMCA!! by Anonymous Coward · · Score: 0

      Correction: Several cowii roamed the farms.

  5. Uh Oh... by nothing+safe · · Score: 3, Funny

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

  6. On Mac OS-X by Anonymous Coward · · Score: 3, Interesting

    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..

    1. Re:On Mac OS-X by Anonymous Coward · · Score: 0

      Thank god you were AC for that, otherwise I'd have a name to put along side the picture of "stupid" in the dictionary. Oooooh, a Windows "underground group." Let me guess, they hang out in, say, #l33th4X0rzzzzzz on EFNet, and though they all claim to be "hackers" they're really just hosting a few warez FTP's?

  7. Make Win32 Trojans Open Source by Slashdotess · · Score: 4, Funny

    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.

    1. Re:Make Win32 Trojans Open Source by Istealmymusic · · Score: 1
      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.
      ADM is way ahead of you man.
      --
      "The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare
    2. Re:Make Win32 Trojans Open Source by sirshannon · · Score: 1

      but what about those of us who make our livings writing proprietary trojans for anti-virus companies?

      --
      The truth doesn't care what I think.
    3. Re:Make Win32 Trojans Open Source by Rasta+Prefect · · Score: 2

      Err....You mean something like this?

      --
      Why?
    4. Re:Make Win32 Trojans Open Source by Ryan+Amos · · Score: 2

      Yeah but BO2k has a legit use. Not that many people really use it for that...

    5. Re:Make Win32 Trojans Open Source by sco08y · · Score: 1

      but what about those of us who make our livings writing proprietary trojans for anti-virus companies?

      Are you a US citizen? If so, you can get lucrative defense contracts protecting Homeland Security against cyber-terrorism.

  8. Too bad no one here cares about ASM... by SexyKellyOsbourne · · Score: 5, Troll

    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.

    1. Re:Too bad no one here cares about ASM... by Brightest+Light · · Score: 0, Offtopic

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

      word.

    2. Re:Too bad no one here cares about ASM... by OneEyedApe · · Score: 2, Interesting

      I've been here a little over a month and this is far more interesting than any case modding story that I've seen. This is the sort of article that I read slashdot for.

      --
      Life sucks, but death doesn't put out at all....
      --Thomas J. Kopp
  9. Magic Patch by taviso · · Score: 5, Informative

    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

    --
    ex$$
    1. Re:Magic Patch by Anonymous Coward · · Score: 0

      finger me for my gpg key

      EWWW!!

      No!

      Well, OK

  10. Trojan Writers by Dakisha · · Score: 5, Funny

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

  11. haiku by bobtheprophet · · Score: 0, Redundant

    We are 1337 h4x0rs.
    Reverse engineering
    trojans like crazy.

    --
    Don't give me none of this "nature theme" business.
    1. Re:haiku by thinkninja · · Score: 0

      Beautiful :)

      --
      "The number of Unix installations has grown to ten, with more expected." (Unix Programmer's Manual, 2nd ed.; june 1972)
  12. Reverse engineering with WINE by jeroenb · · Score: 5, Informative

    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.

    1. Re:Reverse engineering with WINE by Anonymous Coward · · Score: 2, Informative

      Or you could use WinDBG, which MS provides for free. The gdb commands used in the article are almost exactly the same as used for WinDBG.

    2. Re:Reverse engineering with WINE by Istealmymusic · · Score: 1

      Typo? The above posting should say "WinGDB".

      --
      "The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare
    3. Re:Reverse engineering with WINE by IamTheRealMike · · Score: 5, Interesting

      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.

  13. Coming soon! by Anonymous Coward · · Score: 1, Funny

    With any luck, the anti-virus companies will soon start to figure out how to write linux viri...

    They've done a darn good job on win32! Just imagine the amount of work they've put in... Especially when all you need is the following options:

    o Remove .Exe attachments
    o Remove .Com attachments
    o Remove embedded (inline) e-mail files.

    But wait, that'd be too easy!

    1. Re:Coming soon! by Istealmymusic · · Score: 1

      You forgot PIF, BAT, SHS, VBS, and JS attachments.

      --
      "The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare
    2. Re:Coming soon! by Anonymous Coward · · Score: 0

      You talk too much.

      http://developers.slashdot.org/comments.pl?sid=4 52 44&cid=4687228
      http://developers.slashdot.org/com ments.pl?sid=452 44&cid=4687124
      http://developers.slashdot.org/com ments.pl?sid=452 44&cid=4687114
      http://developers.slashdot.org/com ments.pl?sid=452 44&cid=4687085
      http://developers.slashdot.org/com ments.pl?sid=452 44&cid=4687063

    3. Re:Coming soon! by Istealmymusic · · Score: 2

      Point taken.

      --
      "The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare
    4. Re:Coming soon! by Anonymous Coward · · Score: 0


      o ???????
      o Profit!

  14. Not a big deal. But could get expensive. by FreeLinux · · Score: 2, Troll

    Doing assembly dumps on object code isn't terribly exciting. Doing this on trojans is perhaps even less so, even on Linux.

    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.

    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.

    This is the only legal way to do it. If you even glance at an assembly dump of the actual software, you are no longer virgin. Thus ANYTHING that you produce afterwards the even vaguely resembles the operation of the original software will place you in a losing position, legally.

    Avoid assembly dumps of MS code!

    1. Re:Not a big deal. But could get expensive. by chrisseaton · · Score: 1

      And how many trojans come with EULAS? I don't think your argument applies here...

    2. Re:Not a big deal. But could get expensive. by Anonymous Coward · · Score: 0

      He's probably referring to various MS DLLs that the viruses may use. Those most likely fall under those crazy MS EULAs.

    3. Re:Not a big deal. But could get expensive. by Ninja+Master+Gara · · Score: 3, Interesting
      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.

      --

      ---
      When I grow up, I want to be a kid again.
    4. Re:Not a big deal. But could get expensive. by Anonymous Coward · · Score: 0

      no need to reverse-engineer those, they're fully documented and said docs are there for the reading on msdn.microsoft.com

  15. Some useful RE links... by Anonymous Coward · · Score: 5, Informative

    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 =)...

    1. Re:Some useful RE links... by PhotoGuy · · Score: 2

      SoftIce is (or at least was, and I presume still is) truly amazing. The version I used, awhile back, loaded *before* windows, allowing it to breakpoint on anything, about as low-level as you can get.

      Too bad VMWare doesn't support debugging in it's PC emulation, it would even be better than the Wine approach (a real copy of windows running). Still there are some good tools out there to trace programs. Very cool stuff.

      --
      Love many, trust a few, do harm to none.
    2. Re:Some useful RE links... by Anonymous Coward · · Score: 0

      great links !!.... i thought fravia+ froze his site long ago ...... but someone else must be running the show now ...... anyways it should be noted that the techniques that were used to reengg the s/ws in the main fravia's academy database are quite outdated now .... s/ws now use softice detection routines prior to initialising itself ( though there is frogice ;) ) ... then there are anti disassembly techniques , PEs , packers , encryptors etc ..... well if the worm/trojan writers become that smart then i think the forensics people are going to get a tough time ;) ( though i doubt how many so called security experts in bugtraq really study the trojan .. most of them simply do an effect analysis and maybe some basic attempts to find the signature in order to feed the snort/prelude rules ) .

    3. Re:Some useful RE links... by runderwo · · Score: 1
      Go here.

      It's +fravia's page, but it's constantly being updated with new stuff.

      --
      LRC, the best-read libertarian site on the web
  16. You have to admit that this is hard stuff... by Anonymous Coward · · Score: 0

    Not everyone can hack the kernel, and not everyone can disassemble win32 code and make sense out of it.

    One thing that Windows has over Linux is that no one ever implies that you shouldn't be running Windows just because you don't know C++.

    1. Re:You have to admit that this is hard stuff... by runderwo · · Score: 1
      One thing that Windows has over Linux is that no one ever implies that you shouldn't be running Windows just because you don't know C++.
      Who the hell ever implied that? If they did, they are a complete moron and do not represent anyone else's views.
      --
      LRC, the best-read libertarian site on the web
  17. Reverse Engineering by tomkit · · Score: 1

    I've seen this phrase a couple of times on /., but I'm not sure entirely what it means. Can someone provide a link or a concise explanation if no link?

    --tomkiit

    1. Re:Reverse Engineering by jericho4.0 · · Score: 3, Insightful

      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.

      --
      "A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
    2. Re:Reverse Engineering by Anonymous Coward · · Score: 0



      Happy thirteenth birthday from all of us here at Slashdot!!

    3. Re:Reverse Engineering by jaoswald · · Score: 2

      "Engineering" refers to starting with a goal (desired functionality) and arranging materials in a way (determined by a possibly involved design process) that reaches that goal (by delivering a finished product that works).

      "Reverse Engineering" is the exact opposite: one has a finished product that does something, or at least would if it were in proper working order. (Did you break it?) There might be some documentation. One might have some idea of the goal, perhaps only a vague one. (E.g., an automaker might reverse engineer a competitor's automobile, which has an obvious goal. For a Windows virus, you have a vague idea that the program is supposed to cause damage and/or replicate itself.) The missing part is insight into the design process that happened. Figuring out that design process (by whatever means) is the goal of "reverse engineering."

      Why do you want to know about the design? You might discover the secret behind some unique functionality. You might expose some flaw or weakness. You might be able to reconstruct enough of the internal protocols to be able to develop compatible products. (E.g. understand enough about IBM's PC BIOS to document its behavior well enough for a programming team to construct a compatible BIOS without simply duplicating the ROM contents, to break into the market for making PC clones in the 1980s.) You might just enjoy tearing things apart.

      Hope this helps!

  18. no hysteria, please by g4dget · · Score: 5, Insightful

    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.

    1. Re:no hysteria, please by Lisias · · Score: 0
      Well...

      United States is well known for allowing a rich entity to sue common people to bankruptcy. Not that this does'nt happens around here, anyway... 8-(

      If you give M$ a good excuse to sue you, doesn't matter who is right in the end: you will end up this with your life ruined. The rule of thumb is : do that you want, but don't tell other people about it. Or at least don't tell who your are.

      --
      Lisias@Earth.SolarSystem.OrionArm.MilkyWay.Local.Virgo.Universe.org
    2. Re:no hysteria, please by xanadu-xtroot.com · · Score: 2

      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.

      "Piss Boy, wait for the shake... [splash]... [ploink] Your tip is in the bucket."

      --
      I'm not a prophet or a stone-age man,
      I'm just a mortal with potential of a super man.
  19. Misinterpreting "Windows Native" by Anonymous Coward · · Score: 0

    I believe what the submitter meant by "Windows native code" was code compiled to run on a Windows platform, not specifically code written by (or owned by) Microsoft. Most Linux tools I know of primarily operate on ELFs/cores/etc. compiled for Linux. Being able to debug/examine binaries compiled to run on Windows without having a Windows box handy (or without wanting to risk it, or without wanting to use it for whatever reason) is useful.

  20. Debugging in vmware using softice by seudafed · · Score: 3, Informative

    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.

  21. B.G.A.T. ****TROLL ALERT**** by Anonymous Coward · · Score: 0

    B.G.A.T.(Billy Goats Against Trolls) is proud to announce that SexyKellyOsbourne has made our most wanted list. Normally it is pretty hard for us to prove our case against such people. But Ms. Osbourne has taken special care to ensure that the world knows she is a troll. Example #1 Right from her own journal. As much as B.G.A.T. would like to take credit for this, it does all come right from the trolls mouth!That one wasn't enough to convince you. How about This one? And then there is this one. She has also taken a moment to tell her something about herself. A quick glance at her posting History tells it all. Here is one of my favorites. Just have a look at the people on her FOE LIST. She has to go! So please take this time to spend just one mod point to keep this genital wart on society out of sight. MOD HER DOWN AS A TROLL!!!! Not because I said so, but remeber she is a self confesed troll.

  22. 5, Insightful ?!? by Anonymous Coward · · Score: 0

    Moderators PLEASE come to your senses !!! This is such an *obvious* troll.

  23. Isn't Reverse Engineering Prohibited By DCMA? by Anonymous Coward · · Score: 0

    Is Linux a tool of the unlawful?

  24. UPX by Anonymous Coward · · Score: 0

    Well since I still don't know ASM, I guess I learned "Always pack your trojans"... That would probably be useful information, if I start writing trojans, or get laid

  25. OT and way over rated by Anonymous Coward · · Score: 0

    This is about vir... forget it, not even wasting my time, the subject says it all... karma whore

  26. I know these types by Anonymous Coward · · Score: 0

    I've met them in real life. Usually they're boys in their mid teens, totally psychopathic, obsessed with being 'cool', and take joy in the whole badness of the cr4ck0r groupy thing. These boys do alot of damage, so as much as you may demean them for being the idiots they are, they're still going to doing their vandalism.

  27. Mod parent up! by ThePeeWeeMan · · Score: 1

    I have no idea why this was modded as a troll, cause it definitely does give you some insight into:
    (a) writing your own trojans =P
    (b) doing analysis and stuff inhouse without any consultants being needed.

  28. Not what i expected... by Anonymous Coward · · Score: 0

    I can sum up the whole article with:

    c:\> type Trojan.exe | find "WSAStatup"
    c:\> Netstat -a -n | find "LISTENING" >before.txt
    c:\> Trojan.exe
    c:\> Netstat -a -n | find "LISTENING" >after.txt
    c:\> diff before.txt after.txt