My Road to Digital Forensics Excellence

msrll continued

Posted by Paul Bobby on August 3, 2009

Static Analysis – Packed Code

  1. PEiD identifies the code is packed using ASPACK v2.12
  2. I found a manual unpacking method here
  3. I saved the executable once the OEP was reached
  4. LordPE was used to rebuild
  5. I ran the code through Static Analysis part 2, and observed the same filesystem and registry behavior.

Static Analysis – First Look

  1. I reverted to a pristine Windows VM and executed the unpacked msrll.exe
    1. Not interested in analyzing the copy, execute, delete capability
    2. All analysis with Ollydbg conducted against the system32\mfm\msrll.exe file

Static Analysis – Command Analysis

The following commands were observed from a simple strings output

?ssl ?free ?dcc ?clone ?raw ?get ?clones ?update ?say ?login ?hostname ?msg ?uptime ?fif ?sklist ?reboot ?!fif ?unset ?status ?del ?uattr ?jump ?pwd ?dccsk ?nick ?play ?con ?echo ?copy ?killsk ?hush ?move Ping ?wget ?dir Udp ?join ?sums Syn ?aop ?rmdir Smurf ?akick ?mkdir Jolt ?part ?run ?insmod ?dump ?exec ?rmmod ?set ?kill ?lsmod ?die ?killall ?md5p ?crash

Static Analysis – jtram.conf

This file contains a number of obfuscated strings. The string ‘jtram.conf’ was referred to in seven separate locations within the executable. Since the file is created, I decided to find when ‘jtram.conf’ coincides with a call to CreateFile. This happens at 0x409D94.


Setting a breakpoint right after this function call shows jtram.conf created as a 0byte file. So how do you write to a file?

I saw references to the function ‘fprintf()’. This function is called once at 0x410B76. With a breakpoint set just prior to this call, and stepping over, I found that jtram.conf was not populated.

How else do you write to files? I saw references to the function ‘writefile()’. ‘writefile()’ is called from three locations: 0x409E1E, 0x409E47 and 0x40A400. I took a look at 0x409E1E first, and turns out this is the correct place to start. Here’s the flow:”

  1. Call to createfile()
  2. Call to function 0x40B2B0 with the following on the stack
    1. 0022EE50 003E4278 Arg1 = 003E4278 ASCII “set”
    2. 0022EE54 0022EE80 Arg2 = 0022EE80 ASCII “”
    3. 0022EE58 00001000
    4. 0022EE5C 004099F5 ASCII “DiCHFc2ioiVmb3cb4zZ7zWZH1oM=”
    5. 0022EE60 77DDF8D2 advapi32.77DDF8D2
  3. Call to strcat() with the following on the stack
    1. ESP ==> > 0022EE80 dest = “oQERAPMCsTQme0PcWG9XLjSpzm4MQZ0T+YEOEyEmztL4jtJnUw==”
    2. ESP+4 > 00409A12 src = ” ”
    3. ESP+8 > 00001000
    4. ESP+C > 004099F5 ASCII “DiCHFc2ioiVmb3cb4zZ7zWZH1oM=”
    5. ESP+10 > 77DDF8D2 advapi32.77DDF8D2
  4. Call to writefile()
  5. “oQERAPMCsTQme0PcWG9XLjSpzm4MQZ0T+YEOEyEmztL4jtJnUw==” then becomes arg1 when 0x40B2b0 is called again

This is the point where I got bogged down. I attempted to reverse the algorithm used to write the obfuscated text to jtram.conf – big mistake. At least at this early stage in my reversing capabilities!

Can we fake out the executable so that it writes jtram.conf in the clear? Yep, change this:


to this:

imageAfter executing msrll.exe and waiting 30 seconds or so, I terminated the process, and opened jtram.conf in Notepad. The contents were written out in the clear:

   1: set bot.port 2200

   2: set irc.quit

   3: set servers,!,

   4: set irc.chan #mils

   5: set pass $1$KZLPLKDf$W8kl8Jr1X8DOHZsmIp9qq0

   6: set dcc.pass $1$KZLPLKDf$55isA1ITvamR7bjAdBziX


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: