Boot virus on xp

[Robert Green]

Nope, can't get a boot sector virus that way with a

Windows 2000 or >Windows XP and NTFS on a single boot
system.

Of course you can. The fact that HDD boot priority can avoid
infection from floppy doesn't mean it can't happen. Not all
systems are configured that way.

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.

Most systems I see these days have CDROM, A, C boot
priority.

And NT *can* be booted from floppy, though that fact is
irrelevant to this discussion (for a free DOS/NT dual boot
floppy go here: http://download.filerecovery.biz).

Once Windows 2000 or XP takes
control, then a boot sector virus on a floppy disk cannot

infect the >system.

True but irrelevant.

Kindly refrain from top posting, please.

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

news:[email protected]...

news:[email protected]...

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

www.ivi.co.il (Hebrew)

InVircible Virus Defense Solutions, ResQ and Data Recovery Utilities

 

[Phil Weldon]

To much too wrong to reply to.

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

Nope, can't get a boot sector virus that way with a

Windows 2000 or >Windows XP and NTFS on a single boot
system.

Of course you can. The fact that HDD boot priority can avoid
infection from floppy doesn't mean it can't happen. Not all
systems are configured that way.

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.

Most systems I see these days have CDROM, A, C boot
priority.

And NT *can* be booted from floppy, though that fact is
irrelevant to this discussion (for a free DOS/NT dual boot
floppy go here: http://download.filerecovery.biz).

Once Windows 2000 or XP takes
control, then a boot sector virus on a floppy disk cannot

infect the >system.

True but irrelevant.

Kindly refrain from top posting, please.

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

news:[email protected]...

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

message
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
--
NetZ Computing Ltd. ISRAEL www.invircible.com
www.ivi.co.il (Hebrew)
InVircible Virus Defense Solutions, ResQ and Data
Recovery Utilities

 

[Ant]

...

Kindly refrain from top posting, please.

Says the person who left in a ton of superfluous quoted text below
his sig.

 

[Phil Weldon]

Ain'i it the truth. Top posting does tend to make trimming easier and the
effects of un-trimmed quotes less annoying.... so what was my excuse ? B^)

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

 

[FromTheRafters]

C:\ (forgotten the name, sorry) which was an image of the boot sector
that existed at the time Win9x installed.

SetUpHardDriveLOG.BAcKup?
SUHDLOG.BAK

 

[FromTheRafters]

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

If you are trying to appear ignorant - kudo's.

 

[Phil Weldon]

Any documentation of "Enabled BIOS 'antivirus protection' causing constant
false alarms greatfully accepted. Shouldn't take more than a couple of
lines.

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

 

[Ant]

...

Ain'i it the truth. Top posting does tend to make trimming easier

But precludes a conversational inline reply (which is why I've
reformatted this, so there isn't a horrible hard-to-follow mix of
stlyes).

and the effects of un-trimmed quotes less annoying....

If it's an older and long post you still have to scroll up and down
to recall what is being replied to.

so what was my excuse ? B^)

Laziness?

 

[Phil Weldon]

Well, generally, when I read a post, I have already read the previous
posts in the thread (how else is one to know whether a post is of
interest... after all, the subject line adds no new information.) Given
that, reading a reply with the previous parts of the thread in line is like
wading through a conversation all over again, and precludes working with
with a split screen, thread above, and post below.

Now as forgetting to trim, I put that down to fatigue, caused by wading (or
scrolling) through the "conversation" so many times; after all, how many
times SHOULD a conversation be repeated? And excerpeted conversation
snippets preceeding a post is even MORE fatiguing.

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

news:[email protected]...

 

[Beauregard T. Shagnasty]

Quoth the raven Phil Weldon:

Well, generally, when I read a post, I have already read the
previous posts in the thread (how else is one to know whether a
post is of interest... after all, the subject line adds no new
information.) Given that, reading a reply with the previous parts
of the thread in line is like wading through a conversation all
over again, and precludes working with with a split screen,
thread above, and post below.

