My Road to Digital Forensics Excellence

Archive for the ‘Reverse Engineering’ Category

Stability Index and Reliability

Posted by Paul Bobby on January 17, 2011

While conducting an investigation in to removable media, on a Windows Vista 64bit computer, several searches had led me to the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib09

A REG_MULTI_SZ value, called ‘Counter’, contains the following sample text:


Which lead me to the tool “Reliability and Performance Monitor”.


I have never looked at the “reliability monitor” before – but it contains something very interesting. A nice looking timeline of stuff.

Reliability Monitor

Here’s a sample from the “Software (Un)Installs” section:

Software (Un)Installs

Sweet! Another 4n6 timeline artifact that may be immune to file system cleaners and uninstallers. How about those external devices?

External Devices

Okay enough of that – what about deadbox analysis? On my test system, the files of interest are located in the path “C:\ProgramData\Microsoft\RAC\PublishedData”:

File Location

The ‘SWIT’ file contains the Software (Un)Install information, AFL is Application Failures, HFL is Hardware Failures, etc.

Let’s manually decode so that we can enscript them.

The following screenshot represents the record for Microsoft Silverlight, v4.0.51204.0, that indicates there was a successful Configuration Change made on January 8th, 2011 at 08:00:49 EST.

Record Breakdown

Here we go:

Bytes 0-15 represent a 128bit Windows SYSTEM timestamp. (See here)

typedef struct _SYSTEMTIME {
WORD wYear;
WORD wMonth;
WORD wDayOfWeek;
WORD wDay;
WORD wHour;
WORD wMinute;
WORD wSecond;
WORD wMilliseconds;

The cool thing here is that the time is available for analysis as opposed to just the date that is presented in the Perfmon MMC.

The next 128bytes contain a Unicode string representing the application. This byte stream is read until a NULL terminated string is found. In this case, “Microsoft Silverlight”. And to make sure you are paying attention, this field is reusable and can contain SLACK information! Woot.

The next 128bytes contain a Unicode string representing the version of the application. This byte stream is read until a NULL terminated string is found. In this case, “4.0.51204.0”. This field can also contain SLACK information.

The last 12 bytes contain the encoded events (I reversed these, couldn’t find a spec).

Four bytes at Offset 272 (the Purple bytes):

    0x00 = Install
    0x01 = Uninstall
    0x02 = Ignore field

Four bytes at Offset 276 (the green bytes):

    0x00 = Configuration change
    0x01 = Application install
    0x02 = System Update install

Four bytes at Offset 280 (the blue bytes):

    0x00 = Failure
    0x01 = Success

Writing a parsing tool for this is now cake.

Here’s an example from my own SWITable.DAT file that illustrates slack data (or what I’m calling slack data).
SWIT Slack


Posted in Forensics, Reverse Engineering | Tagged: | 1 Comment »

msrll concluded

Posted by Paul Bobby on August 5, 2009

Static Analysis – Interaction with port 2200

Telnet to port 2200 produces a simple prompt “#:”. There is a single reference to this ASCII string in the code at 0x40BD04. That’s where I set my breakpoint.

image On tracing the calling tree that gets to this point, I found a place to modify the runtime credential check.

imageSet a breakpoint on the highlighted line, change the ZERO flag when you get there, and the code will assume the credentials you typed in at the “#:” prompt are valid.

Static Analysis – Interaction in IRC channel

I first attempted to find where the command “?login” was processed – but hit a dead end. Instead I focused on where the malware processes input received from the IRC channel. The bot issues a periodic IRC PING, causing the client to exit after a 180 Timeout if the PONG is not received. This is a little wrinkle when analyzing the code.

image When the username and password are processed, the code tests the results twice: line 405B68 with TEST EAX, EAX and line 405B72 with TEST EAX, 10000. Patching both of these lines with NOPS means a successful login in the IRC channel.

Incident Response

  1. DNS Block
    1. collective7[.]
  2. SMS Search
    1. system32\mfm\jtram.conf
    2. system32\mfm\msrll.exe
  3. Personal Firewall
    1. Block on incoming connections to TCP 2200
  4. 4n6 indicators
    1. Registry autorun key
    2. MD5 of executable

Posted in Reverse Engineering | Leave a Comment »

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

Posted in Reverse Engineering | Leave a Comment »

msrll.exe visits #mils

Posted by Paul Bobby on August 3, 2009


During the course of the recently taken Reverse Engineering class, Lenny encouraged us to practice our skills on a variety of malware that he had included on the class CD. This post is based on the specimen, msrll.exe (MD5: B4ACFE96A98590813413122C12C11AAA) (41,984bytes)

My analysis took 12 steps:

  1. Simple Execution
  2. Live Analysis Part 1
  3. Live Analysis Part 2
  4. Live Analysis Part 3
  5. Analysis Goals
  6. Static Analysis – Unpacking
  7. Static Analysis – First look
  8. Static Analysis – Command analysis
  9. Static Analysis – jtram.conf
  10. Static Analysis – Interaction with port 2200
  11. Static Analysis – Interaction in IRC channel
  12. Incident Response

One of the things I learned during this exercise is the value of the baby step approach – thinking you know what’s happening, leaping ahead and assuming too much, gets me in to trouble. Another lesson learned is that after live analysis is complete, I had to identify a series of analysis goals. With this specific specimen I found myself getting bogged down in the encryption routines, achieving no real progress, so I backtracked, and identified exactly those aspects of this malware I needed to explore.

Simple Execution

Running the program, msrll.exe from C:\Temp produced no visible output. After a few seconds the file disappeared from C:\Temp.

Live Analysis Part 1

  1. Wireshark showed a DNS query for collective7[.]
  2. Regshot showed the following items of interest
    1. HKLM\SYSTEM\CurrentControlSet\Services\mfm key added
    2. HKLM\SYSTEM\CurrentControlSet\Services\mfm\security key added
    3. Various key-value pairs added
      1. ImagePath = “C:\Windows\system32\mfm\msrll.exe”
    4. Files added
      1. system32\mfm\jtram.conf (contains obfuscated text)
      2. system32\mfm\msrll.exe
  3. CaptureBAT.exe
    1. preserved the deleted file msrll.exe from C:\Temp
    2. Both msrll.exe specimens MD5 match
  4. Process Explorer
    1. msrll.exe executing from system32\mfm\msrll.exe
    2. msrll.exe listening on two ports
      1. TCP 113 (Auth identd)
      2. TCP 2200

Live Analysis Part 2

  1. A host entry in system32\drivers\etc\hosts was made to resolve collective7[.] to my Linux VM.
  2. Wireshark reports a connection attempt on port 6667

Live Analysis Part 3

  1. Fire up IRCD on the Linux VM
  2. msrll.exe connects to the IRC daemon
  3. Wireshark lights up with the following activity
   1: USER PKjlVumLCrI localhost 0 :xIzUYurlIIlnEpkWTWTLmKmxpEjwTR



   4: JOIN #mils :

   5: MODE #mils

   6: WHO #mils

   7: PONG :localhost.localdomain

   8: PONG :localhost.localdomain

Analysis Goals

  1. What is in the file “system32\mfm\jtram.conf”?
  2. Interact with what is listening on port 2200
  3. Interact with the IRC bot
  4. Incident Response
    1. 4n6 indicators
    2. Network indicators leading to mitigations

Posted in Reverse Engineering | Leave a Comment »