Malzilla - Malware Hunting Tool

Very good JavaScript deobfuscator for Windows. Especially useful for decoding packer functions. Example screenshot here.

The Slicehost Experience

I was recently experimenting with my Apache configuration and accidentally added a zero too much to the maximum process count setting without noticing. Later, when I ran some benchmarking tools on my website, I was — sadly — forced to put down my swapping server. That was the first time the service of my VPS was interrupted since I purchased it, 231 days earlier, and I’m happy to say; it was completely and utterly my own fault.

Oops!

I was once a shared hosting customer. It was horrible. After having tried a multitude of different shared hosting providers, I gave up trying to find one that didn’t promise me near unlimited resources for only $5/month and then turned out to be extremely unreliable, oversold and ironically; restrictive (most providers hide away inode and file size restrictions deep within their terms, effectively making it impossible for you to use anywhere near the amount of space you’re promised). Eventually, I thought to myself, “There has to be something else, something better, but still something that isn’t crazily expensive”. Shortly after I started looking beyond shared hosting providers, I stumbled upon a website greeting me with the message:

We’re just like you. Sick of oversold, underperforming, ancient hosting companies. We took matters into our own hands. We built a hosting company for people who know their stuff. Give us a box, give us bandwidth, give us performance and we get to work. Fast machines, RAID-10 drives, Tier-1 bandwidth and root access. Managed with a customized Xen VPS backend to ensure that your resources are protected and guaranteed.

It was Slicehost.com.

Although the prices were higher than I was used to, and the resources I was being promised were …much more realistic, I was sold, instantly. It didn’t take much more than 20 minutes before my first 256mb “Slice” was purchased and running. With this Slice, I basically had my own machine, or virtual private server, completely to myself. If you’re a shared hosting customer, this may be hard to fathom… but with this Slice, I was able to do anything I wanted, without any hidden limits. For $20 a month, I had my own quad-core server with 10GB of disk space and 256mb of RAM, and more;
  • Full root access and rebooting
  • Choice of Linux distro
  • Dedicated IP address and Tier-1 redundant bandwidth
  • RAID-10 disk storage
  • Reserved RAM
  • Guaranteed CPU share and more when available
  • 4-core servers running Xen virtualization instances
  • Slicehost management portal for reboots and software installs
  • Mobile management portal for smartphones
  • Ajax console access
  • Bootable rescue mode
  • Private IPs for inter-slice communication
  • HA capabilities via shared IPs
  • Machines running with fixed usage limits, below full capacity
Some examples of what you can run with a VPS that just isn’t possible on shared hosting include:
  • Custom web servers and configurations (Nginx, Lighttpd, Django, Rails, you name it)
  • SCM applications (Git, Bazaar, Subversion, Mercurial, etc.)
  • Game servers (MUDs, Counter-Strike, Call of Duty 4, etc.)
  • VoIP (Ventrilo/Teamspeak) servers
  • IRC bots and bouncers
  • any other server process you want, on any port you want, as long as it runs on Linux.
Now, not everything about Slicehost is rainbows and unicorns;
  • You need to have some Linux experience to be able to set up your server properly (there are tons of guides on Slicehost’s Community site that help ease this process).
  • It’s difficult to set up a real server with only 256mb of RAM. Be ready to do a little tweaking (using Nginx instead of Apache, tweaking your MySQL config, etc.). Of course, this is not really a problem with larger slices.
  • The network isn’t perfect. There are short (~5 mins) downtimes every once in a while.

That being said, Slicehost’s smallest slice, the 256mb slice, beats the crap out of any shared hosting solution I have ever used — and I’m still running everything on the 256mb Slice I purchased almost a year ago. My resources might not be unlimited, but they are always guaranteed. It is nearly impossible for any fellow user to disrupt my service, whether it be by eating CPU cycles or using a lot of memory. Nothing ever just stops working for no apparent reason. I don’t have to worry nearly as much about security. And last but not least, when something actually does go wrong, their support is excellent (and very down-to-earth).

In short, Slicehost has my warmest recommendation. If you’re still a slave to shared hosting — stop.

If I’ve convinced you to get a Slice of your own, you can go straight to the order page, here. If you’d like to know more, head on over to Slicehost.com. If you do end up getting your own Slice, it’d be cool if you’d mention me as the referrer (my e-mail address is patrick at this domain).

How to Install VMware Tools on Ubuntu Server 8.10

While installing VMware Tools (3.5.0-123630) on an ESX virtual machine running Ubuntu Server 8.10 (kernel 2.6.27 x64), I ran into a wall trying to compile the vmmemctl and vmhgfs kernel modules. The vmware-config-tools.pl script would throw errors at me when running make:

CC [M] /tmp/vmware-config0/vmmemctl-only/os.o
/tmp/vmware-config0/vmmemctl-only/os.c: In function ‘os_init’:
/tmp/vmware-config0/vmmemctl-only/os.c:590: error: ‘struct proc_dir_entry’ has no member named ‘get_info’
make[1]: *** [module/tmp/vmware-config0/vmmemctl-only] Error 2
Unable to build the vmmemctl module.