What if you read several hundred posts per day? Do you remember all
that was said in each thread? If it was three days ago? If so, you're
a better man than I am, Gunga Din.

Now as forgetting to trim, I put that down to fatigue, caused by
wading (or scrolling) through the "conversation" so many times;
after all, how many times SHOULD a conversation be repeated? And
excerpeted conversation snippets preceeding a post is even MORE
fatiguing.

One should not quote the entire conversation, except in very rare
cases. One should carefully trim, and retain only significant parts
that are being replied to.

Another point: top posters who use correctly structured sig delimiters
(dash dash space) above the quoted text will cause real newsreaders to
wipe out the previously quoted text. Just like you did. The attribute
to "Ant" that you left in was removed by my newsreader, so I have
little choice to reply to anything you may have left that was said by Ant.

Does anyone else notice that the vast majority of top posters use
Outhouse Distress?

 

[Phil Weldon]

You did not see a quote of the post from 'Ant' because there wasn't any,
just a message ID for link. Don't be so quick to see evil machinations,
there may not be any.

Tell the truth now, were there any posts in this branch of the thread that
you hadn't already read?

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


news:%[email protected]...

 

[Beauregard T. Shagnasty]

Quoth the raven Phil Weldon:

You did not see a quote of the post from 'Ant' because there
wasn't any, just a message ID for link. Don't be so quick to see
evil machinations, there may not be any.

Evil? No, there weren't any quotes from Ant because you trimmed them.
[1] Just as you did here in your reply to me. I though I made that
clear, and my previous post would be in this post if you hadn't
trimmed it.

I said "The attribute to "Ant" that you left in was removed by my
newsreader, ..." The attribute, not the quoted material.

Tell the truth now, were there any posts in this branch of the
thread that you hadn't already read?

Sure I read the thread. Does this mean I have a photographic memory?
Do you expect all readers of your posts to have this capability, even
after reading dozens or hundreds of similar posts? You assume a lot.

You also probably don't realize that many of us have our newsreaders
set to "Display Unread Messages" rather than "Display All." So, we
have to change that option, switch to Threading view, just to see what
the heck you are replying to.

You still haven't moved your sig separator to the end of the post.

[1] I suppose this is better than nothing... it sure helps to
eliminate TOFU.

 

[Zvi Netiv]

Thanks for making the effort. Could you tell us how you infected the dual
boot system with Windows 98SE installed,

From infected floppy.

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?

From infected floppy.

 

[Zvi Netiv]

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.

Take a look at
http://groups.google.com/groups?as_q=f-prot&safe=images&as_uauthors=s. widlake
Obviously, the late Simon Widlake wouldn't agree with you. I stopped
recommending F-Prot for DOS since I saw that it skips directories when run from
the command prompt, under NT based OS.

[snip]

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.

First, not all BSI save a copy of the uninfected sector. Secondly, F-Prot
doesn't check the data block (PT or BPB) in the sector it is restoring. And
last, you should read previous posts in the thread before jumping in the
discussion. The post you have been answering explains how to safely use FDISK
/MBR.

[snip]

Actually, even Win9x posed a barrier to BSVs, as these OSs disallowed
direct disk access.

The reason I still keep Win98SE on a dual boot system (my default system is XP)
is because Win 98 lets me work on and with the RESQ utilities, which are
entirely based on direct disk access. Furthermore, Win 98 still allows to
demonstrate BSI when providing training.

[irrelevant stuff snipped]

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

Uh? The only use of FDISK /MBR is to eliminate virus code from the "partition
boot sector", known as the MBR.

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)

Exactly the purpose for which I suggest running FDISK /STATUS before running
FDISK /MBR, to determine if it's safe to run the latter. Read previous posts.

- you had a DDO to overcome BIOS addressing limitations

Addressed in details, in this thread.

- you had an MBR-based partition/boot manager

Addressed in details, in this thread.

- 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?

You are confusing things. Running FDISK *plain* will do that, and write a
default single partition into the MBR. This was also discussed in a previous
post in this thread.

