Tagged as: Linux

First, this is what I mean about serial numbers. Suppose you're using a Windows system, have a floppy disk at drive A:/ and a regular USB flash drive at E:/, and you run these commands in the command prompt:

C:\>vol E:
Volume in drive E is CRUZER
Volume Serial Number is 955C-59BF

C:\>vol A:
Volume in drive A has no label.
Volume Serial Number is EC2B-36AF

According to The Wikipedia, the serial number (ID) is kept in two different places on the partition depending on the version of FAT being used.

In FAT12 and FAT16 (used with floppy disks), the ID begins at byte offset 0x27 (39 in decimal); in FAT32 (used with flash drives and external hard drives), the ID begins at 0x43 (67 in decimal).

So, with the handy dd utility that comes standard on pretty much any Unix-like system, you can extract this information and display it. Here are a couple of one-liners you can run in a Unix terminal. I'll explain how they work afterward.

# For FAT32 filesystems (modern flash drives)
dd if=/dev/sdb1 skip=67 bs=1 count=4 | hexdump -v -e '1/1 "%02X" " "' | xargs perl -e '@_=@ARGV; print "Serial Number: $_[3]$_[2]-$_[1]$_[0]\n"'

# For FAT12/16 filesystems (old floppy drives)
dd if=testfloppy.img skip=39 bs=1 count=4 | hexdump -v -e '1/1 "%02X" " "' | xargs perl -e '@_=@ARGV; print "Serial Number: $_[3]$_[2]-$_[1]$_[0]\n"'

If you're going to be using a physical device like in my first command, you need to run the command with root privileges (regular users can't read directly from the device node). My second example (using an image file) can be run as a regular user, however.

These commands printed in the terminal for me:

(for the flash drive)
4+0 records in
4+0 records out
4 bytes (4 B) copied, 3.3445e-05 s, 120 kB/s
Serial Number: 955C-59BF

(for the floppy image)
4+0 records in
4+0 records out
4 bytes (4 B) copied, 3.1551e-05 s, 127 kB/s
Serial Number: EC2B-36AF

dd if=/dev/sdb1 skip=67 bs=1 count=4
hexdump -v -e '1/1 "%02X" " "'
xargs perl -e '@_=@ARGV; print "Serial Number: $_[3]$_[2]-$_[1]$_[0]\n"'

The hexdump command takes the 4 binary bytes and displays them in hexadecimal. On my flash drive, it looks like this: BF 59 5C 95. Note that the hex codes are out of order; Windows shows them as 955C-59BF - basically, the reverse of what hexdump shows. Hexdump is showing the correct order; Windows and DOS reverse them when they show you the serial number.

So, we run it through xargs (which turns the four hex numbers into four separate parameters) and sends them to a quick Perl script, which prints out "Serial Number:" and puts the hex codes in the correct order, to give the same result as Windows and DOS.

One could use this information to make a vol command for Unix. If the command checks other places in the filesystem headers to determine the version of FAT, it could automatically use the correct byte offset and get the serial number from both floppy disks and flash drives.

Sometimes I start a graphical app from within a terminal, for instance because opening the app via a double-click doesn't do anything (for instance, if a Wine app won't start because of a missing DLL file - I can only see this error message if I try to start the app from within a terminal).

But then I want to close the terminal but still keep the graphical app running. Closing the terminal would kill the graphical app too, unless you can somehow detach it completely from the terminal.

For the example I'll run gedit, GNOME's default text editing program, from a gnome-terminal terminal window.

1) Start the graphical app from the terminal

$ gedit

2) Temporarily suspend the process with Ctrl-Z

^Z

The terminal will tell you which "job number" it has given to the suspended process. This will usually be 1 unless you have other jobs running:

[1]+ Stopped gedit

$ bg 1

4) Disown all jobs from this terminal

$ disown -h

This can also be used to detach command-line applications, too - especially if it will be a long-running process (for example, to back up a large folder over the network) and when you don't really care about its output; you just want it to continue running until it's done, but you need to close your terminal.

With no 3D acceleration, the results are the same as before: a mostly black screen, can't really do very much with it. With VirtualBox's 3D acceleration enabled, it's similar to the result I had before... very frequently the majority of the desktop (besides a box around my desktop icons) and the whole shapes of windows have that "striped" blue texture all across them.

I say most of the time because it's sometimes possible to get a window to show its true contents and become usable by dragging it around and playing with it for a bit, but the effects usually don't last very long before the window loses its textures again. The scale effect of bringing up the main menu in GNOME Shell usually fscks up all windows you have open again.

