Showing posts with label Boot. Show all posts
Showing posts with label Boot. Show all posts

Thursday, June 3, 2010

Change of hard drive - cloning/restoring with BartPE/DriveImageXML

The following is not particularly ground breaking, just a note to self on how to do a HDD (hard disk drive) backup and restore as hassle-free as possible. My choice of tool was a BartPE CD that I built including the disk cloning tool DriveImageXML (or DIX) as a plugin.

Making the clone file was the easy part - DIX simply lets you make a clone file to a USB drive from within a running Windows OS. Getting the new HDD to boot after restoring the clone file to it was a little trickier. This is what I ended up doing
  1. Install DIX on the old drive running Windows, then creating a backup (clone) of the whole partition to a file on a USB hard drive. Yes, you can actually do that while Windows is running off of the same disk!
  2. Removed the old HDD and installed the new HDD in the computer (since it was a laptop with only one HDD bay, I did not have the option of leaving the old one in until the data was transferred).
  3. Partitioning was a little tricky. Unless you find a partitioning plugin for BartPE, you will have to do it from some other bootable media. I first tried an old Win98 command-line bootable CD, which only formatted around 130Gb (my drive was 160). I ended up booting into a Knoppix Linux boot CD and create a standard, active (=bootable) partition by running its fdisk from a command shell after issuing a su to gain administrator access. The partition was marked as a Linux type partition, which does not matter since DIX will overwrite it anyway, it just does not know how to create the partition. I might also have created the partition by booting into a Windows installation CD, creating the partition and then abort further installation.
  4. Now booting into the BartPE CD, I ran DIX again on the new disk, restoring the image from my USB disk. To get Bart to see the USB disk, make sure that it is on and connected already at boot.
  5. Booting from the new disk was the trickiest. When attempting to boot from the new disk, only a blank black page with a blinking cursor appeared. I had to boot into the Windows installation disk and choose Recovery console. From there, I ran fixboot, fixmbr and bootcfg /rebuild. Seems like my hard drive lacked both a working master boot record (MBR) and because my old disk had a utility partition that I had not bothered taking with me, the partition entry in boot.ini was also wrong.
Finally, my new disk booted with all the old data and programs as it was before.

Tuesday, March 10, 2009

Conficker/Downadup removal - safe mode gives bluescreen

This is the most useless way to make money that I know of: Fighting viruses. As if there aren't enogh real technical challenges to play with.

A customer was hard hit by the Conficker/Downadup virus the other day. The B variant didn't take too long to figure out how to remove, but a couple of the affected computers would not boot to safe mode, yielding the bluescreen of death (BSOD). No virus removal software I tried was able to detect the junk process causing this, so I had to research a little on my own.

Update 14.3.09:
BitDefender now has a removal tool that they claim will also remove the .C variant. I haven't tested it though.

The Downadup.B and .C variants are well described at Symantec's and others' websites, so I won't repeat that. I'll just give a practical short work list that worked for me and left my customer's computers virus free:

Determining if you are infected by Downadup.B:
There's a couple of simple steps to give you a good indication of whether you are affected by the Downadup.B. One or more of these bullets indicate that you are infected:
  • You are not able to browse to sites like www.symantec.com or www.microsoft.com. Other non-antivirus websites, like your local newspaper webpage works fine.
  • You have several entries in Scheduled Tasks - like "at", possibly with a number behind
  • The obvious one: Check your antivirus software logs to see if the virus has been identified
Quick cleaning of Downadup and securing from reinfection
Here's how I cleaned each computer and managed to keep it from being reinfected by other infected computers on the network (although they should all have been physically disconnected from the network):
  • Physically disconnect each computer on your LAN
  • Boot to safe mode without network support (if you get a bluescreen - see below)
  • Change passwords of all local users that have "guessable" passwords - see list on Symantecs virus description page. Gotcha: The virus also guesses existing usernames on the system, even backwards or repeated two times, as possible passwords.
  • Make sure Windows Firewall (or equivalent) is on
  • Make sure you do not allow autorun from USB sticks etc. (see below)
  • Run the removal tool from Symantec (or other tool of your choice)
If you want to remove manually, I found this description from Microsoft to be one of the most helpful if you want to manually remove or check that all traces are gone.

With all the above steps done, you are ready to connect to the LAN again and try to reboot into normal mode.

Booting to safe mode results in bluescreen
This means that things get a little tougher. Symantec did not have a removal tool for the Downadup.C virus when I needed it (Update: BitDefender has - see note above). In addition, the Downadup.B removal tool was killed the same instance you try to start it. Same goes for many antivirus packages etc..

