MS advises drastic measures to fight hellish Trojan Microsoft is advising users to roll-back Windows if they happen to be unfortunate enough to get hit by a particularly vicious rootkit. The Popureb Trojan sticks its tendrils so deep into the operating system that the best option is to nuke from orbit return machines to their pre-infected state and change the Master Boot Record …
Fixing the master boot record and then re-installing Windows would not necessarily erase all data on the computer, although with a fresh registry you would have to re-install all applications. If data files are also lost, which could well happen in some cases, that would be because of limitations of the recovery CD that came with the computer.
Quote from Technet
"Note: Care must be used since certain viruses overwrite the sector between the MBR and the boot sector, redirecting boot to a secondary location. If this has occurred, replacing the MBR can cause permanent loss of the partition information. When unable to boot from a drive always use a virus scanner prior to using the FixMBR command."
If you are going to quote a source , you have to understand why they say this. Just throwing crap out there isn't going to help anyone.
Microsoft won't bash 3rd party developers and some 3rd party partitioning software didn't really partition the drives correctly and would store info in the MBR as a work around. GoBack a horrible backup system would also write info to the MBR.
Since you cannot tell either one of these are on the computer from a recovery console and if you overwrite the MBR you will screw up your hard drive, that is why they have that warning. If cannot boot and need the data and are scared to run the MBR then just put the hard drive as a slave in another computer and pull the data.
Just because you see something written down doesn't mean you understand what it is saying. Maybe if you aren't sure you shouldn't post.
You're correct, but MS are clearly advocating scorched earth policy here.
All recovery CD/DVD/partitions offer a blitz and reinstall, a few offer "repair". If the infection is as bad as it sounds, then fixmbr and blitz would work, while repair certainly wouldn't.
And kudos to the Windows security model once again. Slow clap.
If the user's data wasn't properly backed up in such a situation I'd reach for a Linux rescue CD such as RIP (Recovery Is Possible) Linux.
Boot. Mount the NTFS partitions readonly. Connect to a network share or plug in a USB drive. Copy the user's files. Finally nuke the disk by writing /dev/zero to the whole shebang, MBR and all before doing a Windows reinstall or restoring a disk image.
However devious a root kit, it can pose absolutely no threat to a Linux-based rescue system resident in RAM, because nothing on the compromised disk ever gets executed by the rescue system.
Having just had to show a neighbour how to make a Recovery CD I thought I would just mention that the option is in:
<Control Panel><Backup and Restore>.
Load a blank CD and let it get on with it. Label it (the program tells you what to write). Add the date (the program does NOT tell you that).
Keep it safe. Make a new one every few months or if you change partition sizes.
If you have a back up of a clean MBR then you should be able to use that, and also restore the Windows partiition to a previous clean state. A Linux live CD with partimage provided will do it, for instance - although partimage didn't seem to be getting updated when I looked !ast. Fiddly, too.
I wonder what happens if you've got GPT. There is an MBR but it's a dummy copy, and your GPT might be untouched. You won't get anywhere with partimage, though.
Besides more than enough multiple partitions (which according to documentation Microsoft seems to want to exhaust anyway), the notable driver of GPT adoption is MBR failing to describe hard drives above 2.19 terabytes (2 TiB minus 1 sector) in size, although it may be possible to cheat.
If I correctly understand the situation after reading Wikipedia's GPT article, the drive boot sector or MBR that exists on a GPT disk mainly may contain two things: some of the system boot executable code (probably requiring EFI/UEFI "BIOS" to work), and an partition table that says, "All of this disk is used by one partition type that your partition tool doesn't know about. Leave it alone." The size of that partition will be ~2 TiB or the actual disk size, whichever is less. GPT or dual tools will (maybe) recognise this special MBR and (probably*) ignore it, going straight to the GPT starting on the next sector. MBR tools will probably balk in a way that reminds you that you should use a GPT tool instead. So in that way, the MBR points to the GPT, but only by being a special recognisable non-valid MBR.
I've just viewed http://wiki.onmac.net/index.php/Triple_Boot_via_BootCamp#Disk_Partitions_and_their_Limitations
which appears to describe successfully fiddling with this arrangement to get both a GPT and an MBR that accurately represent working hard disk partitions, but presumably below the 2 TiB limit.
As for Linux-based backup of a GPT Windows installation, here may be where we favour ntfsclone or even dd over partimage, at least, and also separately back up the GPT. partimage scores for me a bit by having compressing and file-splitting your backup built-in instead of apparently requiring a pipeline of statements, as well as grabbing the MBR with no effort (although with so-slow bzip2 compression this is buggy). I reckon that a backup compressed file segment size of 315 MB benefits by packing nicely, if necessary, onto CDs as well as DVDs, which probably makes me a genius in 2005, maybe not now.
I haven't seen it, but, as I say, I gather that Windows sprinkles a baffling selection of strange, tiny, vital partitions onto your GPT disk. As for dd, it'll back up the empty space on your disk, so a Windows procedure or program that fills that empty space with nicely compressible zeroes or something similar before a backup attempt is a good idea.
* Since the false MBR is part of the GPT specification, a smart GPT tool may offer to fix the MBR contents if they're not present and correct.
It's not directly related, but I seem to remember that about fifteen years back BIOSes had an option to prevent a disk's MBR from being modified. It was a virus fighting measure or somesuch.
I may be wrong -- that dates back to when I was first learning to use computers. But I'm curious if anyone else here remembers what it was about and why manufacturers stopped including the option.
If I understand this correctly, there's no reason to assume linux is any more secure here.
Let's start with there being an infected MBR and this gets run before the operating system. In the old days of boot sector/MBR viruses, the virus would allocate some memory for itself using the BIOS, then patch in some entries into the interrupt table, say int 13h, which does low-level disk I/O. The classic sneaky viruses would intercept calls to access the disk and if it was already infected it would return a "cleaned" version so that virus scanners couldn't detect it (hence the need to boot off clean floppies if you wanted to be sure the scanner was working). If the disk (or file) wasn't infected, the virus would usually take that opportunity to do so at the time it's being accessed. The DIR-II virus worked quite like that.
Fast forward to more modern OSs and some things have changed, but not everything. In general, once linux has booted up, it doesn't use the BIOS for anything any more, so even if an MBR virus did manage to install itself before the OS, it would be stranded since int 13H would never get called and the virus would never execute. Apparently (from a quick search) windows still does use the BIOS for disk I/O, so maybe you'd chalk that up as a "linux is better" point. Actually, it's no reason to celebrate just yet... because Linux does use the BIOS at one key stage--when it's booting up, ie loading the kernel.
So actually, if you wrote an MBR virus that was aware of modern operating systems, you could actually hook into the BIOS entries for disk access and when Linux is booting the kernel you return an infected version on the fly. So in theory at least, neither OS is better on this score.
"So actually, if you wrote an MBR virus that was aware of modern operating systems, you could actually hook into the BIOS entries for disk access and when Linux is booting the kernel you return an infected version on the fly."
That would require the virus load up a whole kernel and make sure that works with the modules in your rootfs. Theoretically possible, but hugely challenging.
The cop out clause is that if the virus loads a complete kernel then you can hardly say it is "running Linux".
WTF!,
Back up your data and then reinstall after running the fixmbr.
If you cannot boot into Windows and your are infected then boot off the Windows CD into the recovery console then run the fixmbr command. Then do a parallel install of Windows to another directory and pull your data off.
The person who wrote this article and most of the comments are plain wrong. You never have to loose your data. It is always better to make a backup, but if there isn't one then you still have options.
Since when is using the recovery "restoring to a pre-infected state" mean reinstalling? Using the repair function from the recovery disc fixes it without wiping all your data. I've done it half a dozen times on my personal machines, and I've never lost anything more than a couple days worth of program installs.
Microsoft, makes the operating system. The company who built your computer has chosen not to include a install DVD. This has nothing to do with Microsoft. If you are going to bitch and I think you should then direct it to the right party.
Paris - because she always knows what party to go to be a bitch.
"Microsoft makes the operating system. The company who built your computer has chosen not to include a install DVD. "
Except, the buyer is not told that they are getting a functionality-limited copy of Windows with their new computer. Everything on the computer suggests thay are being supplied with the full product. If that isn't misrepresentation, then I dunno what is.
Maybe there should be a requirement for such versions to include the legend "OEM" on the splash screen, along with the wording, "One-time preinstall" or suchlike. Then, at least the nontech buyer would not be misled into thinking they have a full, reinstallable copy.
IMHO it is also steering very close to misrepresentation to describe an install as "Microsoft Windows" when it has a million items of trialware embedded into the OEM image, and no way is provided of actually installing Windows alone, minus junk.
Parallel example, can I mix Grouse, water and lemonade with Talisker, and sell that as Talisker (with bundled add-ons) -and also fail to provide a stopper for the bottle? I think that would soon get me in trouble, would it not?
Fundamental question; at what extent of adulteration does a brandname cease to legitimately apply to a product?
I'm not convinced M$ doesn't have a hand in this. Clearly it's against Microsoft's interests to have alot of Windows install CDs floating around. That might give people the idea that they could *gasp* buy a computer without an OS and install from Windows CD they already have. (Perfectly legal if the last computer it was used on has been retired.) And considering they pull enough weight with hardware manufactures to dictate details as trivial as having Windows Logo slightly inset on the keyboard, I think it's a pretty safe bet that they have a say in exactly how Windows is distributed with a new computer.
Well, yes, maybe, or maybe not.
It is certainly written in the Windows OEM eula that you are NOT permitted to reinstall the preinstalled copy windows on any other hardware. It is expressly forbidden.
Whether that is enforceable if anyone were to challenge it in court is another matter.
I don't believe this has ever happened so at this point the best we can say it is a legal grey area.
"(Perfectly legal if the last computer it was used on has been retired.)"
This really depends on the type of Windows licence provided with the old computer. If it's a full retail version, you are completely correct. If it's an OEM version, then the licence restricts you to the system that it was purchased on, and some OEM licence keys cannot be used for hardware from a different manufacturer (the installation process can check the BIOS identification string to check that the machine was made by the manufacturer who bought the OEM license).
MS will sometimes grant an activation string if you have to replace the motherboard as a result of a system failure, but I've found that recovery CDs in this scenario do not always work with different motherboards, at least for systems from large suppliers who use custom BIOSes. Simple answer is, if you can get a copy of a retail disk, guard it like it is gold.
I recently found this out when trying to license XP for a VirtualBox on my laptop, which runs Ubuntu (VirtualBox loads a specific BIOS in the VM which is completely unrelated to the actual system BIOS). I could not get it to accept the IBM OEM WinXP Pro key printed on the COA on the bottom of the machine until I cloned the BIOS identification strings in VirtualBox.
Of course, to a system integrator, providing a full retail licence will cost either them or their customer a lot more money than the heavily discounted OEM licence that Microsoft will sell them. This would put the supplier at a significant competitive disadvantage (I believe in the UK it is in the order of £50 per system) to their competitors who just use OEM licences, and as a side effect, ties them almost irrevocably to Microsoft, who will threaten to withdraw the OEM licence if they do anything that Microsoft don't like (like pre-installing Netscape Navigator or Lotus Notes/Symphony [old Symphony, not current], or shippping systems without an OS, or even with Linux pre-installed).
And of course, this also means that MS have a continual revenue stream as people replace their PC, and MS counts another Windows sale, even if it is an OEM one.
It's new, so its infection rate can't be measured accurately.
Detecting it is a moot point since you can't remove it while it's online. Though I have to wonder if the hook can't itself be unhooked or otherwise mitigated so it can't alter the commands.
As for vector, that's up to the people who use the malware. It's classed as a Trojan, so we can expect the usual avenues for a trojan, from programs to drive-bys.
Anyway, I would suspect that the next step for these malware authors would be to go back to another classic MBR technique (Stoning) and booby-trap the MBR so that tools like fixmbr won't work anymore (perhaps by encrypting the partition table and preventing it from being restored). Then it probably really WILL be nuke-from-orbit time since an encrypted partition table will make it exceedingly difficult for recovery programs to figure out what it's trying to restore.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
