Boot virus on xp

[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...

Wrong keywords for the search. ;-)

i wasn't doing a keyword search, i was working off my memory from the 9
years i've spent in alt.comp.virus and 3 years in alt.comp.anti-virus...

There are more hits for failed disinfection
by AV than successful ones,

on going back and actually trying to get the statistics using google i
find something quite different, 'boot infector failed' gives about an
order of magnitude fewer hits than 'boot infector cleaned' for the
group alt.comp.virus...

maybe you've got some better keywords but quite frankly using raw hits
as a measure is misleading as initial failures have often been a case
user error (which, on consultation with the group, gets corrected) or
an issue with an individual av product failing (a phenomenon that is
not constrained to boot sector disinfection and that subsequent use of
a different av fixes)...

especially if you limit the search to the last few
years.

are you suggesting that boot infector detection and removal has gotten
worse during a period when practically no new boot infectors have been
created?

sounds like a tall tale to me...

Nobody would dare having a hernia operation if it had similar mortality
rates to AV disinfection of BSI!

i don't dispute that there have been cases where a particular av
product has failed to do it's job properly with respect to boot sector
viruses just as particular av's have failed on other types of viruses -
that doesn't mean that av products in general are bad at dealing with
boot infectors, it just means they aren't perfect...

and very few things are...

i suggest, though, that your own personal experiences have sampling
biases, as people generally don't go the unconventional route unless
the conventional one fails them... just as successful disinfections
have been under-reported in alt.comp.virus (no need to post if the
product does it's job right the first time), your own experiences
should reflect that under-reporting to an even greater degree...

[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.

except it's not that simple... your 'rules' assume the user knew what
partitions they were supposed to have and how big they were supposed to
be (which has usually not been the case as most users don't even know
what a partition is)...

of course some people can make good use of your rules, but i tend to
think those would be in the minority...

 

[Wim Hamhuis]

"Wim Hamhuis" <[email protected]> wrote

in message news:[email protected]...

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.

Ok, i'm human sometimes i can get confused. If my description works for the
CMOS instead of the BIOS, how do you recover the BIOS (if it is corrupted) ?

with friendly greetings
Wim Hamhuis

 

[Wim Hamhuis]

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

Phew. I'm released ;-)))

w.f.g.
Wim Hamhuis

 

[Wim Hamhuis]

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


And for Windows ME too.


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

Thanks for your usefull answer. I just seem to get used to the new WinXP. I
was used to work with Win98 all the time, you see.
The best way to keep your computer clean from virusses is maintaining a good
backup system.

w.f.g.
Wim Hamhuis

 

[FromTheRafters]

in message news:[email protected]...

Ok, i'm human sometimes i can get confused. If my description works for the
CMOS instead of the BIOS, how do you recover the BIOS (if it is corrupted) ?

If the motherboard supports it, there is a BIOS recovery jumper that can
be set so that alternate BIOS code sufficient to access the floppy drive
can be loaded from a non-volatile area of the BIOS chip's ROM. This
code is specifically designed to access the flash routine that it expects
you to have already obtained and inserted into the floppy (a) drive.

With the jumper set, and the correct BIOS flash routine on the floppy
inserted into the "A" drive, you energize the computer. In most cases,
from what I understand, there is no outward indication that anything
has happened aside from the normal noises from the floppy drive and
perhaps an audible "beep" from the PC speaker when the routine is
finished. At this point you de-energize - remove the floppy - set the
jumper back to the normal position - and then re-energize to boot
normally with a freshly re-flashed BIOS routine.

I have also heard that some motherboards have BIOS chips with a
fully functional BIOS routine in non-volatile ROM so that an almost
normal boot process can be realized even though the flashable part
has been corrupted.

 

[Wim Hamhuis]

"Wim Hamhuis" <[email protected]> wrote

in message news:[email protected]...

corrupted) ?

If the motherboard supports it, there is a BIOS recovery jumper that can
be set so that alternate BIOS code sufficient to access the floppy drive
can be loaded from a non-volatile area of the BIOS chip's ROM. This
code is specifically designed to access the flash routine that it expects
you to have already obtained and inserted into the floppy (a) drive.

With the jumper set, and the correct BIOS flash routine on the floppy
inserted into the "A" drive, you energize the computer. In most cases,
from what I understand, there is no outward indication that anything
has happened aside from the normal noises from the floppy drive and
perhaps an audible "beep" from the PC speaker when the routine is
finished. At this point you de-energize - remove the floppy - set the
jumper back to the normal position - and then re-energize to boot
normally with a freshly re-flashed BIOS routine.

I have also heard that some motherboards have BIOS chips with a
fully functional BIOS routine in non-volatile ROM so that an almost
normal boot process can be realized even though the flashable part
has been corrupted.

That's nice this is possible. Then we instruct other people to save this
floppy very carefully -write protected- in case you do have to re-energize
the computer. Don't *you* (in general) ever forget to make backups.

w.f.g.
Wim Hamhuis

 

[Zvi Netiv]

Zvi Netiv wrote:

i wasn't doing a keyword search, i was working off my memory from the 9
years i've spent in alt.comp.virus and 3 years in alt.comp.anti-virus...

The victims of unsuccessful BSI disinfection aren't limited to acv / aca-v.
Obviously, your selective memory isn't the best source for reference.

on going back and actually trying to get the statistics using google i
find something quite different, 'boot infector failed' gives about an
order of magnitude fewer hits than 'boot infector cleaned' for the
group alt.comp.virus...

maybe you've got some better keywords but quite frankly using raw hits
as a measure is misleading as initial failures have often been a case
user error (which, on consultation with the group, gets corrected) or
an issue with an individual av product failing (a phenomenon that is
not constrained to boot sector disinfection and that subsequent use of
a different av fixes)...


are you suggesting that boot infector detection and removal has gotten
worse during a period when practically no new boot infectors have been
created?

Your simplistic and purely formalistic knowledge on the issue really amazes me.
The change in the last years had to do with the large number of users that
shifted from early Windows, that was still based on DOS, to NT based OS (W2K and
XP). This shift had a pronounced effect on BSI and AV related issues.

First, AV do false alarms much more on boot viruses under the newer OS, to the
point that it's safe to say that the majority of BSI alerts under W2K and XP are
false alarms. Next, attempting the disinfection of BSI on such drives by aid of
AV, ends more often in ruining self-boot ability or loss of access to the
drive's partition(s).

i don't dispute that there have been cases where a particular av
product has failed to do it's job properly with respect to boot sector
viruses just as particular av's have failed on other types of viruses -
that doesn't mean that av products in general are bad at dealing with
boot infectors,

Wrong. AV products are unmistakably worse in cleaning BSI than in dealing with
other types of malware. There is no difference either in failure/success ratio
in that particular area between the various AV brands.

[snip]

except it's not that simple... your 'rules' assume the user knew what
partitions they were supposed to have and how big they were supposed to
be (which has usually not been the case as most users don't even know
what a partition is)...

You obviously haven't tried FDISK /STATUS, surely not on a drive on which you
shouldn't (or can't) run FDISK /MBR. Because if you did, then you would learn
that FDISK /STATUS returns no partitions at all (for anything that isn't FAT or
FAT-32), or senseless data. The return of FDISK /STATUS leaves no doubt
whatsoever, no guess work is needed to interpret the results, nor a university
degree.

