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.
I've been doing this since some of the nastier trojans and rootkits came out a good three-four years ago. Image the machine using Ghost or TrueImage to backup the data files and apps, Nuke and rebuild the machine, and copy back the files from the image backup.
In all honesty, it's usually faster and a sure bet that you've fixed the problem for most cases. It does require the owner of the machine to have at least product keys and media if it's something that is not a download from the 'net, but in this instance, it's a commercial shop, and that's something that was usually required anyhow.
There are instances where this would not be a good idea, such as if there is a huge amount of crap on the machine that would take a day and a half to reload, or servers, or other circumstances.
This is especially nasty on some newer machines where the Windows rebuild partition resides on the hard disk, as even if you restore that the MBR typically gets left alone.
End result is a nice new install with preinstalled rootkit, and no antivirus at all.
Even worse, the first thing the latest malware does is unblocks Autorun so it ends up infecting the external hard disk etc with all the user's files on it.
This was done to avoid the need for restore disks and save the manufacturers money, its about one step ahead of those systems that ask you to "create a restore set" that promptly fails when you really need them.
Maybe there is a market for an antivirus pendrive, that can not only back up the user files but can also restore the original MBR for the various flavours of Windows so that the malware can't load.
AC/DC
Indeed so. What kind of iriot downvotes a perfectly fair question like that ? One with my kind of mouse skillz, maybe? Anyway...
I have a vague recollection that at some time in the last fifteen years or so one of the half dozen AV packages I've used (on NT-derived OSes) was able to detect writes to the MBR and ask for confirmation before continuing. Something along the lines of:
"Virus-like activity detected, attempting to update MBR. If you are not repartitioning please click Cancel, and run a full virus scan in Safe Mode" [or something like that]
I guess expecting people to know that they were repartitioning their disk was a bit much.
I assume the author has not had to fix an infected PC and is just believing the manual. (Or is a secret Apple-Linux man)
This would be easy to fix if you have a second PC. Just pull the drive, whack it in that PC, then fixmbr in there. Backup and clean infection while you are at it.
Even their suggested fix using the Vista\Win7 boot disk and fixmbr will not loose files in the majority of cases. (Have done this myself many times)
Or, as being mentioned a lot here, using Unbuntu will also get you there. (I use an external USB drive to backup to instead of the network)
Backup is just as simple using the above methods. (And who seriously tries to fix an infected PC without doing a backup first?)
I am expecting that ac@16:04 is on the money here. FixMBR will work fine on any "normal" PCs. But those with strange, non-standard setups with old partition layouts will be in trouble. (And GoBack is just evil...)
if you mentioned the ATTACK VECTOR for chrissakes!
The lollage, Sarah, is the basic lack of attention to detail in some of Reg's articles, you ARE journalists aren't you?
It's a requirement of being in the OEM programme, that you provide a recovery option. The physical disk is not required. Press F11 during boot and attend to the MBR, then restore the factory OS from the recovery partition.
My latest PC came with MBR partitioned disk containing Windows 7 "system partition" (which boots the PC), "boot partition" (which contains the operating system) that was nearly all of the hard disk, recovery partition, and EFI diagnostics. Four partitions is as many as you're allowed in MBR, and you can't update-in-place to GPT.
I discovered that I could download an updated EFI diagnostic program and install and use it on SD card, so I killed the EFI partition (now dead space, fairly small), shrank the Windows volume, and created a new partition for data.
While we're discussing it, putting a large swap file and (compulsorily if used) large hibernation file on the operating system volume, makes it that much harder to back up the volume for an all-or-nothing restore.
My gripe is mainly the fact that the %HOMEPATH% environment variable (in the case of XP: "c:\Documents and Settings\<User>") is not easily configurable. Fair enough, you can move your My Documents or whatever, but what about all your application settings, add-ins etc? You can get around this using some Microsoft enterprise distribution tools, or for consumers there is nLite which allows you to specify a different home path, but last time I checked that was not a function of vLite (the Vista-oriented successor to nLite which also works with W7) and if you want to use a different partition (or indeed physical drive) for your data, you're pretty much stuck with doing a half-job and moving all the preset file storage directories to where you want them (but leaving everything else under C:\User) or attempting to implement some frankly scary kludge with the repair console and building in NTFS junction points where the OS expects to find all its pretty little folders.
Not nice.
Re: backing up for an all-or-nothing restore - if you're stuck with a swap and hiberfil on your system partition, UBCD4Win combined with DriveImageXML can be handy in that you can delete these hulking great files and create a backup image while the system is offline.
But first, we'll do PC Playschool... try to keep your data on a different disk.
Now back to the kindergarten. Drive-Image XML. It is free and it works.
So, (as they say on the internet)... You boot into Windows from a CD and use Drive-Image XML to restore the C-drive image you made to another/external disk.
What? You're telling me that MS no longer allow booting to a working system from an installation CD? Bastards. That's why you need to have made a Bart-PE boot disk.
Really, this is computing for six year olds.
Even if a complete reformat/install should turn out to be necessary, you still do the above to restore your entire environment, loaded programs, etc etc etc.
Is there a pro here that doesn't know about imaging, for goodness sake?
"...applying a Master Boot Record fix before using a recovery disc is going to strip infected systems of both installed applications and associated data."
What complete and total nonsense! Maybe the author should read the Wikipedia article (http://en.wikipedia.org/wiki/Master_boot_record) next time before writing fiction like this.
To be precise, the FixMbr command overrides the MBR *code* in bytes 0 to 440, and not the partition table information at offset 01BE as the author incorrectly assumes.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
