Boot virus on xp

[Wim Hamhuis]

The computer will not boot at all! As to the original poster, IMEO, the

computer has no boot virus at all, just a messed up infection by Sasser!

Then he should boot his computer with [F8]
step through the processes
cancel process avserve2 [this proces locks the file "used by windows"]
clean with antivir

voila.

w.f.g.
Wim Hamhuis

 

[Wim Hamhuis]

It depends on the specific case. If all that was done was running SYS C:, and
nothing else was changed (C:\Ntldr, C:\Ntdetect.com, C:\Boot.ini, and the MBR
are all intact), then a simple FIXBOOT command from the XP repair console should
do the trick.

Other cases may require specialized tools, like RESQDISK.

Regards, Zvi

Ofcourse.. you need the correct system disk to transfer the right system if
it's a bootsectorvirus. Sasser isn't a bootsector virus, but a process
called avserve2. Just cancel the process "avserve2" when booting. In win98
this could be done by pressing [F8] when you boot. Then you would be able to
clean the virus with the fixtool provided by symantec.

w.f.g.
Wim Hamhuis

 

[Wim Hamhuis]

If curious, then the DOS version that XP installs on the MS-DOS boot
floppy is

Millennium. You can tell by typing VER and Enter when booted of that floppy.

Regards, Zvi

How do you rescue the bootsector in the new winXP then ?

The command for DOS 6.22 was SYS
The command for Win98 is SYS

is it changed to something else then ?????

w.f.g
Wim Hamhuis

 

[FromTheRafters]

Then connect te battery again, standard bios (default) WILL BE LOADED
FROM ROM. Some virusses infect or try to "flash" the bios. When this
happens, disconnect the bios backup battery. When you do, connecting
the battery again will cause a standard program into ROM loaded into your
BIOS by default.

Some confusion over CMOS and BIOS in the above. The battery
(or shorting jumper, or debug routing) will cause the CMOS to be
set to factory default settings. If the BIOS has been corrupted then
there is sometimes another procedure that will get it back for you -
but the above is not it.

Wim's procedure will work for setting the CMOS settings, but does
not affect the BIOS routine. Indeed, some malware will alter settings
in the CMOS, and this is helpful to at least get default settings back.

 

[Jason Wade]

[ dangerous advice snipped ]

Do /not/ disconnect the cmos battery unless your motherboard or computer
manual tells you to do so.

Doing that will probably make your system non bootable, at least
temporarily.

And, AFAIK, the cmos backup battery has nothing to do with the bios chip.
Unplugging it will hurt you, but it can't help you.

Many motherboards don't have a flashable bios, so a virus won't be able to
tamper with those machines in that way.

But if an mb has it, and a virus changes it, it's time for a bios chip or
motherboard replacement.

It's very rare for a virus to be able to tamper with the motherboard. Do
/not/ mess up your system out of panic.

Find out what type of malware you have and respond to that one.



Also, as far as "fdisk /mbr" is concerned, it can either replace the
master boot record only, or it can wipe the partition table. Use at your
own risk.

 

[Zvi Netiv]

On Tue, 25 May 2004 04:40:13 -0500, Wim Hamhuis wrote:
[snip]

Also, as far as "fdisk /mbr" is concerned, it can either replace the
master boot record only,

Not even that. FDISK /MBR just rewrites the partition loader portion of the MBR
and leaves the partition table data intact!

or it can wipe the partition table.

Plain false!

Use at your own risk.

Meaningless statement. You could say that about everything, from coffee to
flushing the toilet, and it would be true just the same.

Regards, Zvi

 

[kurt wismer]

Not even that. FDISK /MBR just rewrites the partition loader portion of the MBR
and leaves the partition table data intact!


Plain false!

actually, in the old days there was a condition that would cause fdisk
/mbr to wipe the partition... don't know if current versions of fdisk
still do it but i'm pretty sure it used to be if the 55AA at the end of
the sector wasn't there it would wipe... i seem to recall discussing
this with you before - i think you told me the disk won't boot properly
under that condition anyways... i might be thinking of someone else
though...

the bigger problem with fdisk /mbr is if the partition table is no
longer where it is supposed to be or if it has been encrypted...

 

[Zvi Netiv]

