Believe it or not, even those of us who are professionals at this kind of thing can get hit with a spyware and virus mess.  Recently, through my own laziness on my gaming PC, I got hit with several Trojans and pieces of spyware at once – along with that most evil of malware, a rootkit.  The first indication I had that something was going on was when I noticed that my results in Google were being directed to false websites.  When I opened one of the search results, even in a new tab or window, there was an random chance of being redirected to another page.

In my attempts to repair the damage done to my system, I revisited my toolbox and updated the programs that I use.  For this article, I’m just going to list some of the tools I used to give everyone a good list of reliable options.

There are also free online virus scanners on sites like Panda Security, Trend Micro and BitDefender’s bdtools.net. Of course, the best practice is to avoid malware in the first place.  Resident antivirus applications like Avast! and steering clear of sketchy sites and software will help keep the computer running smoothly.

Finally, nearly any boot floppy can be added to a bootable USB drive.  This comes in handy to use the simple DOS format and fdisk tools, or even something like the NetBootDisk (which I use at work all the time to image PCs from network drives).  An invaluable tool to convert the floppy disks to bootable image files (or at least, the program I use) is WinImage. The program can create .img files out of any floppy disk, and can even be used to create larger floppy images than the standard 1.44 mb.  That comes in handy when dealing with bootable floppy sets, as in the old Norton Partition Magic.

Once the image file is acquired, the Grub4DOS menu entry for it is relatively simple to accomplish.  The following is the entry I used to add a Killdisk boot floppy to my USB menu.

title Killdisk
find –set-root /kdisk.img
map –mem /kdisk.img (fd0)
map –hook
chainloader (fd0)+1

That same setup can be used for any floppy image, substituting the title and filenames to suit.

As for installing Grub4DOS, it’s actually very easy.  The only difficult part of getting it to work is making the drive bootable.  The easiest way to do that is to use the HP USB format tool, which I’ve uploaded here.  Just make a DOS boot disk (or find the files necessary) and use those files with the USB format program to make it bootable.  The formatting program, of course, will erase the USB drive, so make sure to back it up first.

Once the drive is bootable, download the newest Grub4DOS and extract it (not to the USB drive).  Copy the grldr and menu.lst files to the USB drive.  The menu.lst holds all the settings for how to boot the programs on the drive.  My menu.lst is uploaded here, for an example.  More notes on Grub4DOS can be found here.

Many Linux distributions can be reconfigured in order to boot directly from a removable USB drive.  Even the most popular distributions, such as Ubuntu, have a method for fitting them on a USB drive.  However, the versions I chose for my drive were picked because of the specific tasks they provided and the fact that they don’t take up much storage space.

Damn Small Linux is a distribution optimized to 50 megabytes in size that contains a lot of command line tools and the ability to get to network shares.  It is a functional operating system, allowing things like music and video playback – though I don’t utilize them much when trying to use DSL as a repair tool.

To add DSL to a Grub4DOS boot menu, first download the ‘embedded’ version from the website.  The file for the current version as I write this is dsl-4.4.10-embedded.zip.  Put the linux24, minirt24.gz files and the KNOPPIX folder on the USB drive.  If Grub4DOS is already installed on the drive, then add the following lines to menu.lst:

title Linux: DSL
find –set-root /grldr
kernel /linux24 ramdisk_size=100000 init=/etc/init lang=us apm=power-off vga=791 initrd=minirt24.gz nomce noapic qem quiet BOOT_IMAGE=knoppix frugal
initrd /minirt24.gz

The title is customizable, it is just what shows up on the menu when booted.  It should copy and paste correctly, but just in case it doesn’t – the third line starts with ‘kernel’ and ends in ‘frugal’.

Puppy Linux is a Linux distribution created from scratch – i.e., not based on another version (as DSL is based on KNOPPIX).  It has a similar philosophy to DSL, and is intended to be a fully featured operating system that runs from a small footprint.  Download the ISO file for the newest version from the website, and open it with a program like WinRAR.  Extract the initrd.gz, pup_XXX.sfs (the X‘s are the version number), and vmlinuz files to the USB drive.  Create an empty file called USBFLASH on the drive.  Again, if Grub4DOS is installed, add the following to menu.lst:

title Linux: Puppy
find –set-root /grldr
kernel /vmlinuz root=/dev/ram0 initrd=initrd.gz PMEDIA=usbflash PKEYS=us acpi=off nopcmcia
initrd /initrd.gz

The title is customizable, and the third line starts with ‘kernel’ and ends with ‘nopcmcia’.

