Jun 182011
 

This is a series of notes on dealing with PC malware (viruses, worms and the like) gathered because I’m looking into it and published as a way of reminding myself about this stuff. Bear in mind that I’m not an expert but neither am I a complete dunce – I’m normally a Unix or Linux person but I’ve been keeping half an eye on Windows infections for years.

Some links to tools are contained within. However you should be aware that tool recommendations change over time; you will need to check how outdated this document is before following any recommendations blindly.

At present this blog entry is a work in progress … lots of testing needs to be done before being confident this is right.

Cleanup Process

This is not :-

  1. How to approach this forensically – if you’re dealing with an investigation, it’s a whole other ball game and you probably need professional assistance to avoid corrupting evidence.
  2. A technical guide as to which tools to use.

1. For The Ultra Cautious Or When Handling Real Important Data

The process of removal can be destructive, and in the worst cases you can end up cleaning the malware and ending up with a brick. So make an image of the hard disk as it is. Two basic ways this can be done :-

  1. Removing the hard disk from the infected machine, attaching to an appropriate machine (USB->SATA, USB->IDE converters are handy here), and making an image of the disk.
  2. Booting off a “rescue” CD on the infected machine, and imaging the hard disk to a network share of some kind. This is the preferred option.

This will be slow. So be it. Cleaning an infected PC is not going to be a quick job whatever you do. The best you can hope for is that there are many periods where you can leave it churning away and get on with something else.

2. Boot A Rescue CD

There are those who tell you that there is no need to boot off a known uninfected disk to clean an infected machine; their anti-malware/virus product can clean an infected machine “live”. There are others who claim that the only way to be sure is to boot off that disk and clean the machine that way. Both are wrong.

If you are paranoid (and in the presence of malware paranoia is fully justifiable), you will do both.

3. Boot Infected Machine and Clean

As suggested previously after booting off a rescue disk and cleaning, boot the infected machine and clean again.

Tools

The following is a list of rescue CD’s that have been suggested :-

  • UBD4Win. Has to be “built” with the assistance of an XP installation; somewhat tedious but it isn’t the end of the world. However it does need preparing in advance – building a rescue CD with the assistance of an infected machine isn’t the most sensible idea!
  • Knoppix. Graphical, pretty, feature packed, but seems to be lacking in anti-malware tools (for instance the only AV tool included is Clam).
  • Trinity Rescue Disk. Menu interface. Virus definitions update over the net; choice of Clam, F-Prot, Bitdefender, Vexira, AVast (need to obtain license key). Various other utilities.
  • F-Secure Rescue CD.

Some of the above are Windows based; some are Linux based. The choice of which to use should be based on results not whether they tickle your prejudices (or mine!).

The following is a list of “live” tools to be installed that have been suggested :-

Asides

Nothing to do with the main subject. Merely some notes worth mentioning.

It seems that at least some malware can detect it is running within a virtual environment. In some cases it ceases to do anything, and in others may try to “break out”. This indicates that analysing malware within a virtual environment may not give sensible results, and in some cases may be dangerous! That is not to say that using a virtual environment is no longer of any use, but you may need to take special case such as running the virtual environment under Linux and/or ESX rather than Windows. And be careful about negative results.

May 172011
 

This is going to be grossly insufficient for anyone trying to learn R (a wonderfully powerful statistical package … although the “stats” part of that may be my inner statistician). This is merely a set of commands I tend to use myself on the rather too rare occasions when I need R.

R is started with “R” at the command-line … of course (although “r” does something quite different).

Loading Data

If you have a file formatted like :-

number1 number2
number3 number4

Then this can be read into a “variable” with :-

> Data <- read.table("filename.dat")

If it is convenient to add column names into the file to give presentable names later on, then do so and tell R that there are headers :-

> Data <- read.table("filename.dat", header=TRUE)

Whilst R has plenty of control about how to read data … far more than I need at least, it may be easiest to munge your input data into the above format if you are more comfortable with the command-line. You can see how R has imported your data with :-

> names(Data)
[1]: "header1" "header2"

Later when it comes to doing something with the actual data, you can access the relevant “vector” with Data$header1. But hopefully you will choose more meaningful names!

Stats Summary

To produce a summary of a vector :-

> summary(vector)
   Min. 1st Qu.  Median    Mean 3rd Qu.    Max. 
   1249    6938   18900   16210   24100   30840

Graphs