What should really amaze is why that simple and safe solution (FDISK /MBR,
preceded by FDISK /STATUS for verification) didn't surface earlier in the
virus/AV discussions. Could it be connected with the preserving of some ones'
profit?

of course some people can make good use of your rules, but i tend to
think those would be in the minority...

.... and a defeatist too, on top of the rest.

Regards, Zvi

 

[Zvi Netiv]

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

Usenet posts and archives, statistics on the drives brought for recovery to
NetZ, and a personal interest and specialization.

Regards, Zvi

 

[FromTheRafters]

[snipped BIOS recovery stuff]

That's nice this is possible. Then we instruct other people to save this
floppy very carefully -write protected- in case you do have to re-energize
the computer.

Not really necessary, but not a bad idea either. If you ever find yourself in
such a situation, the flash routine should be available from the motherboard
manufacturer, either for replacement of the original or as an upgrade.

Also, some maotherboards with flashable BIOS have a jumper setting
so that you can inhibit flashing altogether - thus making the BIOS flash
malware payload a non-issue.

Don't *you* (in general) ever forget to make backups.

Who me!? I *never* forget anything, so of course I ...what was the
question? :O)

 

[FromTheRafters]

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.

Thanks for expanding on that, Zvi. I was only suggesting, in a general way,
that it is best to find out what one is dealing with prior to dealing with it.
Especially when "dealing with it" concerns the use of fdisk /mbr.