SystemRescueCD is a Linux system designed to boot and run from CD, and it contains multiple tools for repairing and recovering from various system errors.  Those include software such as partition editors and file system tools.  Download the ISO file for the current stable version.  The website has instructions for installing the OS by itself on a USB drive, but I extracted the maps folder and the rescuecd, rescuecd.igz, and sysrcd.dat files to the drive.  Add the following lines to menu.lst:

title System Rescue CD
find –set-root /grldr
kernel /rescuecd root=/dev/ram0 initrd=rescuecd.igz init=/linuxrc video=ofonly setkmap=us vga=0 looptype=squashfs loop=/sysrcd.dat dokeymap scandelay=10 cdroot=/dev/sd splash=silent dostartx
initrd /rescuecd.igz

The third line starts with ‘kernel’ and ends with ‘dostartx’.

I mentioned Trinity Rescue Kit in my initial post, but I have since dropped it since I never used it and was never fully satisfied with how I had it running on the USB (it had a lot of errors – my fault, not the distribution).  More information is available at the official website.

Also, for more information about setting up other Linux versions to boot from USB drives, check out Pendrivelinux.com.

I noticed last time that I didn’t mention how to set up BartPE on a USB drive, and added a link.

Next time: How to make floppy disk images and boot them from USB with Grub4DOS, and how to set up Grub4DOS to boot a USB drive.

I use most of the plugins that are packaged with PEBuilder in my BartPE builds.  The ones that I remove are usually plugins that are necessary to remove for added plugins to work.

• XPE
  This is the aforementioned plugin that provides the shell and some networking and other tools.  XPE makes the BartPE environment look and feel like Windows XP.
  
• Active Killdisk
  Killdisk is the application that we use at work to wipe hard drives before sending them back to the leasing company.  The Windows version of the application allows us to wipe multiple drives at once, and running it from BartPE makes it possible to kill all the drives in the system.
• LANDesk Remote Control Viewer
  LANDesk is the solution that we use at work for application deployment, remote support, and asset tracking.  This plugin wraps the remote control viewer that is a part of that product.  I wrote this one myself with some help from the PluginBuilder.
• Foxit PDF Reader
  Just a lightweight PDF reader in case I needed to open any documentation while working on a PC.
• Deepburner
  
• PuTTY
• IrfanView
  The plugin files for Deepburner, PuTTY, and IrfanView are included with PEBuilder.  All that needs to be done is to download the respective applications from the manufacturers’ websites.

I mentioned PluginBuilder above.  It works by detecting all the registry keys and extra files used when running the application, allowing the collection of those files and generation of the INF files required for a plugin.  I’ve only used it once, and I had to do a little INF hacking to get it to work with XPE, but it may be worth a shot if you have a hard time creating a custom plugin.

Ever since BartPE was created, there have been several side projects and improvements built on top of the architecture.  Notable projects include:

• Reatogo-X-PE
• UBCD4Win
• Winbuilder
  This one isn’t technically based on BartPE, but it’s a tool that can build many different similar projects.  I’m not very familiar with this one.

I completely forgot to explain how to actually add this to the USB drive. Click here to go to a thread with all the nuts and bolts.

Coming up next in Part III: Booting various Linux distros from USB, and how I set up the specific ones that I use.

For those of us who have been fixing computers, BartPE has been part of our core toolkit – or at least it has been a big part of mine.  Every time I run into a computer that has an issue with booting into the operating system, I turn to BartPE and the tools that I have inside it.  I’m not going to even attempt to make this a comprehensive guide to BartPE, but I’ll try and link to a pile of tools and plugins, as well as describe how to make it work on a USB drive.  And at the end of this series, I’m going to tie it all together and show how to set up Grub4DOS to boot to all the tools I described.

On my USB drive that I have set up with all the boot tools, I have two separate BartPE installations.  The major difference between the two is that one uses the standard Nu2Menu and can run in systems with only 256 megabytes of RAM, and the other uses the more sophisticated XPE plugin system and requires at least 512 megabytes of RAM.  As standard memory sizes increase on our computers at work, the memory required for the XPE plugin becomes less of an issue, and the only difference now is the time required to load.  I usually stick to the XPE version, since any of the custom plugins that I’ve written I’ve only added to that version.

Bart Lagerweij is the creator of the application, as well as a lot of the plugins that come with it.  Most helpful in the initial creation of a BartPE installation is the PEBuilder, available at the author’s page.  Basically, if you follow the instructions, put the plugins and drivers in the folders where they are meant to go, it’s very easy to run the wizard and burn a bootable CD.  The CD definitely works just fine, but if you’re like me and just want to have fun and add multiple tools to one USB drive, then there are a few more steps.  It’s also possible to create a multi-boot CD with the Bootable CD Wizard, but I’m not going to cover that here because it’s outside the scope of this article series.