But the reason for this particular blog entry is that I also decided to test Compiz Fusion inside VirtualBox, on Fedora 12, under the same conditions as the GNOME Shell. I couldn't do this before because the beta version of Fedora 12 had some dependency issues, and Compiz conflicted with GNOME Shell; they couldn't co-exist together.

In Fedora 12 they can co-exist, and the Desktop Effects GUI window gives options to select either Compiz or GNOME Shell. Anyway, here's a screenshot. This is a real screenshot of Fedora 12 running in VirtualBox with full desktop effects active, including the 3D Cube effect.

Click for a full-size version of this screenshot

It basically relied on the fact that GNOME, KDE, and Xfce treat .desktop files specially, in the way that Windows treats .exe files specially. .desktop is the file extension of Launchers in modern desktop environments, and they used to be launchable without even requiring execute permissions first. With them you could distribute a simple .desktop file via e-mail which downloads and executes malware from the web in one easy "click-and-run" motion from the victim. Read the linked blog post for all the details.

In Ubuntu 8.10 and Fedora 10, as mentioned there, this is how GNOME treated .desktop files; in Fedora 11 (and probably more recent Ubuntu's) things are a little different. Now, .desktop files are inherently untrusted and will prompt the user when they try to execute them. The user can then mark them trusted (which requires them to try and execute them a second time), or just launch them this one time.

When a launcher is untrusted, it displays in Nautilus as a text file. Its icon is a preview of the first couple lines of the text inside the launcher file, instead of the custom icon specified for it, and the .desktop extension is displayed to the user. When marked as trusted they work as before: the .desktop extension is hidden and the launcher gets its custom icon displayed.

Anyway, when you put files into a tarball (e.g. tar -czvf), the files keep their permissions and attributes. Thus, if you put a file with execute permissions into a tarball, it keeps that permission. If extracted on any other unix system in the world, it's extracted with execute permission.

After some poking around, I discovered that the mechanism by which launchers are marked as trusted is simply based on the execute permission. When a program such as wine creates a launcher (for instance, if you just installed a Windows app that puts an icon on your desktop), the launcher is currently untrusted by default, so you'd have e.g. "Mozilla Firefox.desktop" on your desktop; it's not a trusted launcher. When you run it and mark it trusted, all that happens is that GNOME adds execute permissions to the file. You could also run chmod +x "Mozilla Firefox.desktop" in a terminal to do the same thing.

So... for the "virus" in that blog entry to still work on Fedora 11, you'd need one additional step: e-mail them a tarball containing your desktop launcher and have them extract the contents, and then run the launcher. This makes it a little bit less likely that the victim will actually run it, though, especially because if they look inside the tarball first they'll see its real file name (including the .desktop), and GNOME's archive manager won't execute it if they open it directly from inside the tarball; instead they'll get the contents of the file displayed in their text editor.

I remember that the ability to share USB devices with virtual machines used to be working "out-of-the-box" with VirtualBox and older versions of Fedora, but Fedora 11 complicates things a bit.

By default USB devices in virtual machines don't work; the menu lists all your USB devices as being greyed-out while the machine is running. It comes down to a permissions issue with the user you're logged on as. To fix:

1) Make sure your user belongs to the vboxusers group. Older versions of VirtualBox made this an absolute necessity (virtual machines wouldn't boot otherwise), but VirtualBox 3.0 seems to only create this group but not actually require your user to belong to it for the most part. Update: with current VirtualBox, this is all that's required; USB should be working after you do this and log out and back in. If not, continue reading.

2) Create a mount point directory for usbfs (I did mkdir /usbfs as root).

3) Edit /etc/fstab to add a line that mounts usbfs, giving the vboxusers group write permissions to the mount point. In my case vboxusers had a group ID of 501; check in /etc/group to see what your group's GID is:

# VirtualBox USB support
none  /usbfs  usbfs  rw,devgid=501,devmode=664 0 0

Now, you can either reboot or run mount -a as root (to reload the data from /etc/fstab). If you had to add your user to the vboxusers group because it didn't already belong to the group, you'll need to log out and back in again.

And now your virtual machines can access the USB devices.

This is a sequel to my rant about GNOME Shell. I decided to back up my claims with an experiment.

Installing gnome-shell in a virtual machine with no 3D hardware acceleration.

Every single desktop environment that exists right now will run just fine in a virtual machine with no 3D hardware acceleration: XFCE 4.6 and older; KDE 4.3 and older; KDE 3.x and older; GNOME 2.26.3 and older; LXDE; and of course all of the desktop-less window managers (IceWM, et cetera).