actually, in the old days there was a condition that would cause fdisk
/mbr to wipe the partition... don't know if current versions of fdisk
still do it but i'm pretty sure it used to be if the 55AA at the end of
the sector wasn't there it would wipe... i seem to recall discussing
this with you before - i think you told me the disk won't boot properly
under that condition anyways... i might be thinking of someone else
though...

You are referring to a very specific condition where the last two bytes in the
MBR are zero, rather than 55 AA (so called "boot sector signature"). Running
FDISK (no need for the /MBR switch, just plain FDISK) will rewrite the entire
MBR with a fresh partition loader, a default partition table, and the correct BS
signature. The "default partition" is the entire available drive space, in a
single partition.

A precondition to the MBR or boot sector to be considered and executed as such
is the presence of the 55 AA signature.

The other person you think of is probably Joep.

Regards, Zvi

 

[Jason Wade]

Plain false!

Uh huh,

http://support.microsoft.com/defaul...pport/kb/articles/Q69/0/13.ASP&NoWebContent=1

http://www.cknow.com/vtutor/vtfdiskmbr.htm

http://www.wintrouble.net/discus/messages/55/430.html?973182605

I amend what I said. Fdisk /mbr won't wipe the partition table,
but it can still make the disk unusable.

 

[FromTheRafters]

[snip]

So neither is recommended for removing boot viruses?

I wouldn't entirely exclude FDISK and SYS, especially not FDISK, from the list
of available tools for repairing boot virus damage. After all, their respective
action on the boot sector or MBR is implemented in FIXBOOT and FIXMBR, two tools
used as part of the repair console of the newer OS.

Understood. My intention was to caution against possibly doing more
harm than good by implementing either of these without first determining
exactly which boot virus one is attempting to remove, and the system
specifics (dual boot, overlay, etc..) being dealt with.

The rule is that you should know what you are doing.

That is a good rule. :O)

 

[Zvi Netiv]

http://support.microsoft.com/defaul...pport/kb/articles/Q69/0/13.ASP&NoWebContent=1

That reference doesn't support your statement that FDISK /MBR can wipe the
partition table. Besides, that page content is badly outdated and recycled
info. You can tell from the reference to Speedstor (who still uses it?). Not
worth marking it.

http://www.cknow.com/vtutor/vtfdiskmbr.htm

Badly outdated, and doesn't support your claim either. I doubt that Nick would
have written that stuff now.

http://www.wintrouble.net/discus/messages/55/430.html?973182605

This one explicitly says: "FDISK /MBR [the /MBR parameter is available in
MS-DOS 5.x onwards] replaces the partition executable code, *without changing
the partition data.*" Quite the contrary to your statement!

I amend what I said. Fdisk /mbr won't wipe the partition table,
but it can still make the disk unusable.

That's better, yet still not true.

You seem to confuse between usability, self boot ability and partition(s)
accessibility. FDISK /MBR cannot turn an usable disk into an "unusable" one.
In the very few and now rare cases in which FDISK /MBR may have an undesired
effect on the boot manager, it will prevent self booting, at worst. These cases
are limited to drives that use a DDO, or a third party boot manager (excluding
MS native multi-system boot). The problem can then be fixed simply by
reinstalling the boot manager or the DDO, without losing the drive content.

As to the boot viruses that once were the cause of all that nonsense about FDISK
/MBR, they are now so rare that it's time to stop that silly campaign. In those
*extremely few* cases where the partition table has been encrypted by the virus,
zeroed, or dislocated, you can use my free utilities to fix what needs fixing
(available from www.invircible.com/iv_tools.php and
www.invircible.com/resq.php).

Besides, the function of FDISK /MBR is now well established and implemented in
FIXMBR, a command available to both W2K's and XP's repair console.

Regards, Zvi

 

[Zvi Netiv]

How do you rescue the bootsector in the new winXP then ?

Answered in my reply to James Egan, in this thread: The command is FIXBOOT,
from the repair console.

The command for DOS 6.22 was SYS
The command for Win98 is SYS

And for Windows ME too.

is it changed to something else then ?????

SYS is a DOS command, and Win 9x and ME still have DOS in the basement. Which
is why SYS is available under these OS. As to XP, it's an NT based operating
system and the SYS command isn't recognized by the OS. FIXBOOT isn't the XP
replacement for SYS, it only assumes the role of fixing the XP boot sector, just
as SYS does to its boot sector under DOS.