Having said that, you realize that the "exact" determination of the boot virus,
if there is one at all, is not always possible.

True, and I can see the benefits of dealing with it generically. It seems
that one would have to be somewhat experienced with such things to
even have a chance at recognizing the results of fdisk /status to ensure
that disk data has not been encrypted by the virus one is attempting to
remove.

....of course I haven't ever seen what the results of fdisk /status look like
when the likes of Stoned Empire Monkey has written itself to the partition
sector. I assume it looks nothing like a normal one.

 

[Phil Weldon]

Ah yes, anchedotal information.

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

 

[Phil Weldon]

Tell us, how does one even GET a boot sector virus on a single-boot Windows
2000 or Windows XP using NTFS on a single boot system?

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

Zvi Netiv wrote:

i wasn't doing a keyword search, i was working off my memory from the 9
years i've spent in alt.comp.virus and 3 years in alt.comp.anti-virus...

The victims of unsuccessful BSI disinfection aren't limited to acv / aca-v.
Obviously, your selective memory isn't the best source for reference.

on going back and actually trying to get the statistics using google i
find something quite different, 'boot infector failed' gives about an
order of magnitude fewer hits than 'boot infector cleaned' for the
group alt.comp.virus...

maybe you've got some better keywords but quite frankly using raw hits
as a measure is misleading as initial failures have often been a case
user error (which, on consultation with the group, gets corrected) or
an issue with an individual av product failing (a phenomenon that is
not constrained to boot sector disinfection and that subsequent use of
a different av fixes)...


are you suggesting that boot infector detection and removal has gotten
worse during a period when practically no new boot infectors have been
created?

Your simplistic and purely formalistic knowledge on the issue really amazes me.
The change in the last years had to do with the large number of users that
shifted from early Windows, that was still based on DOS, to NT based OS (W2K and
XP). This shift had a pronounced effect on BSI and AV related issues.

First, AV do false alarms much more on boot viruses under the newer OS, to the
point that it's safe to say that the majority of BSI alerts under W2K and XP are
false alarms. Next, attempting the disinfection of BSI on such drives by aid of
AV, ends more often in ruining self-boot ability or loss of access to the
drive's partition(s).

i don't dispute that there have been cases where a particular av
product has failed to do it's job properly with respect to boot sector
viruses just as particular av's have failed on other types of viruses -
that doesn't mean that av products in general are bad at dealing with
boot infectors,

Wrong. AV products are unmistakably worse in cleaning BSI than in dealing with
other types of malware. There is no difference either in failure/success ratio
in that particular area between the various AV brands.

[snip]

knowledge.

except it's not that simple... your 'rules' assume the user knew what
partitions they were supposed to have and how big they were supposed to
be (which has usually not been the case as most users don't even know
what a partition is)...

You obviously haven't tried FDISK /STATUS, surely not on a drive on which you
shouldn't (or can't) run FDISK /MBR. Because if you did, then you would learn
that FDISK /STATUS returns no partitions at all (for anything that isn't FAT or
FAT-32), or senseless data. The return of FDISK /STATUS leaves no doubt
whatsoever, no guess work is needed to interpret the results, nor a university
degree.

What should really amaze is why that simple and safe solution (FDISK /MBR,
preceded by FDISK /STATUS for verification) didn't surface earlier in the
virus/AV discussions. Could it be connected with the preserving of some ones'

profit?

of course some people can make good use of your rules, but i tend to
think those would be in the minority...

... and a defeatist too, on top of the rest.

Regards, Zvi

 

[Zvi Netiv]

Thanks for expanding on that, Zvi. I was only suggesting, in a general way,
that it is best to find out what one is dealing with prior to dealing with it.
Especially when "dealing with it" concerns the use of fdisk /mbr.


True, and I can see the benefits of dealing with it generically. It seems
that one would have to be somewhat experienced with such things to
even have a chance at recognizing the results of fdisk /status to ensure
that disk data has not been encrypted by the virus one is attempting to
remove.

...of course I haven't ever seen what the results of fdisk /status look like
when the likes of Stoned Empire Monkey has written itself to the partition
sector. I assume it looks nothing like a normal one.

I have done it, for your benefit and of all. Below are the results of running
FDISK /STATUS on my test drive, in the following three conditions: Uninfected,
with AntiEXE in the MBR, and with Monkey. Here is how it looks:

