This Hard Drive, Which PC?

Technorati tags: PC maintenance

Let's take two unrelated ideas and draw them together...

If you take Fred's brain and transplant it into Martin's body, have you performed a brain transplant on Martin, or a body transplant of Fred?

If the processor is your computer's brain, then the computer's hard drive is your mind.

Do you think the second sentence should have been "...the computer's hard drive is the computer's mind"?  Both statements are true, but from your perspective, the first may be more important.

Why might this matter?

The practical importance of this arises if you take a hard drive out of a PC, and then come back after a while with that hard drive in your hand, and a collection of PCs without hard drives on the bench.

It's easy to tell who the hard drive belongs to, because the files it contains will be full of cues.  But which PC belonged to that particular user?  Less easy, because all information uniquely linking that computer to the user is on the hard drive.  Unless you have kept some other record, e.g. serial number tracking, ownership sticky notes, arrival photos etc. you could have a problem.

Solving this problem

On old PCs that don't auto-detect hard drives, you can examine CMOS to look for CHS geometry etc. that matches the hard drive in your hand.  But new PCs generally don't persist CHS or other hard drive parameters in CMOS; they re-detect such devices on POST instead.

You can examine the hard drive's files to look for links to the particular hardware, e.g. an OS product key that matches a case sticker, or a collection of device drivers that map to the rest of the PC hardware. 

That is not as easy as looking for cues to the user of the PC; you may have to bind registry hives and look for cues in there.  You could do that implicitly by CDR-booting into Bart and using RunScanner to wrap Regedit or other tools so they map to the hard drive installation's hives, or you can do that explicitly by running Regedit from any suitable host OS, and manually binding the hard drive's hives under HKLM.

Don't boot in the wrong PC!

Whichever approach you use to examine the hard drive, it's crucial not to allow the hard drive to boot in the wrong PC, in all but the most trivial of OSs.  DOS would be safe, but anything more complex is likely to go wrong for various reasons.

Win9x will use Vmm32.vxd as the core driver set upon which all other drivers are loaded, and that core driver code was derived from the particular PC hardware that was in effect when Windows was installed on it.  If it's incompatible, then the PC will crash before the OS has reached sufficient "consciousness" to Plug-n-Play. 

This is a common crisis when changing the motherboard under a Win9x system, and can be solved by rebuilding a new Vmm32.vxd appropriate to the new hardware.  Yes, there's one on the installation disk, but it's an empty stub upon which Windows Setup builds the "real" file at install time.

You could rebuild Vmm32.vxd by re-installing the Win9x over itself, but that is messy; breaks patches and subsystem upgrades, loses settings, and so on.  Or you could do a fresh install of Win9x on a different hard drive, harvest the new Vmm32.vxd from there, and drop that into the "real" hard drive from DOS mode.

Having got this far, Windows should now boot to the point that Plug-n-Play can detect the rest of the new hardware and nag you for drivers.  Expect problems from hardware-specific code that was not installed as drivers, and is thus not disabled when PnP detects the hardware as no longer present - think packet-writing CD software, modem fax and especially voice software, hardware-specific Properties tabs added to Display Settings, etc.

XP, Windows 2000 and older NT-based OSs may fail in a similar way, though the installation-time hardware-specific code file will he the HAL (Hardware Abstraction Layer) rather than Vmm32.vxd - same difference, in other words. 

You will probably have to do a repair installation to fix this, with similar impact as installing a Win9x over itself.  I'm not sure if cleaner fixes would work.

XP may have another surprise for you, if you aren't BSoD'ed by a HAL compatibility STOP error; Windows Product Activation may see the changed PC as "too different", and trigger the DoS (Denial of Service) payload.

Vista doesn't have the same HAL mechanism as earlier NT, so it may start up without a STOP error, but you'd still have the Product Activation payload to contend with - as you would with MS Office versions XP and later, regardless of OS.

I can't tell you how Linux, BSD or MacOS (pre- or post-BSD) would fare when booted in the "wrong" computer, but I suspect similar issues may apply.  Aside from artificial crises caused by deliberately malicious product activation code, you may still have the core problem of needing hardware-specific information to boot the logic that can respond to altered hardware.

Safety First

If you are not certain that you're putting the hard drive in the correct PC, then you should back up C: in such a way it can be restored as a working OS, if mistakes lead to a PnP or product (de)activation mess.