I finally got it working using alternative module sources. Here’s how:

Getting it working

  1. In e.g. VMware Infrastructure Client, right-click the virtual machine and select “Install VMware Tools”, then extract the VMware tools installation package inside the VM:
    mkdir ~/vmtools
    cd ~/vmtools
    sudo mount /media/cdrom
    tar xfz /media/cdrom/VMwareTools-*.tar.gz

  2. Now, grab the latest version of Open Virtual Machine Tools, extract it, and copy over its working kernel module sources. Note that the wget command below may not point to the latest version.
    wget http://dfn.dl.sourceforge.net/sourceforge/open-vm-tools/open-vm-tools-2009.03.18-154848.tar.gz
    tar xfz open-vm-tools-*.tar.gz
    cd open-vm-tools-*/modules/linux
    for i in *; do mv ${i} ${i}-only; tar -cf ${i}.tar ${i}-only; done
    mv -f *.tar ~/vmtools/vmware-tools-distrib/lib/modules/source/
    

  3. Finally, grab some dependencies needed for the compilation, and then run the VMware tools installer as you normally would:
    sudo apt-get install build-essential linux-headers-`uname -r`
    cd ~/vmtools/vmware-tools-distrib
    sudo ./vmware-install.pl

The installation should now finish without any problems! When you’re done, you can go ahead and do rm -rf ~/vmtools, or keep the files for deployment on other machines.

How to Use Minilyzer to Find Out Why Windows Crashed

You are sitting at your PC, relaxed and minding your own business. Happy. Suddenly and without warning, Windows decides to throw a fit and bombards you with the infamous Blue Screen of Death! You get angry — furious, in fact — and perhaps a little scared. You never got a chance to see what happened at the dreadful moment.

With Minilyzer and Microsoft’s Debugging Tools for Windows, you can easily and quickly figure out what caused a blue screen (or a seemingly spontaneous reboot), by analyzing what is called a Minidump, a file that is created by Windows whenever there is a STOP error (blue screen).

Analyzing the Minidump

Follow the steps below to generate a report containing the details of the blue screen.

  1. Download and install the 32-bit or 64-bit version of Microsoft’s Debugging Tools for Windows. If you are not sure what version to get, get the 32-bit version.
  2. Download the minilyzer.cmd script to somewhere convenient (like the desktop).
  3. If you want to analyze the latest blue screen and are running Windows XP (or Vista/Windows 7 with UAC disabled), run minilyzer.cmd and skip to step 6.
  4. Navigate to the C: folder and find the latest Minidump file, e.g. Mini012309-01.dmp.
  5. Copy the Minidump file to your desktop, then click and drag it onto the minilyzer.cmd script that you downloaded.
  6. Don’t be frightened by all of the information displayed in the window that pops up. If it’s the first time you are using Minilyzer, this will take a while. Relax, grab a drink and a powerbar, and wait until the Minilyzer report is opened.

Finding the Cause

When the report is opened, scroll to the very bottom and look at the last three lines: DEFAULT_BUCKET_ID, MODULE_NAME and IMAGE_NAME. These are what will usually tell you what has happened. Here’s what they might look like:
  • DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
  • MODULE_NAME: L1E60X64
  • IMAGE_NAME: L1E60X64.sys

Okay, so there’s something wrong with one of our drivers, but what is L1E60X64? A quick search on Google will show that it is the 64-bit version of the Atheros AR8121/AR8113/AR8114 ethernet driver. We have our culprit!

Fixing the Problem

In most cases, a simple driver update will fix problems like these. You can usually find drivers on your PC manufacturer’s website, the manufacturer of your motherboard, or directly from the manufacturer of the device itself. In the case above, installing the Atheros AR81Family 1.0.0.40 driver from Atheros’ drivers page solved the problem.

Of course, not every blue screen happens because of a driver issue. If you are not able to find out what caused a crash, the reports generated by Minilyzer are detailed enough to send to a geeky friend and/or a technical support service. You can find the reports in the folder where you saved minilyzer.cmd.

Cleaning Up

When you are done using Minilyzer, you can safely delete minilyzer.cmd and the Debugging Symbols folder that was created. If you think you might need to analyze more Minidumps in the future, you can keep minilyzer.cmd and the Debugging Symbols folder in the same folder to speed up any future analyses.

To find out more about Minilyzer, have a look at the Minilyzer project page.

3 Blasts From The Past

The main reason I discontinued many of my other blogging projects and re-made PatrickMylund.com was that the other sites were taking up way too much of my time, and their content wasn’t really that great — I had chosen technology news as the focus, so you can imagine. There wasn’t a lot that you hadn’t already seen 700 other places, and half of my time was spent trying to be the first to hit the button when X version of Y software was released. Boring, really.

There were, however, a few good posts that would fit on here nicely — and when I received a notice about expiration of one of my old domains, Sheeped.com, I took the time to transfer some of them to PatrickMylund.com. If you’re wondering why the sidebar now links back to 2006, this is why.

The posts are:

Enjoy!