Regards, Zvi

 

[Ant]

Well, generally, when I read a post, I have already read the
previous posts in the thread [...]

And if the message being replied to has expired, or hasn't arrived on
another news server, what is the reader using that server to make of
your post? You need to quote something to give context.

reading a reply with the previous parts of the thread in line is
like wading through a conversation all over again,

That's why it's important to snip, but leave enough so it is clear
which point you are answering when replying inline.

[...] how many times SHOULD a conversation be repeated?

It's not a matter of repeating a whole conversation, but leaving
snippets of quoted text to give context. I know, many people do not
snip nearly enough.

And excerpeted conversation snippets preceeding a post is even MORE
fatiguing.

But then how is anyone able to make a point-by-point reply?

For a different take on the top/bottom posting argument, and why
contextualized inline posting is a good thing, see here:
http://www.kronatech.com/storage/trimming.mike.easter.pdf

 

[Gabriele Neukam]

On that special day, Phil Weldon, ([email protected]) said...

To much too wrong to reply to.

And for that one sentence, you have to quote 300 lines below?

Exchange-Users, bah.


Gabriele Neukam

(e-mail address removed)

 

[kurt wismer]

The victims of unsuccessful BSI disinfection aren't limited to acv / aca-v.

i didn't say they were... i was using the activity in these groups as a
sample, not a census...

[snip]

Your simplistic and purely formalistic knowledge on the issue really amazes me.

argumentum ad hominem...

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.

the os type should have no bearing on an mbr infector

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.

because the mbr looks so much more like a known virus under NT that
even 4 years after w2k came out anti-virus products still can't see the
difference?

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

and that would be because why exactly? has the mbr become more
complicated since those disinfection routines were written? have the
viruses mysteriously changed? if it were a false alarm i could see
disinfection screwing things up, but false alarms are not the norm...

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.

says you... with no support other than your say so... excuse me if i
fail to overlook your vested interest in promoting this view...

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

perhaps not a university degree, but i think you're forgetting how low
the lowest common denominator is... there are folks who can barely use
a computer, folks who move their lips when they click, etc... fdisk
/status doesn't say "safe to use fdisk /mbr" or "not safe to use fdisk
/mbr", now does it...

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?

have we returned to the conspiracy theories?

lets see - fdisk can't tell you that you have a any kind of virus and
there are some viruses for which the use of fdisk /mbr will cause the
hd to become unbootable...

on the other hand, anti-virus products can tell you when you have a
known virus and ideally should be able to safely remove any virus it
can detect (that's the ideal, mind you, it's understood that all
software has bugs)...

anti-virus software was designed to remove viruses and fdisk wasn't,
that's why anti-virus products were the preferred tool for removing
viruses...

 

[kurt wismer]

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?

the file system makes no difference to an mbr infector as it resides in
an area outside of the file system...

the operating system makes no difference because it is not running when
infection of the hard disk takes place... infection occurs when an
attempt is made to boot from an infected disk - that is the way boot
infectors have always worked... if you were thinking of multi-partite
infectors, that's a different kettle of fish entirely...

 

[kurt wismer]

Nope, can't get a boot sector virus that way with a Windows 2000 or Windows
XP and NTFS on a single boot system.

yes you can...

If the BIOS not set to boot from
floppy disk first

that has nothing to do with the operating system or the file system...

(and why would it be with Windows XP or Windows 2000,
which can't be booted from a floppy disk)

yeah it can... i take it you've never heard of ntfsdos or those linux
boot disks used for ntfs recovery purposes...

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.

once 2k or xp takes control you're past the point at which a boot
infector operates anyways...

you assume that just because someone has 2k or xp that they'll have
floppy booting disabled - that assumption doesn't always hold true...
i, for one, have booted 2k and xp machines from floppies many times for
the purpose of creating or restoring from partition images saved on a
secondary fat32 partition using norton ghost...

 

[kurt wismer]

To much too wrong to reply to.

don't mince words... just stick your fingers in your ears and go "na na
na na na, i can't hear you"...