GNOME 3.0, I claimed, with its GNOME Shell, will be the first desktop environment that will not run unless the user has 3D hardware acceleration, and that there is no fall-back. Here is the proof:

No Guest Additions; No 3D

* Fedora 12 Alpha (11.92 Rawhide)
* VirtualBox 3.0.6 r52128 (2009-09-09)

Let's launch it!

Getting ready to launch GNOME Shell

And... what happens?

Umm...

Hmm...

Let's put on the dumb end user hat and say Joe Average installed Ubuntu 10.10 which might come with GNOME 3.0 and GNOME Shell, he hasn't installed his nvidia drivers yet because they're proprietary and Canonical can't legally include them with Ubuntu, and he logs on and sees THIS. He's lucky that X11 didn't crash entirely and send him back to the login screen, but nonetheless he can't see anything. He can't see Firefox to start browsing the web trying to find a solution to this problem.

Okay, let's move on...

Guest Additions, No 3D

Exactly the same.

I won't post screenshots because they look just like they did the last time. I get a mostly black, unusable desktop.

Of note however is that the terminal printed this upon starting the GNOME Shell:

OpenGL Warning: Failed to connect to host. Make
sure 3D acceleration is enabled for this VM.

Enabling 3D Acceleration

I've personally not used it. But it is known to be buggy; VirtualBox labels it as "experimental"... well, here's why:

Start the shell...

Uh...

This looks promising...

In this experiment, even with 3D acceleration by the virtual machine, GNOME Shell is not usable. Again, though, VirtualBox's 3D acceleration is still in the "experimental" phase. It probably doesn't work a whole lot better with Compiz Fusion, either. Plus my video card might just suck (VirtualBox basically passes the guest's OpenGL calls directly to the host's video card).

But the thing to take away from this is:

• Desktops that work with basic video drivers:
  • GNOME 1.x series
  • GNOME 2.x series
  • Xfce 4.6 and older
  • KDE 3.x series and older
  • KDE 4.x series and older
  • LXDE
  • All window managers
