What's an MBR virus?

[ClickCardo]

Does only the drive(s) with an OS on it have MBR's? What's an MBR virus? How do you know if you have one? How do you get rid of one especially in a multi-drive, one-OS, setup?

[tuskenraider]

http://www.google.com/search?source=ig&hl=en&q=mbr+virus&btnG=Google+Search

[Rabid Badger]

MBR stands for master boot record and it is located on your boot drive (the one that contains your OS). If you have a MBR virus, that is where you'll find it.

[ClickCardo]

tuskenraider, thanks for getting me into Google. After much research I think I understand what the MBR viruses are. I also believe there is one MBR on every physical drive in my system. Can you tell me if that belief is correct? I also believe that when I reinstalled XP, during which I only had the boot drive connected, I repartitioned/formatted the drive it would not get rid of a MBR virus. Can you tell me if that belief is correct? It also seems that if I now booted the XP install CD into recovery mode and did a FIXMBR that would replace the MBR virus with a good version. Is that correct? If that's right then what happens when I reconnect one of the physical data drives that might have a MBR virus and boot the clean XP disk?

Thanks.

PS: Thanks Rapid Badger for your reply too. Perhaps you could weigh in on my questions also.

[tuskenraider]

Sorry, wasn't in a helpful mood when I posted that. There is an MBR on every drive and repartitioning and formatting or using "fixmbr" very well could get rid of an MBR virus. You would also want to run an anti-virus program capable of checking the MBR for viruses as well as the virus could reinfect after you fix it. If you want to be 100% sure you're virus free, do a low level format with a program like KillDisk (http://www.killdisk.com/downloadfree.htm). Adding a second infected disk should not infect another clean disk. Again you can do a "fixmbr" on it after attaching it and booting from the Windows CD into Recovery Console and also an anti-virus scan from a boot disk or KillDisk the drive if no important data is on it.

[ClickCardo]

tr

Thanks for the reply. I'd rather not kill my data drives and even fixmbr gets me nervous, but I'd do that. This is in spite of data being duplicated on the disks since I'd have to wipe them all to be sure and thus lose all my backups as well as data.

My anti-virus is Zone Alarm Security Suite (ZASS). I have SpySweeper, SpyBot and ZASS as spyware scanners. I could also do an online scan with Housecall from trendmicro.com. I could also do a HiJackThis scan. I have no idea if any scan the MBR. I'll post to the ZASS forum to try to find out about that one. Do you have any suggestions for scanning?

Thanks again.
Rich

[mikeblas]

An MBR appears on all drives, not just bootable volumes.

[drizzt81]

Since I was curious myself some info.
How bootloaders work:
http://www.xs4all.nl/~lennartb/bootloaders/node3.html

From my understanding the bootloader sits in the MBR. The MBR itself is a single block on the harddrive (512Bytes), which the BIOS loads to a specific memory address. The first -couple?- of Bytes must be instructions, the rest can be data.

From my understanding an MBR virus would replace or modify the MBR sector to load itself before the boot loader.

[mikeblas]

There's a few errors in that article, but I guess it's accurate enough.

The MBR is exactly a sector long: 512 bytes. At this point, there's no OS and no file systems and nothing. If you're making a PC that will never (EVER!) use any other operating system than the one you're writing today, then you can put whatever you want on that sector.

In fact, the boot sector of a floppy won't have an MBR; it doesn't need one, as there's no partitions on it.

If you want to put an MBR on a hard disk and need that disk to play nice with other OSes, including their partitioning tools, then you want to follow the MBR format. That means you'll have other data in the 512-byte sector besides your boot code; that'll include the MBR's partition information, which other OSes might read and use to set themselves up in those other partitions.

The BIOS will load the sector and then execute the code it finds there; so, yes, it must start out with some instructions. To be useful, there will be lots more instructions -- to start loading the rest of your OS, for example.

Using the DEBUG utility that ships with Windows, it's easy to load the MBR from a floppy and disassemble it to see what it's really doing.

[ClickCardo]

drizz, that article started to make my eyes glaze, but thanks for the brief explanation. Also, it seemed a little oriented towards Linux and DOS where as I'm using Windows. But I get the fact that it's the BIOS starting what's in the MBR regardless of OS.

[ClickCardo]

mike

Thanks for the even more detailed explanation. When I get my XP and data drives malware free then later I'll dual-boot Vista too. If every disk has MBR's why would any of them but the one's having OS's on them be executed?

I read somewhere that even floppies can be infected by MBR viruses and this was their original historical point of origin.

I'm sure I could disassemble the boot loader and MBR, but not knowing assembly language I do not see how that would benefit me.

[drizzt81]

mike

Thanks for the even more detailed explanation. When I get my XP and data drives malware free then later I'll dual-boot Vista too. If every disk has MBR's why would any of them but the one's having OS's on them be executed? From what I understand, the user can select the boot order (and boot disk order) from the BIOS. I would guess that the MBR has to follow some 'format' in order to be recognized as 'bootable' by the BIOS, otherwise I have a hard time understanding how the BIOS would distinguish between a bootable and a non-bootable disk. If that is indeed the case, then I would guess only the first, bootable MBR will be executed. However, some boot-loaders, such as the one on the Windows XP install CD, will allow the user to skip booting from that device, in which case the next MBR is likely to be loaded.

I find it rather impressive how many things have to 'work together' to get a PC to boot correctly.

Edit: I just tried to load the first sector of my C drive using DEBUG and apparently WinXP SP2 does not like that very much. Neither as a restricted user nor as the local admin was I allowed to run:
debug
-l 0100 2 0 1
I saw a dialog telling me that directly accessing the hard drive "cannot be permitted". I have no idea why this is the case.

[mikeblas]

I saw a dialog telling me that directly accessing the hard drive "cannot be permitted". I have no idea why this is the case. I will randomly guess it may be related to the "dataexecution prevention" that I have turned on.

It's got nothing to do with DEP.

The reason it doesn't work is that DEBUG is doing a low-level DOS INT 21h call which Windows no longer supports against hard drives; Windows XP doesn't have any DOS bits. If you do the DEBUG command against a floppy, you'll be able to load the boot sector from the floppy and disassemble it.

It's been at least 15 years since I've done any of this stuff, but I think the BIOS decides a disk is bootable by looking for a signature of 0x55AA in the last two bytes of the boot sector. (If it can't read the boot sector in the first place, the drive is obviously not bootable.)

Here's a dump from some floppy I had around. It's just the machine code and not even the assembly, but you can see a few of the messages and the signature in the last bytes. There's certainly no partition table here.


C:\>debug
-l 7c00 0 0 1
-d 7c00
13B4:7C00 EB 3C 90 54 72 61 63 65-72 53 54 00 02 01 01 00 .<.TracerST.....
13B4:7C10 02 E0 00 40 0B F0 09 00-12 00 02 00 00 00 00 00 ...@............
13B4:7C20 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
13B4:7C30 00 00 00 00 00 00 00 00-00 00 00 00 00 00 0E 1F ................
13B4:7C40 33 C0 FA 8E D0 BC 00 7C-FB BE 76 7C FC AC 84 C0 3......|..v|....
13B4:7C50 74 08 B4 0E B3 07 CD 10-EB F3 B4 00 CD 16 CD 19 t...............
13B4:7C60 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
13B4:7C70 00 00 00 00 00 00 0D 0A-4E 6F 6E 2D 53 79 73 74 ........Non-Syst
-d
13B4:7C80 65 6D 20 64 69 73 6B 20-6F 72 20 64 69 73 6B 20 em disk or disk
13B4:7C90 65 72 72 6F 72 0D 0A 0D-0A 52 65 70 6C 61 63 65 error....Replace
13B4:7CA0 20 61 6E 64 20 73 74 72-69 6B 65 20 61 6E 79 20 and strike any
13B4:7CB0 6B 65 79 20 77 68 65 6E-20 72 65 61 64 79 0D 0A key when ready..
13B4:7CC0 00 43 6F 70 79 72 69 67-68 74 20 31 39 39 32 20 .Copyright 1992
13B4:7CD0 54 72 61 63 65 20 4D 6F-75 6E 74 61 69 6E 20 50 Trace Mountain P
13B4:7CE0 72 6F 64 00 00 00 00 00-00 00 00 00 00 00 00 00 rod.............
13B4:7CF0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
-d
13B4:7D00 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
13B4:7D10 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
13B4:7D20 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
13B4:7D30 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
13B4:7D40 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
13B4:7D50 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
13B4:7D60 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
13B4:7D70 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
-d
13B4:7D80 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
13B4:7D90 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
13B4:7DA0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
13B4:7DB0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
13B4:7DC0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
13B4:7DD0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
13B4:7DE0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
13B4:7DF0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 55 AA ..............U.

[drizzt81]

It's got nothing to do with DEP.

The reason it doesn't work is that DEBUG is doing a low-level DOS INT 21h call which Windows no longer supports against hard drives; Windows XP doesn't have any DOS bits. If you do the DEBUG command against a floppy, you'll be able to load the boot sector from the floppy and disassemble it.Thanks for that info. The lack of floppy drive will make it rather difficult for me to try that. I guess it's time to see if there is a Linux equivalent that I can use on my VM to have a peek. <sorry for going way off topic>

[Rabid Badger]

PS: Thanks Rapid Badger for your reply too. Perhaps you could weigh in on my questions also.

Seeing as how my info was completely wrong, I think I'll leave you in the hands of tusken, drizz and mike.:) Your polite thanks is appreciated, though. ;)

[ClickCardo]

From MS's website I found FIXMBR and FIXBOOT that, executed in Recovery Console, might solve my problem. I see how to use MAP to help me out. What I would like to know is should I do it to ALL my HDD's? Do I use both commands or just one and in what order? Finally, if I did this would it mess up my current files on their existing drives/partitions?

CC