Drivers are a little tricky.  Part of the reason that my XPE version of BartPE is so large is that I’ve included lots of drivers for network and storage, allowing me to use it on a wide variety of systems.  However, I really should cut down on the number of drivers I have included (at least for the versions I use at work), since we have a known number of computer models active at any given time.

If you still want to include a lot of drivers in your setup, the place to go is Driverpacks.net.  Download the Base pack from the website, and install it to your hard drive in a directory where you’ll remember, like C:\driverpack.  From that directory, launch DPS_BASE.exe.  On the left hand side of the window that comes up, click UpdateChecker.  On that screen, select the LAN, WLAN, and MassStorage packs, and click Update Selected, which will then download the newest version of those driver packs. Then click the Location item in the left hand side (under Settings), select BartPE as the installation type, and click Browse.  Find the plugin directory where you installed PEBuilder (such as C:\pebuilder3110a\plugin).  Then click DriverPacks under Settings, select the three driver packs you need and click Slipstream.  When you create your BartPE build, you will need to enable the DriverPacks.net plugin.

BartPE comes with a ton of default tools in the standard builder application.  I’ve decided to break up this article into two separate columns.  Next time: extra plugins, how to boot BartPE from USB, and other projects based on BartPE.

At my office, I use a handful of tools that require me to boot computers to something other than the internal hard drive.  I have multiple BartPE builds, along with different Linux distros and some old DOS boot tools (like Partition Magic). 

Specificly, my USB thumb drive has the following installed as bootable:

In 2007 the company I work for was hit by a network-wide virus.  It spread, ironically, through an unpatched vulnerability in our Symantec Corporate Edition’s LiveUpdate – basically our anti-virus was spreading the virus from computer to computer.  It was easily patched, however the remnants of the virus still persist even now.

You see, another vector that this virus used to spread itself is through the network drives mapped on the computer.  I would drop an autorun.inf and setup.exe into all the mapped drives on the computer, so that it would auto install the virus every time the computer connected to that drive.  Pretty low-tech virus, it didn’t even do anything but interfere with network traffic.

Nearly every user in our company has a folder on one of our file servers that gets mapped according to settings set in a domain logon script.  However, every once in a while, this home folder will be treated by Windows as if there is an autoplay set up for it.  For a while, the solution for that was to delete the autorun.inf file that remained after the virus was cleaned up.  (An autorun.inf that points to setup.exe will cause Windows to check first in the same directory for a setup.exe; if it doesn’t find it there it will run the setup.exe in the system32 folder under the Windows directory.)  Mostly those autorun files have been removed.  Now the users that report this issue have a trickier problem.

In the registry there are a couple of keys buried deep that hold the key to this issue.  There is a key named ‘MountPoints2′ which holds information concerning the drives that are mounted to your Windows session.  Most commonly it is located under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2.  To solve the issue where the drive tries to autorun even though it shouldn’t, look for the server name under the list of mount points (the subfolders under MountPoints2).  Remove the _AutorunStatus from the drive with the problem, as well as any subfolders.  You may be able to just remove the key for that drive entirely, but of course always back up everything before you meddle in the registry.

One of the biggest issues we face at my company (and I’m sure pretty much most companies) is how to balance the capability to work remotely for users with laptops against the security and redundancy of their data.  Everyone with a domain account gets a certain amount of space on our file servers, which get backed up nightly.  This allows us to guard against accidental deletion and avoid risks of hardware failure that come with storing things on a local drive.

However, the push lately is to switch as many people as possible to a laptop, so that management can squeeze as much working time as possible out of the employees.  Of course, as a member of the IT department I am opposed to giving everyone a laptop, because of the risks and costs associated with supporting them instead of workstations and desktops.  In order for these employees to be able to work from home or remotely, they of course need to have all their data stored on their hard drive (because the VPN is too slow - that dreaded concept).  One of my challenges is coming up with a better way of getting that data backed up to the file servers and backed up with the rest of the files to tape.

Our nightly backups on the server run through a Tivoli system and a large tape library (for most of our locations, we have a library or tape drive on the premises, though some sites share a library over the WAN).  This relies on a client-server architecture and is designed to work with a tape library.  It really isn’t applicable to backing up end user systems.

The process we have in place right now (and I don’t even consider this a process) is just a VBScript that runs WinZip through a command line to back up the relevant folders to the users’ network shares.  It’s rather inefficient, has significant drawbacks (such as not being able to get any file that is flagged as ‘in use’) and relies on the end user to purposefully run a backup when connected to the network.