--- FDISK /STATUS with no boot infector, or with AntiEXE ---

Fixed Disk Drive Status
Disk Drv Mbytes Free Usage
1 38162 100%
C: 19077
D: 19085

The drive is 40 GB, divided into two equal size partitions, with dual boot
(Win98SE and XP professional), both on FAT 32 (for inter operability of
applications under either OS). FDISK /STATUS returns the same for an uninfected
drive, or when infected with AntiEXE. FDISK /MBR is safe to run under these
conditions.

--- FDISK /STATUS with Empire.Monkey ---

Fixed Disk Drive Status
Disk Drv Mbytes Free Usage
1 38162 100%

FDISK /STATUS shows no logical partitions with Monkey's code in the MBR, as the
encrypted partition data is not recognized by FDISK. You should not run FDISK
/MBR under this condition.

As you can see, the results are unambiguous and it's fairly simple to tell under
which condition FDISK /MBR is safe to run, after having tested with FDISK
/STATUS.

Regards, Zvi

 

[Robert Green]

Tell us, how does one even GET a boot sector virus on a single-boot Windows
2000 or Windows XP using NTFS on a single boot system?

By starting up with an infected floppy in drive A. BSV hard
drive infection exploits the BIOS and has nothing to do with
the operating system or file system in use.

Bob

--
Robert Green
BootMaster Partition Recovery
http://bootmaster.filerecovery.biz
bob[dot]green[at]filerecovery[dot]biz

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

lousy job. Lots of
false alarms, high percentage of
unsuccessful partition(s), or loss
of self

alt.comp.anti-virus...

The victims of unsuccessful BSI disinfection aren't

limited to acv /
aca-v.

Obviously, your selective memory isn't the best source for reference.


Your simplistic and purely formalistic knowledge on the

issue really
amazes me.

The change in the last years had to do with the large number of users that
shifted from early Windows, that was still based on DOS,

to NT based OS
(W2K and

XP). This shift had a pronounced effect on BSI and AV related issues.

First, AV do false alarms much more on boot viruses

under the newer OS, to
the

point that it's safe to say that the majority of BSI

alerts under W2K and
XP are

false alarms. Next, attempting the disinfection of BSI

on such drives by
aid of

AV, ends more often in ruining self-boot ability or loss of access to the
drive's partition(s).

had similar
mortality

Wrong. AV products are unmistakably worse in cleaning

BSI than in dealing
with

other types of malware. There is no difference either

in failure/success
ratio

in that particular area between the various AV brands.

[snip]

If you suggested FDISK /STATUS before running FDISK

/MBR, instead of
sending the now be common
knowledge.

You obviously haven't tried FDISK /STATUS, surely not on

a drive on which
you

shouldn't (or can't) run FDISK /MBR. Because if you

did, then you would
learn

that FDISK /STATUS returns no partitions at all (for

anything that isn't
FAT or

FAT-32), or senseless data. The return of FDISK /STATUS leaves no doubt
whatsoever, no guess work is needed to interpret the

results, nor a
university

degree.

What should really amaze is why that simple and safe solution (FDISK /MBR,
preceded by FDISK /STATUS for verification) didn't surface earlier in the
virus/AV discussions. Could it be connected with the

preserving of some
ones'

 

[Zvi Netiv]

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.

The BIOS write protection of the boot sector is anachronistic, worthless, and
should have been discontinued since long. Its only role is to scare uninformed
users for no sensible reason.

All Windows versions since Win 95 write data to the MBR as part of their normal
operation (Windows 95 to ME use a double word at offset 220 of the MBR, XP uses
offset 437 to 443). Enabling the BIOS "antivirus protection" will cause
constant false alarms!

Moreover, the BIOS protection can only intercept "writes" by aid of BIOS
interrupt INT 13h. Writes to boot areas done through port access (LBA)
completely evade the BIOS "protection". If you don't believe it, then you are
invited to freely manipulate the MBR on your drive (you know what you are doing,
right?) with the RESQDISK utility (get from my signature), with BIOS protection
enabled, and see for yourself the nonsense of that "feature". FYI, there are
now quite a few boot infectors and multipartite that use port access to do their
thing to boot areas. In fact, almost all malware from last five years vintage,
that manipulate the boot areas, use direct drive access and bypass the BIOS
protection.