• Desktops that don't work with basic video drivers at all:
  • GNOME 3.0 with GNOME Shell
  • (can you hear the crickets? yes, GNOME 3.0 stands alone, all by itself, in this category. sad. :( )

Now let's see if the GNOME dev team can turn this around in the next year (doubtful; they all come off to me as a bunch of eye-candy-obsessed children who'd rather snazz up the desktop because they think it's "cool" than to worry about things like usability, functionality, or accessibility... and with absolutely no thought given to the user experience, and no usability studies done, etc.).

GNOME Shell for the lose.

Half a year ago the roadmap for GNOME 3.0 was announced, and it involves a new window manager called GNOME Shell. They plan to have GNOME 3.0 ready for public consumption in 2010, around the release of Fedora 13. I tested the GNOME Shell back then and it was awful; since then, it hasn't improved a lot, either. And I'm not optimistic about where it's headed; I think GNOME 3.0 is going to be a terrible, terrible mistake.

If you aren't aware, GNOME is a desktop environment for Unix, and is the default desktop environment for both Fedora and Ubuntu. The other major desktop environments are KDE and Xfce.

GNOME has been said to resemble Windows 98 - true, its default theme is pretty gray and boring, but GNOME is flexible enough that it can be made to look just like OS X or Vista or anything else.

The KDE desktop environment looks an awful lot like Windows as well. KDE jumped from versions 3.x up to 4.0 about a year ago, and KDE 4.0 looks a lot like Windows 7. But on the whole, the desktop still looks and acts the same; KDE's version jump was a natural evolution of its desktop, not a complete change to something completely new and unfamiliar.

GNOME, not wanting to be 1-upped by KDE's version jump, decided they'd bump GNOME 2.x up to version 3.0 -- and entirely redefine the desktop metaphor while they're at it. GNOME 3.0 with its GNOME Shell has almost nothing at all in common with GNOME 2.x.

Here is a relatively recent article about GNOME Shell, so you can take a look.

But that's not why I dislike it. I just thought I'd give some background first. This is why I dislike it:

GNOME Shell requires 3D hardware acceleration. What? Let's compare the current desktop environments: Xfce 4.6 and older, KDE 3.x and older, KDE 4.0, and GNOME 2.x and older... all of these desktops can be run on bare minimal video hardware. You know how Windows Vista, and Windows 7, have "Basic" themes? If you run Vista or 7 on a computer that either doesn't have a kickass video card, or you simply just don't have the drivers installed yet, you get to use the "Windows Basic" theme. Windows has a fall-back to Aero.

But GNOME 3.0 will have NO such fallback. If your video card sucks, or you don't have the drivers, you can't use GNOME 3.0 at all. What will you see? You'll see the X11 server crash and leave you at a text-mode prompt. You will have NO graphical user interface at all; you'll be stuck in text-only mode, because your video card must be kickass for GNOME Shell to load.

Most people have ATI or Nvidia cards, you say? Well, it's well known that ATI and Nvidia have proprietary, closed-source drivers; the companies simply refuse to open up their video drivers as free software. And because Linux is a free and open source operating system released under the GNU General Public License, Linux isn't legally allowed to include ATI or Nvidia drivers "out-of-the-box."

So, when you pop in your Ubuntu or Fedora CD to install it on your computer, the installed operating system can not legally contain Nvidia or ATI drivers. Without the drivers, your video card can't do 3D acceleration. If you were on Windows Vista or 7, you would see the Windows Basic theme; if you're on Linux with GNOME 3.0, you'll see NOTHING! You'll be at a text-mode login prompt, and when you log in, you'll be at a text-mode bash prompt. No graphics, no windows, nothing but text.

This wouldn't be the end of the world for me personally, but then again I know a great deal about Linux. I would be able to install third-party software repositories and install the Nvidia or ATI drivers all at the command line; or at least I would know how to install an alternate desktop environment such as Xfce so that I could get a GUI and then fix the video problem manually. But the average user, or newbie to Linux? They'll be stuck.

I'm curious to see how Canonical (the company behind Ubuntu) is going to deal with this. Are they going to stick it out with GNOME 2.x and ignore GNOME 3.0? I imagine that's quite a likely scenario. Because consider this:

Ubuntu is known as the newbie-friendly Linux distro. It's the easiest one to get set up and running, it's easy to use, and when you log in for the first time it even asks you if you'd like to install some proprietary hardware drivers. Ubuntu can't legally install these automatically but it makes it easy for the user to install them afterward.

What if Ubuntu upgrades to GNOME 3.0, a new user installs it on their computer, and the new user can't even get the desktop to load? They have an ATI card and they don't have the drivers installed, and therefore GNOME 3.0 absolutely will not start because it absolutely requires hardware acceleration. They're a complete newbie to Linux, they know nothing about the command line, but they're stuck at a text-mode prompt. Know what they'll do? They'll switch back to Windows and never be fooled again when somebody wants them to give Linux a try!

Of smaller importance, by reinventing the wheel, the GNOME developers are basically starting over from scratch almost. This means that some of the more complicated problems that the GNOME dev team have tackled in the past may come back. Dual monitor support, for example. The jump to 3.0 is quite likely going to be a large step backwards for the GNOME desktop environment.

I am not a fan of where GNOME is heading. And if the GNOME dev team end up fscking this all up in the end, I'll just be forced to use a different desktop environment. Although, I really don't want to have to resort to that...

I love GNOME 2.x. I can not stand KDE. KDE is just completely annoying to use. Xfce isn't too bad; it shares a lot in common with GNOME (they both use the GTK+ GUI toolkit)... but Xfce feels far behind GNOME 2.x - it feels clunky and old-school, and it lacks certain features that GNOME 2 has, such as integrated dual monitor support; for dual monitors in Xfce you'll have to resort to Nvidia's config tool (if you have an Nvidia card), otherwise you're screwed.

Xfce still has a year to get better, and GNOME 3 still has a year to not completely suck in the end. If GNOME 3 sucks and Xfce is still so clunky, I may even just be forced to abandon the Linux desktop altogether and go back to Windows. :(

Take a lesson from Windows (and literally every single desktop environment in Linux), GNOME 3.0 - don't make 3D acceleration an absolute requirement, and include a fallback version for basic video drivers. Otherwise a really good chunk of your user base will move on to other desktops, or move back to Windows. And if you keep this up, Canonical and Red Hat may even just have to drop you completely as their default desktop environments in their distros, for making life too complicated for the end users.

Late last week I started thinking about how to access a webcam device from within Perl. I have no direct need of such capability at the time being but I wanted to know how to do it in case I wanted to do something in the future involving webcams.

A few years ago when I used mostly Windows I found EZTwain, a DLL library for accessing a webcam in Windows using the TWAIN protocol (which as I understand is obsolete by now). The DLL was a pain in the butt to use and I couldn't get it to work how I wanted it to (it insisted on displaying its own GUI windows instead of allowing my Perl script to directly pull a frame from it without a GUI).

Besides that there's pretty much no libraries Perl has been built to use yet that can access a webcam. So, I started looking into using third-party programs such as ffmpeg and mplayer/mencoder to provide the hardware layer for me so that Perl can get just the jpeg images out and do with them what it needs.

Of these programs I wanted to use ffmpeg the most, because I know for sure there's an ffmpeg.exe for Windows, which might mean that whatever code I come up with might be reasonably portable to Windows as well.

After some searching I found some command-line sorcery for using ffmpeg over SSH to activate the camera on a remote computer and stream the video from it over SSH to the local system, and display it in mplayer:

ssh user@remoteip ffmpeg -b 100K -an -f video4linux2 -s 320x240 -r 10 -i /dev/video0 -b 100K -f ogg - | mplayer - -idle -demuxer ogg

Using the basic ffmpeg command in there, along with some hours of research and poking around, I eventually came up with a command that would activate the webcam and output a ton of jpeg images with consecutive file names, of each frame of video that the camera recorded:

ffmpeg -b 100K -an -f video4linux2 -s 640x480 -r 10 -i /dev/video0 -b 100K -f image2 -vcodec mjpeg test%d.jpg

The mjpeg codec (or "motion jpeg"), in ffmpeg, really means it's a bunch of jpeg images all combined together one after the other (the start of each jpeg image can be seen in hex by looking for the magic number, 0xFFD8). The "image2" format here means that each frame from the mjpeg stream gets written to an individual image file, in the format test%d.jpg where %d is a number that goes up for each image written.

By changing the image2 to image2pipe instead, the output (all the jpeg images in the mjpeg stream) is sent through the program's standard output, so it can be piped into another program, or read from in Perl.

So in Perl I opened a pipe that executes this command and have the script read from it, reading all the jpeg images and then displaying them in a Perl/Tk window as they come in. In effect: a live webcam stream, where Perl is entirely in control of the jpegs as they come in from ffmpeg and can do with them whatever it wants!

I added a button to my GUI for taking a snapshot and saving it to disk (in actuality, as each complete image is read and displayed, it's kept around in memory until the next image is read and displayed... so this button just saves the last full image to disk).

Here's my proof of concept Perl code:

#!/usr/bin/perl -w

# Perl/Tk Webcam Streamer and Snapshot Taker
# Proof of Concept
# Author: Casey Kirsle, http://www.cuvou.com/

use Tk;
use Tk::JPEG;
use MIME::Base64 "encode_base64";

# Some things that might need to be configured.
my $device = shift(@ARGV) || "/dev/video0";
if ($device =~ /^\// && !-e $device) {
    die "Can't see video device: $device";
}

# Tk MainWindow
my $mw = MainWindow->new (
    -title => 'Tk Stream',
);
$mw->protocol (WM_DELETE_WINDOW => \&onExit);

# A label to display the photos.
my $photo = $mw->Label ()->pack();

# A button to capture a photo
my $capture = $mw->Button (
    -text => "Take Picture",
    -command => \&snapshot,
)->pack();

$mw->update();

You can download it here. It should run on any Linux distribution and it depends on having Perl/Tk and ffmpeg installed, and the video4linux2 system (any modern distro will have that).

In the ffmpeg command here you'll see I also piped the output into a quick Perl script that substitutes all the jpeg headers so that they begin with "KIRSLESEP" -- this was to make it easier to split the jpegs up while reading from the stream.

Since this uses ffmpeg and there's an ffmpeg.exe for Windows, this might work on Windows (you'll definitely need to modify the arguments sent to the ffmpeg command, though). I don't currently have access to a Windows machine with a webcam, though, so I can't work on that just yet.

Anyway, here it is: webcam access in Perl!

I, along with pretty much every other savvy computer user, never do the "Recommended" installation of software and always go with the "Custom Installation" route, so that I can opt out of installing unnecessary toolbars and other spyware/adware that comes with free Windows software. But does the Average Joe Windows user know that? Definitely not; the Average Joe just clicks through the install dialogs until the program he wants is installed, not knowing that he also just sold his soul to the devil by installing all manner of malicious spyware on his system.

So, I conducted an experiment.

I installed Windows XP on a virtual machine, and installed only a small selection of software that the average user would likely use, and went with all the "Recommended" installation options for every program installed. Altogether, I only installed 9 programs, and most of those were something everybody can say they've installed: instant messengers.

The Experiment

Memory: 256 MB
HDD Space: 10 GB

I installed a fresh copy of Windows XP, installed the VirtualBox guest additions, and used this as the baseline for a "vanilla" Windows XP installation -- a fresh, clean, pure instance of Windows with nothing really installed on it.

[click for larger screenshot]

In our fresh vanilla Windows XP install, we see the default desktop, the start menu, the Task Manager with few enough tasks in it that we don't even need a scrollbar, and a default Internet Explorer 6 window with MSN as its homepage.

Then, I started installing some software.

Installing Software

Then I installed Yahoo! Messenger 9.0.0.2162 - this installed Yahoo Messenger, put an icon on my desktop, installed the Yahoo! Toolbar, and set my homepage and search engine to Yahoo.

Then, Windows Live Messenger 2009 (Build 14.0.8089.726) - this one didn't install a desktop icon, but it set my homepage in IE back to MSN.com and changed my search engine back to Bing.

These are the three most common instant messengers that most people use. So, I went and installed other essential software:

Sun Java Runtime Environment, JRE 6 version 15. Java also took the liberty of installing the Bing Toolbar in my Internet Explorer.

Then I downloaded WinZip 12.1 Free Edition. Windows XP comes with built-in support for zip files, but Average Joe is bound to come across archives of other types and will be told to get WinZip. WinZip installed for me the Google Toolbar in Internet Explorer.

Then, the Adobe Flash Player 10.0.32.18 - this is, so far, the only piece of software that installs what it says and nothing more. It's also the only thing I've installed in my experiment that installed only what I wanted it to.

Finally, I got a couple extra instant messengers installed: Skype 4.1 and ICQ 6.5 - Skype installed the Google Chrome web browser and ICQ installed the ICQ Toolbar and set my homepage and search engine to ICQ.

At this point, I have only installed 8 programs; 8 programs that Average Joe End User is likely to install. Using the default options on all the installers, my system is now fscked up already. But why stop there? Average Joe also needs an antivirus suite, with all this scare going around about viruses.

So, Average Joe installs AVG Free because Average Joe is a cheapass who can't afford Norton or McAfee. AVG may be well-intentioned, but that didn't stop it from installing the AVG Toolbar "Powered by Yahoo!" into my Internet Explorer as well as changing my search engine to AVG Search.

So, what's the damage? 9 programs, and this is what my system looks like:

[click for larger screenshot]

My Task Manager list has grown exponentially; I have to resize it vertically as tall as it will go, and even then there's still a scrollbar. And do you see the IE window in all that mess? It's completely being murdered under the weight of the 7 different toolbars taking up HALF of the vertical screen real estate.

This is only 9 programs being installed. For a quick list, here they are again:

1. AOL Instant Messenger
2. Yahoo! Messenger
3. Windows Live Messenger
4. Sun Java
5. WinZip
6. Skype
7. Adobe Flash
8. ICQ
9. AVG Free

[click for larger screenshot]

This, THIS is why Windows sucks. All Windows software installs all this crapware along with it, and all this crapware competes with each other (just look how many times my search engine had been changed).

This is the list of toolbars in IE, from top to bottom, which take up 50% of my 1024x768 vertical resolution:

1. (IE Menu Bar)
2. (IE Default Toolbar)
3. (IE Address Bar & Links)
4. AIM Toolbar
5. Yahoo Toolbar
6. Tabbed Browsing Toolbar
7. Google Toolbar
8. Bing Toolbar
9. ICQ Toolbar
10. AVG Toolbar

19 cookies in Internet Explorer. Cookies!!!

The only thing AdAware found were cookies left by ad banners. No adware? No spyware? Are you kidding me!?

So, how do the startup programs look? Well, I'll tell you that rebooting this virtual machine is miserable. With all these programs starting up when the desktop loads, nothing productive can be done for a full 10 minutes. Here's the breakdown:

Startup Items

After this, the startup items were:

• Current User Registry Items
  • AOL Instant Messenger
  • Windows Live Messenger
  • Yahoo Messenger
  • ICQ
  • Skype
  • Google Toolbar Notifier
• System-wide Registry Items
  • AVG Tray
  • Microsoft Default Manager
  • Sun Java Update Scheduler
  • VBoxTray (VirtualBox Guest Additions)
• Start Menu Items
  • WinZip Tray

It should be noted here that free, open source software, almost never comes with crap like this. If you stick to fine programs like Firefox and Pidgin you can install them without worrying about what other crap they'll bring along with them.

I hate Windows.