Regards, Zvi

 

[Zvi Netiv]

[snip]

So neither is recommended for removing boot viruses?

I wouldn't entirely exclude FDISK and SYS, especially not FDISK, from the list
of available tools for repairing boot virus damage. After all, their respective
action on the boot sector or MBR is implemented in FIXBOOT and FIXMBR, two tools
used as part of the repair console of the newer OS.

Understood. My intention was to caution against possibly doing more
harm than good by implementing either of these without first determining
exactly which boot virus one is attempting to remove, and the system
specifics (dual boot, overlay, etc..) being dealt with.

Boot viruses is where AV software always did a lousy job. Lots of false alarms,
misidentification of the virus, and the worst - high percentage of unsuccessful
"disinfection" that ended in loss of access to partition(s), or loss of self
boot ability.

Having said that, you realize that the "exact" determination of the boot virus,
if there is one at all, is not always possible. Worse: Such determination by
AV cannot be trusted and shouldn't be acted upon, especially when multiple
products do not agree on the identification of the alleged virus, or what is
more often the case, only one product claims finding the virus, and the others
see none.

A better approach to boot viruses is the generic one. Follow some rules how to
safely use FDISK /MBR, or FIXMBR:

For platforms that run under DOS, Windows 9x, or Millennium:

- Prepare a boot disk on a clean PC that runs under the same OS which is
installed on the problem PC. Copy FDISK.EXE to the floppy and write-protect the
floppy. A utility that will prepare such floppy for the above mentioned
platforms is MakeResQ from www.invircible.com/iv_tools.php

- Boot the problem PC from the floppy you made.

- When at the A: prompt, run FDISK /STATUS. You should see the details of all
partitions on installed fixed drives. If these details conform with the known
configuration of your drives, especially of the first one, then it's safe to run
FDISK /MBR on that drive.

If your antivirus still finds a virus after having run FDISK /MBR, then change
the antivirus.

Dual boot and overlays:

As I explained elsewhere in this thread, Microsoft's dual-boot is initiated by
the boot sector (NOT the MBR), pointing to the NT loader (NTLDR, followed by
NTdetect.com) and by the content of C:\boot.ini. FDISK /MBR is perfectly safe
to run for such drive.

As to boot overlays: There are two types of these, one originally written by
Ontrack (Disk Manager) and the other known as EZ-bios. FDISK /MBR is the
manufacturer recommended method to rewrite the MBR loader of Disk Manager, in
case it has been corrupted or affected by a virus! For both overlays, you will
have to rewrite the overlay anyway in case of virus infection, as the overlay
was most probably punched by the virus, having relocated the original MBR and
overwritten part of the overlay.

W2K and XP: If Windows starts normally and your AV claims finding a virus in
the MBR, then start the repair console and run FIXMBR. If the AV still claims
that it finds the virus after having run FIXMBR, then replace the antivirus as
it's false alarming.

Regards, Zvi

 

[kurt wismer]

Zvi Netiv wrote:
[snip]

Boot viruses is where AV software always did a lousy job. Lots of false alarms,
misidentification of the virus, and the worst - high percentage of unsuccessful
"disinfection" that ended in loss of access to partition(s), or loss of self
boot ability.

and yet the google archives of alt.comp.virus (and to a lesser extent
alt.comp.anti-virus) are chock full of examples of people
*successfully* removing boot infectors with anti-virus products...

[snip]

A better approach to boot viruses is the generic one. Follow some rules how to
safely use FDISK /MBR, or FIXMBR:

if only people could remember the rules... generally they wind up doing
(or worse advising) fdisk /mbr totally blind...

 

[kurt wismer]

You are referring to a very specific condition where the last two bytes in the
MBR are zero, rather than 55 AA (so called "boot sector signature"). Running
FDISK (no need for the /MBR switch, just plain FDISK) will rewrite the entire
MBR with a fresh partition loader, a default partition table, and the correct BS
signature. The "default partition" is the entire available drive space, in a
single partition.

A precondition to the MBR or boot sector to be considered and executed as such
is the presence of the 55 AA signature.