This is not what I would consider an ideal situation.  What I’d like to put in place is something where the client on the laptop will wait for a connection to the network share, then send a backup to the server.  That way, the user is not responsible for keeping their data backed up.  Any responsibility that I can relieve the end user of is a win in my book.  My company isn’t convinced that this is enough of a priority to spend money on (the software cost isn’t the issue, I could write it myself or find several suitable open source projects, but they don’t want to commit the resources to get it in place).

Where does this leave me?  I have to find a solution that addresses as many of the drawbacks of our current system without incurring more costs in time or money.  This of course sucks – a lot.  Any suggestions?  I’d love to deploy something along the lines of Bacula.

During the course of my job, quite a lot of the time I have to deal with old Access 97 databases.  (It’s a long story involving the company’s strange money-based reluctance to upgrade anything software related.)  What this means, however, is that I get to spend time figuring out ways to interact with those databases to increase usability and productivity while avoiding risks that could corrupt the databases.

In a perfect world, we would be able to migrate everything we have over to SQL Server databases, and create web interfaces to interact with them.  We have been pushing for this to happen ever since I came on board, but since we’re pushing from the bottom up, it’s a slow process.  In the meantime, I try and figure out how to automate a lot of my own tasks involving these databases.  My latest project was to drastically speed up serial lookups in our leased hardware database.

Normally, the process to look up a computer in our hardware database involves opening up the file in Access and using the built-in form to query.  However, as you may have guessed, this can be slow and annoying.  I decided I would write a script that would allow me to do a quick search for a computer by serial number (the database is also searchable by end user, but that happens less often and I haven’t put the work in to making this script do both as yet).  And as I am a huge Launchy fan, I figured I could integrate my script into it for even quicker access.

As I am not a native vbscripter, most of my knowledge comes from my own research and ‘find-it-as-I-need-it’ searches.  For this I decided I needed to learn how to query Jet databases and also read command line arguments in a vbscript, both of which I had never done before.

It’s actually pretty easy to grab the command line arguments, just by using Wscript.Arguments(i).  All I did was write a check to make sure that there actually is an argument passed, then take that and query the database with it.  It then just pops up the number of records it found, followed by each of them in sequence.  As this is just a hashed together script, I haven’t made it super secure or commented it or anything, but here it is in all its mediocre glory.

Set objconn = CreateObject(“ADODB.Connection”)
Set objrecset = CreateObject(“ADODB.Recordset”)

Const adOpenStatic = 3
Const adLockOptimistic = 3
Const ForReading = 1

objconn.Open _
    “Provider = Microsoft.Jet.OLEDB.4.0; ” & _
        “Data Source = xxxxxxx.mdb”
if Wscript.Arguments.Count > 0 Then
    serial = Wscript.Arguments(0)
Else
    serial = “No query entered.”
End If

objrecset.Open “SELECT * FROM xxxxxxx WHERE Serial_Number LIKE ‘%” + serial + “%’”, objconn, adOpenStatic, adLockOptimistic

msg = “Retrieved ” & objrecset.RecordCount & ” record(s).”
Wscript.Echo(msg)
Dim result
if objrecset.RecordCount > 0 Then
    if objrecset.RecordCount = 1 Then
        Wscript.Echo “Model: ” & objrecset(“Type_Model”) & VBCrLf & _
            “Serial: ” & objrecset(“Serial_Number”) & VBCrLf & _
            “User: ” & objrecset(“Equipment_Owner”) & VBCrLf & _
            “Lease Ends: ” & objrecset(“Lease_Exp_Date”) & VBCrLf & _
            “Status: ” & objrecset(“Status”)
    Else
        Do Until objrecset.EOF
            Wscript.Echo “Model: ” & objrecset(“Type_Model”) & VBCrLf & _
                “Serial: ” & objrecset(“Serial_Number”) & VBCrLf & _
                “User: ” & objrecset(“Equipment_Owner”) & VBCrLf & _
                “Lease Ends: ” & objrecset(“Lease_Exp_Date”) & VBCrLf & _
                “Status: ” & objrecset(“Status”)
            objrecset.MoveNext
        Loop
    End If
End If

I’m not sure if this really fits on my project blog, but I got an awesome Kodak Z712 digital camera for Christmas, so I’ll be actually able to take pictures of any of the physical projects that I work on from time to time. (I’ve been known to dabble in case mods and woodworking from time to time.)

If you’re wondering why this post looks familiar, I was having an issue with the crosspost to Livejournal that I’m using. To make this not a complete waste of a new update…

I haven’t used the camera as much as I’d like so far. Mostly I’ve just screwed around with it. I have to get another rechargeable battery for it, but that’s not what’s holding me back. Part of my issue is that it’s boring to take pictures of the inside of my house, and since it’s so blooming cold outside up here (Olean, NY) that I haven’t managed to get out as much as I’d like. Soon I’ll be able to pop pictures up here, though; I promise.