To solve this, you need to find a clean donor computer with the same OS and probably as identical hardware as possible. Export the following regkey to a memory stick (that you have verified is clean before plugging it into your clean donor computer) or similar and run it on the infected computer:

HKLM\System\CurrentControlSet\Control\SafeBoot

Then quickly reboot into safe mode (F8 upon reboot), in the hope that the virus will not redelete the key before you manage to take down your system for reboot.

Removing the Downadup.C
You have now managed to boot into safe mode (F8 during boot). The virus is still there, you will need to look for it manually, unless there's a removal tool by the time you read this. On my two infected computers where I got bluescreen upon safe mode boot, I opened Windows Explorer in c:\windows\system32, sorted the files on date and looked for the most recent DLLs or EXE files I could find. There was only one DLL file created within the last week, and in both cases it was named a random set of characters. Going to properties, I verified that there was no Microsoft version information - hence, this file would most probably not be to my benefit. Just to make sure, I renamed the file extension to VIRUSSUSPECT and rebooted. The virus was gone, and I had the proof I needed to delete the file I first renamed.

Beware that the Downadup.C also weakens security that you do NOT get restored only by removing the virus DLL. Again, review the Symantec (or other) descriptions of the virus and take action accordingly.

Good luck, and good hunting!

Friday, August 25, 2006

After-OS RAID install on a Dell PowerEdge 2800

Task: A Dell PowerEdge 2800 server with Windows Server 2003 was to have its one physical hard disk drive (HDD) upgraded to a multi-disk hardware RAID system.

Problem:
I want to use a disk cloning system (like Norton Ghost) to transfer an exact copy of the standalone HDD to the new RAID disk system. This poses two problems:
  1. The system would not boot, because the SCSI driver of the RAID controller was not installed in the kernel of the OS. After the clone, you could of course run the Windows 2003 setup CD and install the SCSI driver from a floppy disk, but it has to be a physical floppy - if you don't have that or even a floppy drive, you're stuck. Personnally, I chose another approach that I find more convenient (see below).
  2. On the PowerEdge 2800, the Raid controller is a chip that, when installed, actually takes over the control of the physical disk bays of the computer. This means that no clone can be made because the standalone HDD and the RAID volume can not coexist on the server.
Needed: (You could probably do this with other tools as well, but this is what I had available)
  • A Ghost network boot disk (CD or floppy) for your server
  • A spare server
  • A Ghost network boot disk (CD or floppy) for your spare server
  • A LAN with a working DHCP server
  • A driver for the SCSI RAID controller (not necessarily on a floppy)
Successful procedure:
  1. Still running the OS from the original HDD (that is to be the source for the RAID disk), the SCSI driver for the RAID controller were installed. On Server 2003 it will ask you to install the device first (on the good old NT4 Servers, this was easier to accomplish). On my server however (a Dell PowerEdge 2800), there are two on-board SCSI controllers, whereof only one were in use, making the following possible:
    1. Open the unused controller from the Device Manager and choose Update Driver (be very sure you have chosen the unused one - otherwise you may not be able to boot again)
    2. Click Have disk and uncheck the option to only show compatible drivers. Locate the RAID controller's driver and select it to replace the original SCSI driver for this unused controller. This will of course render this unused SCSI controller useless for now, but it installs the driver into the OS so that the RAID controller later will be recognized and handled in boot.
  2. Install the physical parts into the computer - including the RAID controller (chip) and the disks it will control
  3. Set up the RAID volume on the RAID controller. This is done during boot. The controller tells you to push a function key to access RAID controller options/setup.
  4. You must also enter the server's CMOS setup and set the RAID controller as the boot device.
  5. On most systems you can now boot from a Ghost boot disk and image the old HDD to the new RAID volume. As mentioned, this does not work on the PowerEdge. As a workaround, a spare server was used. The old HDD was installed there. Now the following steps were taken:
    1. The now RAIDed server was booted with a Ghost network boot floppy, selecting TCP/IP and Slave from the Ghost menu. Make a note of the DHCP given IP address. If this goes wrong, check that you have a DHCP server running.
    2. The spare server was then (afterward - important) booted with a Ghost network boot floppy, selecting TCP/IP and Master from the Ghost menu
    3. The IP of the RAIDed server is given as the Ghost slave to control
    4. The RAIDed computer is ghosted over the net, and will, because of the previously installed RAID controller SCSI driver, boot nicely when finished.