seems in agreement (more or less) with the discussion i'm remembering
so far...

The other person you think of is probably Joep.

that name does not ring any bells... i was sure it was a discussion
with you in alt.comp.virus, but google groups is only showing hits for
bruce and simon...

 

[Phil Weldon]

Boot sector viruses are the easiest of all viruses to prevent and to
remove! Using the BIOS option to write protect the boot sector of the boot
hard drive pretty well eliminates the possibility of infection by a boot
sector virus.

Repairing the boot sector is either done by booting with a DOS bootable
floppy for DOS or DOS based operating systems. Or the repair console or
booting from the installation disk for NT based windows keeping in mind that
you must have the Administrator account password, a password for another
account that has administrator privledges won't do.

The only way a single boot NT based Windows system can even GET a boot
sector virus is for another type of virus to drop a boot sector virus in the
interval between boot time and the time the protected mode of the operating
system loads and takes control.

--
Phil Weldon, pweldonatmindjumpdotcom
For communication,
replace "at" with the 'at sign'
replace "mindjump" with "mindspring."
replace "dot" with "."

..
..
..

 

[Frederic Bonroy]

Boot sector viruses are the easiest of all viruses to prevent and to
remove! Using the BIOS option to write protect the boot sector of the boot
hard drive pretty well eliminates the possibility of infection by a boot
sector virus.

Oh please. That BIOS option is close to useless.

 

[Zvi Netiv]

Zvi Netiv wrote:

that name does not ring any bells... i was sure it was a discussion
with you in alt.comp.virus, but google groups is only showing hits for
bruce and simon...

Joep is a regular in comp.sys.ibm.pc.hardware.storage that occasionally posts in
a.c.v.

I remember for sure having recently discussed that peculiar behavior of FDISK
with Joep, but could be that it was on the "storage" group.

Regards, Zvi

 

[Zvi Netiv]

Zvi Netiv wrote:
[snip]

Boot viruses is where AV software always did a lousy job. Lots of false alarms,
misidentification of the virus, and the worst - high percentage of unsuccessful
"disinfection" that ended in loss of access to partition(s), or loss of self
boot ability.

and yet the google archives of alt.comp.virus (and to a lesser extent
alt.comp.anti-virus) are chock full of examples of people
*successfully* removing boot infectors with anti-virus products...

Wrong keywords for the search. ;-) There are more hits for failed disinfection
by AV than successful ones, especially if you limit the search to the last few
years. Nobody would dare having a hernia operation if it had similar mortality
rates to AV disinfection of BSI!

[snip]

A better approach to boot viruses is the generic one. Follow some rules how to
safely use FDISK /MBR, or FIXMBR:

if only people could remember the rules... generally they wind up doing
(or worse advising) fdisk /mbr totally blind...

If you suggested FDISK /STATUS before running FDISK /MBR, instead of sending the
poster on a wild goose chase, then the "rule" would now be common knowledge.

Regards, Zvi

 

[Phil Weldon]

What is the evidence for your boot sector assertion, other than anechdotal?

--
Phil Weldon, pweldonatmindjumpdotcom
For communication,
replace "at" with the 'at sign'
replace "mindjump" with "mindspring."
replace "dot" with "."

Zvi Netiv wrote:
[snip]

Boot viruses is where AV software always did a lousy job. Lots of false alarms,
misidentification of the virus, and the worst - high percentage of unsuccessful
"disinfection" that ended in loss of access to partition(s), or loss of self
boot ability.

and yet the google archives of alt.comp.virus (and to a lesser extent
alt.comp.anti-virus) are chock full of examples of people
*successfully* removing boot infectors with anti-virus products...

Wrong keywords for the search. ;-) There are more hits for failed disinfection
by AV than successful ones, especially if you limit the search to the last few
years. Nobody would dare having a hernia operation if it had similar mortality
rates to AV disinfection of BSI!

[snip]

A better approach to boot viruses is the generic one. Follow some rules how to
safely use FDISK /MBR, or FIXMBR:

if only people could remember the rules... generally they wind up doing
(or worse advising) fdisk /mbr totally blind...

If you suggested FDISK /STATUS before running FDISK /MBR, instead of sending the
poster on a wild goose chase, then the "rule" would now be common knowledge.

Regards, Zvi