For a Win9x, that's as simple as copying off all files from the root directory, all of the OS subtree, and (easiest) everything in "Program Files".  For best-practice on WinME, you should preserve the _Restore subtree too.  These are the only contents of C: that should be affected by the OS "waking up" in the wrong PC.

For NT, it's messier, because Windows 2000 and later (I haven't tested earlier NT) will not boot after a file-copy transfer from one hard drive to another, even if you meticulously include all files.  So you're obliged to do a partition-level copy (e.g. save C: as a partition image via BING) to maintain undoability.

Should You Detect Old Malware?

Technorati tags: Malware, Safety, Security

We've gone from thinking of software as a "durable good" to evolving under selection pressure.  This certainly applies to malware and blacklist-driven scanner countermeasures, which are assumed to become either extinct or irrelevant over time. 

Who needs old scanners?

You may want to keep an old scanner if it still detects stuff other scanners can miss, or if it was the last version that ran in your environment - though as an "extra" on-demand scanner, not as sole resident protection, of course.

For example, Kaspersky's CLI scanner no longer runs under Bart, and I haven't adapted AdAware 2007 (which I don't particularly like) to run in Bart either.  There are still manual updates for AdAware SE, so that's still "current", and Kaspersky CLI still works in Safe Cmd.  However, I may want the safety of formal scanning with Kaspersky CLI, and for that, I'd need the last "old" version and updates that still worked from Bart.

Another example is McAfee's Stinger.  Just as an "old" Kaspersky CLI may find stuff other updated scanners will miss, so it is with the even older Stinger - it's particularly good at catching TFTP-dropped malware and some bots, both of which are likely to be found in an NT that has not patched RPC against Lovesan et al.

F-Prot's DOS and Win32 CLI scanners are also discontinued, i.e. no further updates, but are still useful.  Specifically, these scanners will often detect "possibly new version of ... Maximus", and sometimes that rather loose and false-positive-prone detection still finds things others miss.  These scanners also find other false positives unrelated to Maximus, so handle with care.

Does old malware matter? 

Firstly, you may encounter vintage malware on vintage systems and diskettes (e.g. boot sector infectors on old DOS or Win95-era PCs, old MS Office macro infectors in "documents" from old systems).  Malware of that era were mostly self-contained and fully automated, and often had destructive payloads, so they will still bite... so you'd want to detect them.

Secondly, think of the spammer equivalent of the guy who still uses a PC built from old parts running MS Office 2000 on Windows 98, because these old feeware programs pre-date automated defence against piracy - i.e. no software budget.

A less-obvious feature of botnets is that those who own them, don't want folks controlling them for free.  So if you want to send spam through a modern botnet, you will probably have to find someone and pay them.

On the other hand, old bots that are still in the wild, may have been cracked so they can be operated for free - or may simply pre-date the rise of malicious info-business and thus lack modern mechanisms to block control.  In which case, our impoverished spammer may use these instead - so it may still be prudent to detect and kill them off, especially in the context of poorly-patched or defended systems (e.g. unpatched Windows 2000, no firewall, outdated or missing av).

XP Repair Install

Technorati tags: XP, install

Re-installing Windows XP isn't a good idea as a blind first step in troubleshooting problems, but there are specific contexts where it is necessary, as the cleanest way to "make things work".  One of these contexts is after a motherboard change that invalidates XP's core assumptions, typically causing a STOP BSoD on any sort of attempted XP boot (from Safe Cmd to normal GUI).

This is the situation that edgecrusher is in, as posted in comments to the previous post in this blog, and this post is my response.

Before you start

Firstly, I'm going to assume you have all the necessary installation and drivers disks, have your XP product key or retrieved this via Nirsoft Produkey or similar, excluded malware, and verified RAM overnight e.g. via MemTest86 or MemTest86+ and hard drive e.g. via HD Tune. 

Make sure the edition (OEM vs. retail, Home vs. Pro, etc.) of the XP installation disk you will use for the repair install is one that matches your product key, that the disk actually has the ability to do a non-destructive install (as many OEM disks do not), and that the disk can be read without errors (as tested by copying all files to a subdir on the hard drive before you start).

It's a good idea to make a partition image backup of your XP installation before you start, using something like BING.  Simply copying off every file is not enough, because unlike Windows 9x, XP will not work when copied in this way.

Also before you start, you may want to uninstall any OS-bundled subsystems that you've upgraded past the baseline of your XP installation disk, such as IE7 or recent versions of Windows Media Player.  Things are cleaner and more likely to be "supported" if you uninstall these before the repair, and re-install them afterwards, plus you'll have valid entries in Add/Remove Programs should you need to uninstall them again later (e.g. as a troubleshooting step).

Several sites describe the XP repair install process, starting from how to start the process, and going on to a step-by-step slide show or providing more detail.  In this post, I will mention a few specific gotchas to avoid...

137G capacity limit

If your hard drive is over 137G in size, then the Service Pack level of the Windows XP installation disk must be at least SP1 to install, and SP2 to live with.  In other words, you cannot safely install XP "Gold" (SP0) on a hard drive over 137G, and should apply SP2 or SP3 over an XP SP1 installation. 

If your install disk pre-dates SP1, you need to slipstream a later Service Pack into this and make a new installation disk that includes SP1 or later, built in.  Your other option is to install XP "Gold" onto a hard drive smaller than 137G, apply SP1 or later, and then use a partition transfer utility to copy the partition to the larger hard drive where the partition can then be resized to taste.

XP "Gold" has no awareness of hard drives over 137G and is very likely to mess them up.  XP SP1 is supposed to be safe on such hard drives, but there are some contexts where the code that writes to disk is unsafe and may cause corruption and data loss; from memory, these contexts typically apply to C:, e.g. writing crash dumps to the page file.  XP SP2 and SP3 are truly safe over 137G.

F6 driver diskette

Yep, you read right; that's "diskette" as in "ancient crusty old stiffy drive"! 

Most current motherboards have S-ATA hard drive interfaces that are not "seen" by the native XP code set (affecting Bart and Recovery Console boot disks as well).

The trouble is, the latest PCs often have no diskette drive, and the latest motherboards often have no legacy diskette controller.  You may come right with an external diskette drive plugged in via USB.  You'll also have to find and download the relevant driver diskette image and make a diskette from this, if yours is missing or unreliable.

If you use a USB keyboard, and this is not initiated at the BIOS level, then your F6 keystroke to read the driver diskette will be missed.  If so, you can plug in a PS/2 keyboard... as long as your new motherboard has PS/2 sockets; the newest ones don't.

Sometimes your mileage may vary, depending on the mode that your S-ATA is set to operate in CMOS Setup.  RAID and AHCI will generally not be "seen" natively by XP's code, whereas IDE mode may be.  But some nice S-ATA features may not work in IDE mode, e.g. hot-swapping external S-ATA or NLQ, and changing this after XP is installed may precipitate the same crisis as the motherboard swap... requiring a repair install to fix, again.

All of this is a reason why I consider the XP era to be over, when it comes to new PCs.  I appreciate how old OSs run beautifully fast on new hardware, and how attractive that is for gamers in particular - but XP's getting painful to install and maintain, and this is going to get worse.

Duplicate user accounts

Later in the GUI part of the installation process, you will be prompted to create new user accounts.  You can try to skip this step (best, if that works... I can't remember if it does), or create a new account with a different name that you'd generally delete later. 

But many users are likely to create a new account with the same one as their existing account, and that's likely to hurt... 

The two accounts will show the same name at the Welcome screen, but both will be selectable via this UI; I have no idea what will happen if you were to force the more secure legacy logon UI, which requires the account name to be typed in.

Each account will have a unique Security Identifier (SID), which is the real "name" used behind the scenes - but you can't login with that.  There will also be separate account subtrees in "Documents and Settings"; the one with the plainest name is likely to be the original, and the one with numbers or the PC name added to it is likely to be for the newly-spawned account.

At this point I'll mention another user account hassle that I generally don't see, because I avoid NTFS where I can.  If you find you can "see" your old user account's data, but aren't permitted to access the files, then you may have to "take ownership" of these files from a user account that has full administrative rights. 

This issue is well documented elsewhere; search and ye will find!

Broken update services

It's a given that the "repair" is going to blow away all patches subsequent to the baseline SP level of the XP installation disk you are using, unless you've slipstreamed these into your installation disk.

What's less obvious is that after you do the "repair" install, you won't be able to install updates.  It doesn't matter whether you try via Automatic Update, Windows Update or Microsoft Update, the results will be the same; the stuff downloads OK (costing you bandwidth) but will not install, whether you are prompted to restart or not.

The cause is a mismatch between the "old" update code within the installation CD, and the newer update code that was controversially pushed via update itself.  I can see Microsoft's logic here; if you ever wanted updates to work (e.g. you'd chosen "download but don't install", or disabled updates while planning to enable them later), then the update mechanism has to be updated - but doing so, invalidates the original installation disk's update code.

This topic is well-covered, as is the fix; manually re-registering a number of .DLLs that are needed for the update process to work.

Broken settings

It's often asserted that a repair install "won't lose your settings", and is yet waved around as a generic fix for undiagnosed problems.  Part of why it sometimes works as a "generic fix" is precisely because it can and does flatten some settings, which may have been deranged to the point that the OS couldn't boot!

So if you do apply any non-default settings, you should check these to see if they've survived.  I always check the following, and can't remember with certainty which ones survive and which don't:

• System Restore (may be re-enabled on all volumes)
• System Restore per-volume capacity limits
• Automatically restart on system errors
• RPC Restart the computer on failures (may survive)
• Show all files, extensions, full paths, etc. (may survive)
• NoDriveTypeAutoRun and NoDriveAutoRun
• Standard services you may have disabled
• Hidden admin shares, if you'd disabled them
• Recovery Console enabling settings
• AutoChk parameters in BootExecute setting
• Shell folder paths
• Windows Scripting Host, if you'd disabled it
• Settings detail in IE, including grotesquely huge web cache
• Windows Firewall settings; may be disabled if < SP2 !!
• Anything else you've dared to change from duhfaults

It's particularly crucial to enable the Windows Firewall (or install a 3rd-party alternative) before letting your PC anywhere near any sort of networking, especially the Internet, if your installation is "Gold" or SP1.  Not only do these dozeballs duhfault to "no firewall", they're also unpatched against RPC (Lovesan et al) and LSASS (Sasser et al) attacks, so you'd be "open and revolving".

By now, the original PoC Lovesan and Sasser worms may be extinct, but these exploits are often crafted into subsequent workaday bots and worms.  You may still get hit within an hour of plugging in the network cable if so, and probably before you can pull down updates for the OS, antivirus scanners, etc.

Cause and Distance

"Send this habitat module to Sirius Prime, now!"

' OK ...'

Right-click habitat module, Properties, Location tab, highlight "Earth", enter new text "Sirius Prime", press Enter.  Drone work, really, but Fred just counts himself lucky at being able to find a summer job.

Sharp distance runaround

I find it interesting that despite the strange and counter-intuitive models we've developed for sub-atomic matter, we still cling to the Newtonian idea that cause is carried by force, and force involves objects banging into each other.

So we've had "The Aether" before we could get our heads around empty space, the idea that waves must travel in a medium (neatly solved by counter-generating electro and magnetic fields), and the "problem" of action at a distance that is modelled on throwing particles around.

We understand space and time as interrelated through the speed of light, so that "distance" can be envisaged in either terms. 

Trapped in the mesh

Trying to resist the idea of desire-guided evolution, consider the need for senses (or sensors, if you like).  We sense what we need to attain, avoid or overcome, not what we can happily ignore as irrelevant.  Does hard drive S.M.A.R.T. monitor the tides of the ocean?  Nope.  Does the body monitor radiation levels?  Nope, as this had not been relevant during the timescale when shaped by selection pressure.

We are of the universe and are unable to transcend "distance" (be it conceptualised as time or space) at will, though we have a limited ability to physically move towards or away from things.  So we perceive distance as a dominant property of our environment, shaping concepts such as "cause and effect" and "the arrow of time". 

But this perspective may be a platform-specific perception issue, rather than a universal truth.  Perhaps if we visualize things differently - e.g. consider the distribution of mass as a constant, and "distance" as a particular parameter, then some things may snap in to focus, such as gravity as a "curvature of space". 

Often a graph that has a shape that is hard to grapple with, becomes a tame line drawing when the scaling of an axis is changed; certain problems, such as shapes that tend towards but never reach zero, may resolve themselves.  So it may be with "distance".

After writing this, I found the articles I've linked to, along with this one.  It would probably be more enlightening to fan out from here than to read the post you have just finished reading  :-)