Regards, Zvi

 

[cquirke (MVP Win9x)]

Zvi Netiv wrote:

[/QUOTE]

That hasn't been my mileage with F-Prot for DOS, which I have found to
be compitent on the BSVs I've seen ITW. One caveat: Always re-scan
after cleaning a BSV, in case you get this common scenario:
- scan shows BSV A to be present
- scan/fix cleans up BSV A
- scan shows BSV B to be present
- scan/fix cleans up BSV B
- scan shows BSV A to be present
- ...etc.

Most av will use knowledge of the malware to find and restore the
original boot sector from where the BSV relocated it, unlike kludgers
such as FDisk /Mumble that just splat standard code into place.

Trouble is, if the original boot code was also infected, F-Prot
doesn't check for this during the cleaning phase (as at 3.14a or
older; I haven't seen a BSV for some months now). So it restores the
previous BSV when cleaning up the current one. That's why it's
prudent to re-scan after fixing a BSV.

The change in the last years had to do with the large number of users that
shifted from early Windows, that was still based on DOS, to NT based OS (W2K and
XP). This shift had a pronounced effect on BSI and AV related issues.

Actually, even Win9x posed a barrier to BSVs, as these OSs disallowed
direct disk access. The installation process of Win9x also replaces
the boot code, which is why an av scan often finds a BSV in a file in
C:\ (forgotten the name, sorry) which was an image of the boot sector
that existed at the time Win9x installed.

Some BSVs and BSV droppers worked around Win9x by killing the relevant
32-bit code that drives the disk, forcing the handling for that disk
to fall back to DOS compatibility mode. This removes the blockade on
direct disk access, and allows BSVs to infect boot code. This
approach was common with respect to diskettes, and is a common cause
of "Drive A: is in DOS compatibility mode".

NT is more effective in blocking direct disk access (though Witty is
proof that it is not 100% effective). So I don't expect to see new
BSVs in the XP age, another reason being that diskette booting is now
a far smaller part of the exposure pie chart (compared to email,
direct network access through code defects, etc.)

First, AV do false alarms much more on boot viruses under the newer OS, to the
point that it's safe to say that the majority of BSI alerts under W2K and XP are
false alarms. Next, attempting the disinfection of BSI on such drives by aid of
AV, ends more often in ruining self-boot ability or loss of access to the
drive's partition(s).

I wouldn't rely on Windows-based av to detect and manage BSVs, and
would shrug if you had adverse mileage there. It's like saying a
chainsaw causes excessive collateral damage when used in carpentry;
it's just the wrong tool for the job.

Wrong. AV products are unmistakably worse in cleaning BSI than in dealing with
other types of malware. There is no difference either in failure/success ratio
in that particular area between the various AV brands.

As I say, that hasn't been my mileage at all.

What should really amaze is why that simple and safe solution (FDISK /MBR,
preceded by FDISK /STATUS for verification) didn't surface earlier in the
virus/AV discussions. Could it be connected with the preserving of some ones'
profit?

No; FDisk /MBR is a bad idea in several contexts. I used to advocate
this as an easy fixer until posters set me straight; yes, I still use
it sometimes, but *NEVER* without backing up the MBR first (FDisk /MBR
does nothing at all where partition boot viruses are concerned).

FDisk /MBR replaces the MBR boot code with standard code, regardless
of what was there or what should be there. This is NOT always what
you want, and will botch things if:
- the BSV is needed to decrypt the HD data (face-hugger dependency)
- you had a DDO to overcome BIOS addressing limitations
- you had an MBR-based partition/boot manager
- you had other custom code in the MBR

Further, if FDisk /MBR finds the 55AAh boot signature missing from the
end of the MBR, it will zero out the partition table - 'nuff said?

-------------------- ----- ---- --- -- - - - -

Hmmm... what was the *other* idea?

 

[Peter Seiler]

Robert Green - 30.05.2004 08:41 :

By starting up with an infected floppy in drive A. BSV hard
drive infection exploits the BIOS and has nothing to do with
the operating system or file system in use.

oh, what a terrible "trick" putting such numerous quoting lines after
the SIG "-- ". If everybody would post this way...

Adding all those quoting lines nevertheless increases the size of the
downloads and waiste bandwidth dramatically - especially when heavely
crossposting. For that, SIG-text should have a maximum of only 4 lines!
Therefore (not only you) please respect this argumentation. Thanks.

 