This section needs a lot of expansion. But to graph two variables … essentially one being a value at a particular time and the other being the time :-

plot(v1, v2, xlab="Horizontal label", ylab="Vertical label", main="Title")

This will draw the graph onto the default device – which is normally the main X11 display. If you want to change the output, you need to choose an alternate device. For a PNG file :-

png("filename.png")
(Redo the plot you're happy with)
dev.off()
May 142011
 

This is a note for my own future sanity (like when I start using IPv6 and want this enabled again) given that this information is widely available around the network. If you do not know why you would want to turn off IPv6 when you are almost certainly not using it, then you probably want to do it anyway.

Hint: You may have a globally reachable IPv6 address on your machine that bypasses your firewall. And if that doesn’t worry you, it should!

Anyway, to turn it off run regedit in your preferred manner, and create the following DWORD attribute :-

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip6\Parameters\DisabledComponents

Set the value to FF (in hexadecimal). And reboot your machine.

So far this has worked with :-

  1. Windows Server 2008R2
  2. Windows 7 (Ultimate)
Jan 292011
 

In the dim and distant past when keyboards were enclosed in metal cases and you certainly didn’t tuck one under the arm and walk around with it (actually I don’t do now either), the placement of many keys was continually up for debate. But apart from the main QWERTY section, one of the key placements you could rely on was the Control key next to the “A” key. These days it’s been turned into one of those silly CapsLock keys.

Back when I previously did some keymapping, I neglected to mention how I mapped CapsLock into a Control key. As appropriate punishment, changing window managers has somehow meant that my previous mapping had been lost. So I had to figure out how to do it again.

First thing to do is to switch to a text console – I’ll be mapping this at a very low level.

Next thing to do is to find out the scancode of the key I want to map :-

# showkey -s

One started I have to press the key I am interested in within 10 seconds or the program will edit. I press CapsLock and I get two numbers displayed – 3a and ba (they’re in hexadecimal for the base-16 challenged). The first is the key press, and the second is the key release. We can discard the second as Linux is clever enough to figure out one from the other.

The next thing we want to do is to obtain the keycode of the key that we want to map to – in this case the left control key. It probably doesn’t matter here, but it is worth noting that the left and right control keys are different scancodes and keycodes. So you could map then to different things. Anyway, to obtain the keycode of the key we want, run :-

# showkey -k

And press the key to map to.

Lastly we want to construct the command to actually do the mapping :-

setkeycodes 3a 29

This of course has to be added to a script being run when the system boots – you want this mapped as early as possible.

Jan 232011
 

During a recent upgrade of the software I have installed on my work laptop, Macports managed to get a trifle confused during the process. Firstly Enlightenment suddenly started crashing at the drop of a hat, and secondly dbus suddenly started refusing connections and claiming that X11 support was not built-in.

The first problem I solved by comping Enlightenment (E16) from scratch and overwriting the Enlightenment installed from Macports – probably not the right thing to do. It turns out that the Macport version of Enlightenment is very outdated and could do with a refresh.

The second problem was a little trickier, and may have been solved in a slightly more Macport compatible manner. In fact this problem was two problems in one. First of all, any attempt to start a GNOME-based (or presumably anything wanting to talk to dbus) would give an error indicating that X11 support was missing.

I fixed this by recompiling dbus manually :-

# port mirror dbus
#   Gets a copy of the source code used to compile the source
# cd /opt/local/var/macports/distfiles/dbus
#   Change to directory where the source code is located
# gunzip -c dbus-1.2.24.tar.gz| tar tvf -
#   Unpack the source code
# cd dbus-1.2.24
#   Enter the directory that we've just unpacked.
# ./configure --prefix=/opt/local
#   Configure the package.

If you look at the last few lines of the output from this configuration process, you will see a message of the form “Building X11 code: yes” which is what we want to see – that X11 support is being built. At this point we can build and install :-

# make
# make install

The next problem was that attempting to use the automatically launched version of dbus resulted in a “permission denied” error when trying to communicate over the socket. The work-around for this turned out to be to :-

  1. To turn off the launchd control of dbus by renaming the files /Library/LaunchAgents/org.freedesktop/dbus-session.plist and /Library/LaunchDaemons/org.freedesktop/dbus-session.plist by putting a “.” in front of their name. This stops launchd from starting anything.
  2. Changing the .xinitrc to start dbus using the syntax eval $(dbus-launch –auto-syntax) (note that I explicitly ensure that this script is launched with zsh).