[Phil Weldon]

Nope, can't get a boot sector virus that way with a Windows 2000 or Windows
XP and NTFS on a single boot system. If the BIOS not set to boot from
floppy disk first (and why would it be with Windows XP or Windows 2000,
which can't be booted from a floppy disk) then the floppy drive will not be
accessed on boot up. Once Windows 2000 or XP takes control, then a boot
sector virus on a floppy disk cannot infect the system.

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

Tell us, how does one even GET a boot sector virus on a single-boot Windows
2000 or Windows XP using NTFS on a single boot system?

By starting up with an infected floppy in drive A. BSV hard
drive infection exploits the BIOS and has nothing to do with
the operating system or file system in use.

Bob

--
Robert Green
BootMaster Partition Recovery
http://bootmaster.filerecovery.biz
bob[dot]green[at]filerecovery[dot]biz

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

Zvi Netiv wrote:

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. ;-)

i wasn't doing a keyword search, i was working off my memory from the 9
years i've spent in alt.comp.virus and 3 years in alt.comp.anti-virus...

The victims of unsuccessful BSI disinfection aren't

limited to acv /
aca-v.

Obviously, your selective memory isn't the best source for reference.

There are more hits for failed disinfection
by AV than successful ones,

on going back and actually trying to get the statistics using google i
find something quite different, 'boot infector failed' gives about an
order of magnitude fewer hits than 'boot infector cleaned' for the
group alt.comp.virus...

maybe you've got some better keywords but quite frankly using raw hits
as a measure is misleading as initial failures have often been a case
user error (which, on consultation with the group, gets corrected) or
an issue with an individual av product failing (a phenomenon that is
not constrained to boot sector disinfection and that subsequent use of
a different av fixes)...

especially if you limit the search to the last few
years.

are you suggesting that boot infector detection and removal has gotten
worse during a period when practically no new boot infectors have been
created?

Your simplistic and purely formalistic knowledge on the

issue really
amazes me.

The change in the last years had to do with the large number of users that
shifted from early Windows, that was still based on DOS,

to NT based OS
(W2K and

XP). This shift had a pronounced effect on BSI and AV related issues.

First, AV do false alarms much more on boot viruses

under the newer OS, to
the

point that it's safe to say that the majority of BSI

alerts under W2K and
XP are

false alarms. Next, attempting the disinfection of BSI

on such drives by
aid of

AV, ends more often in ruining self-boot ability or loss of access to the
drive's partition(s).

Nobody would dare having a hernia operation if it

had similar
mortality

rates to AV disinfection of BSI!

i don't dispute that there have been cases where a particular av
product has failed to do it's job properly with respect to boot sector
viruses just as particular av's have failed on other types of viruses -
that doesn't mean that av products in general are bad at dealing with
boot infectors,

Wrong. AV products are unmistakably worse in cleaning

BSI than in dealing
with

other types of malware. There is no difference either

in failure/success
ratio

in that particular area between the various AV brands.

[snip]

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.

except it's not that simple... your 'rules' assume the user knew what
partitions they were supposed to have and how big they were supposed to
be (which has usually not been the case as most users don't even know
what a partition is)...

You obviously haven't tried FDISK /STATUS, surely not on

a drive on which
you

shouldn't (or can't) run FDISK /MBR. Because if you

did, then you would
learn

that FDISK /STATUS returns no partitions at all (for

anything that isn't
FAT or

FAT-32), or senseless data. The return of FDISK /STATUS leaves no doubt
whatsoever, no guess work is needed to interpret the

results, nor a
university

degree.

What should really amaze is why that simple and safe solution (FDISK /MBR,
preceded by FDISK /STATUS for verification) didn't surface earlier in the
virus/AV discussions. Could it be connected with the

preserving of some
ones'

profit?

of course some people can make good use of your rules, but i tend to
think those would be in the minority...

... and a defeatist too, on top of the rest.

Regards, Zvi

 

[Phil Weldon]

"Enabling the BIOS 'antivirus protection' will cause constant false
alarms!" Not true on the face of it, and I stopper reading at this point.

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


replace "dot" with "."

 

[Phil Weldon]

Thanks for making the effort. Could you tell us how you infected the dual
boot system with Windows 98SE installed, and if you can infect a system that
has only Windows 2000 and/or Windows XP with NTFS installed via a methhod
that could exist in-the-wild?

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