Boot virus on xp

[cquirke (MVP Win9x)]

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.

[/QUOTE]

Take a look at
http://groups.google.com/groups?as_q=f-prot&safe=images&as_uauthors=s. widlake

Let me see if that link works (I have ISP vs. WAN access issues at the
moment, major PITA...) ...ah, yes! Joy!

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.

Well duh, that's to be expected

When I use F-Prot for DOS, it's either formally via a DOS mode
diskette boot, or on-demand to scan yet-to-be-run material (which I
don't store within system dirs).

Using it to informally scan the whole system from within that
?infected system is not smart in a number of ways, but if you see
value in this approach (which I do not) then a Windows-based av will
likely cope with code emulation and settings management better...
though the downside is that Win32PE infectors may infect it while they
wouldn't be able to infect the DOS version.

It's like saying Kavlar body armour's useless, because it won't save
your life if you fall out of a helicopter <g>

BTW: F-Prot themselves recommend caution using F-Prot for DOS within
NT, for a number of reasons. That's part of a bigger debate; the need
for a maintenance OS for NT, especially NT on NTFS. I cover that at
http://cquirke.mvps.org/whatmos.htm

Ah yes...

http://groups.google.com/[email protected]&rnum=4

....is interesting, though I'm not sure if Simon's right about a HD
with multiple active primaries being unbootable. While this is indeed
an anomalous situation, I suspect the code will just shrug and pass
control to the first active primary partition it finds.

This one...

http://groups.google.com/groups?q=f...&[email protected]&rnum=6

....just adds evidence as to why informal av scanning (i.e. looking for
active malware while that malware is actively running) sucks.

But overall, I take your point; one should back up the MBR before
tackling BSVs, irrespective of whether one is using an av scanner or
restore-from-fresh methods such as RC FixMBR or FDisk /MBR

Now that I think of it, that's pretty much what I've been doing - it's
just that it's been so long since I saw a new BSV I'd forgotten. My
SOP is to scan formally without cleaning, save the report one way or
another, then proceed to clean only if I know the malware that's ben
found. When I find a new BSV I read the desc, back up the relevant
sectors, and let the av clean it up. If it does so properly, then if
I see it detect that BSV in future, I let it clean it.

What's wrong with that picture? My assumption that because an av
successfully cleans up BSV A on one PC, it will always successfully
clean up BSV A whenever it encounters it on any PC. This thread has
given me the heads-up to backup the relevant sectors *every* time.

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.

Sorry I missed the start of the thread; I've been away for a while,
and old posts were purged off my ISP's news server :-(

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

Yep, that's basically the point I was making. Whereas it may be
expected that an av would detect and manage a PBR infector, FDisk /MBR
clearly is not going to do that.

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.

I can't read previous posts, they're gone!

Addressed in details, in this thread.
Good.


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.

I've read that behaviour described in the context of FDisk /MBR,
rather than FDisk without parameters, but as it wasn't a rigorous
documentation source that I'd read this, I'd appreciate a URL?

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

Our senses are our UI to reality

 

[Phil Weldon]

From "Ant" <[email protected]> in message
"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 ."

Now contextual, inline posting makes sense, but only if a real,
multi-pointed conversation is in progress. But for most threads, I'd rather
keep track of the discussion in my head, aided by the thread's tree.

As for messages expiring, that's not a problem on the news servers I use
(three month life.)

As for messages that have not arrived, well, that information will not be in
the quotes either.

As for nips and tucks, I'd rather have the whole cloth, rather than someone
else's editing.

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

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

 

[FromTheRafters]

the os type should have no bearing on an mbr infector

An infected floppy can infect (corrupt?) the harddrive, but can
the process work the other way under those OSes? That is,
from the harddrive to the floppy?

 

[FromTheRafters]

As for messages that have not arrived, well, that information will not be in
the quotes either.

I fairly often see responses (with quoted material) before the original
post appears. It is due to the way usenet posts are propagated.

 

[Ant]

From "Ant" <[email protected]> in message
"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 ."

Now contextual, inline posting makes sense, but only if a real,
multi-pointed conversation is in progress.

To me, it always makes sense, even if I'm only answering one point.

But for most threads, I'd rather keep track of the discussion in
my head, aided by the thread's tree.

I see. So would you agree with mike's analysis of the mindset of the
top-poster? I think what he says may be true, in that you prefer to
reply based on an overall impression, rather than respond precisely
to particular chunks of text. In fact you did respond to my points,
but chose to do it out-of-line rather than inline.

As for messages expiring, that's not a problem on the news servers
I use (three month life.)

On my server expiration time varies depending on the group. Some are
as long as 3 months, but others as short as 2 weeks. I don't know why
it's this way, since the short-time groups I've seen are low traffic
text-only, therefore it's not a storage space issue. If someone on
another server with a longer retention time replies to an older post
and doesn't quote properly, then it's a problem for the short-timers.

As for messages that have not arrived, well, that information will
not be in the quotes either.

The message may have arrived on your server, but not on mine. It may
never show up on mine. I see this frequently when a post contains an
attibution which is obviously from an anon remailer (Anonymous, Frog,
An Metet). My server often doesn't receive these.

As for nips and tucks, I'd rather have the whole cloth, rather than
someone else's editing.

Which you normally have in your threaded newsreader. On that rare
occasion when you want more context you can go back and re-read the
earlier post.

I haven't snipped any of your post here, because I think all of it
was required to maintain context, and I had something to say about
each part. The amount of quoted text is less than the amount of
original text, and I can't believe it was tiresome to see your words
quoted inline. They are there as aide memoirs - you can just skim
over them.

 

[Phil Weldon]

Just some comments on my news server experience; Earthlink keeps messages
from newsgroups that
it carries for three months regardless of volume (though Earthlink does
limit downloads an account can make from its news servers to one Gbyte per
month. I don't think I've seen more than one or two posts in the last
several years for which the previous post is missing. Anyway it is probably
not a Good Thing for a thread to go past two or three weeks in a newsgroup
like this. It isn't as if there is much added value after that time.

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


..
..
..

 

[Nemo S.]

An infected floppy can infect (corrupt?) the harddrive, but can
the process work the other way under those OSes? That is,
from the harddrive to the floppy?

Yes !! Your bypassing the OS in the first place and DDA is at the
hardware level before the OS Kernel is even loaded to prevent it and
it can hide in ANY place that has any cache where ever it is
successful in writing itself too including FLASH, a HARDWARE flush of
ALL memory spaces and Cache's on the motherboard every drive including
CD-ROMS and Floppies and a reflush and check by the OS would help
prevent this, IF you do not give it a place to live it dies and
becomes useless, worthless and obsolete ...


~Nemo~

~Nemo~

 

[Zvi Netiv]

Sorry I missed the start of the thread; I've been away for a while,
and old posts were purged off my ISP's news server :-(

I am referring to posts of the last couple to three days. I wouldn't consider
that old.

Since you post as lot on Usenet, then it could be worth to subscribe to a
specialized news server.

Regards, Zvi

 

[Zvi Netiv]

Zvi Netiv wrote:
[...]

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

Not what I wrote. Read ... "BSI and AV related issues". As said, simplistic
and purely formalistic knowledge.

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?

No. The reason is the way AV implement BSI detection under NT based OS, when
deprived of the INT 13h routines that were available to them until Windows
Millennium. Direct disk access BIOS routines are disallowed under NT based OS.

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

Poor and simplistic reasoning. What changed is the interaction between the many
factors that participate on the issue. First, most BSI are based on old INT 13h
routines, and FAT-12/16 in mind. So were the AV disinfection routines. Since
then, large capacity drives appeared, Int 13 evolved into extended Int 13
(through the upgrading of the ATA standards), FAT-32 came about, and NTFS became
more popular. The last two have significant changes in the boot chain, that
have an impact on what BSI do to them. The only thing that didn't change are
the AV detection and disinfection routines, that unsurprisingly do fail when
applied in the wrong conditions with different parameters. BTW, false alarms
*are* the norm for BSI alerts under W2K and XP.

[...]

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

What vested interest, in refuting all the nonsense that has been said about
FDISK over the years? That's ridiculous.

[...]

perhaps not a university degree, but i think you're forgetting how low
the lowest common denominator is...

Why do you think that you are the only intelligent creature in the North
Hemisphere and everyone else are stupid?

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

Invalid argument. Using an antivirus requires much more from the user than my
suggestion.

[...]

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

Alarmist. This was covered in details in my previous post.

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

Formalistic and wrong as explained above, and in previous posts.

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

FDISK /MBR was designed to rewrite the partition loader, when corrupted, and the
main reason for that was BSI. The avoiding of FDISK /MBR till now is the result
of a scare campaign that was initiated by the AV producers, and not of users
preference.

Fact that FDISK /MBR is suggested time and again as the more common cure to boot
infectors, and you as well as others would render a better service to users in
explaining how to use it safely, and when to avoid it. You'll be surprised how
few are the instances where FDISK /MBR should not be used. Where FDISK /MBR
should be avoided, antivirus won't help either - they'll need Bob Green's
assistance, or mine.

Regards, Zvi

 

[kurt wismer]

An infected floppy can infect (corrupt?) the harddrive, but can
the process work the other way under those OSes? That is,
from the harddrive to the floppy?

if the boot sequence is changed such that no attempt is made to boot
from the floppy then i see no reason why an infected mbr couldn't
infect a floppy in the drive during boot-up... i don't know if there
are any viruses that will actually do that...

and obviously, after boot-up it's out of the question for most mbr
infectors under more recent OSes...

 

[kurt wismer]

Zvi Netiv wrote: [snip]

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

Not what I wrote. Read ... "BSI and AV related issues". As said, simplistic
and purely formalistic knowledge.

and as i said, argumentum ad hominem...

No. The reason is the way AV implement BSI detection under NT based OS, when
deprived of the INT 13h routines that were available to them until Windows
Millennium. Direct disk access BIOS routines are disallowed under NT based OS.

this is a non-issue... why, exactly, would one be trying to deal with a
boot infector in any circumstance other than after booting from a
clean, bootable floppy disk (which won't be an NT based OS) which has
been the de facto advice for boot infectors for years and years?... you
seem rather persistent in overlooking that condition for proper bsi
handling with av products... heck, your own safety rules for fdisk /mbr
require the same thing...

Poor and simplistic reasoning. What changed is the interaction between the many
factors that participate on the issue. First, most BSI are based on old INT 13h
routines, and FAT-12/16 in mind. So were the AV disinfection routines. Since
then, large capacity drives appeared, Int 13 evolved into extended Int 13
(through the upgrading of the ATA standards), FAT-32 came about, and NTFS became
more popular. The last two have significant changes in the boot chain, that
have an impact on what BSI do to them. The only thing that didn't change are
the AV detection and disinfection routines, that unsurprisingly do fail when
applied in the wrong conditions with different parameters.

the routines were updated (as necessary) to deal with larger drives and
fat32... those were around long before nt based OSes became popular -
boot infectors were still being written back then... i think you've
made a hasty generalization here...

BTW, false alarms
*are* the norm for BSI alerts under W2K and XP.

says you...

[...]

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

What vested interest, in refuting all the nonsense that has been said about
FDISK over the years? That's ridiculous.

no, in promoting the view that conventional av's are ill suited to deal
with boot infectors... your interest lies in the fact that you have a
not-so-conventional av that, among other things, deals with boot
infectors...

[...]

perhaps not a university degree, but i think you're forgetting how low
the lowest common denominator is...

Why do you think that you are the only intelligent creature in the North
Hemisphere and everyone else are stupid?

you've read more into my statement than is actually there...

Invalid argument. Using an antivirus requires much more from the user than my
suggestion.

there are known viruses which fdisk /mbr cannot cope with... there
should be no known viruses which an av cannot cope with...

[...]

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

Alarmist. This was covered in details in my previous post.

what was covered was the fact that there are circumstances when fdisk
/mbr is not to be used... what wasn't covered was that in the case of
av products there should be no known bsi which the av product can't
remove...

[snip]

FDISK /MBR was designed to rewrite the partition loader, when corrupted, and the
main reason for that was BSI.

oh really? and you know it was put there for that reason how? unless
you've got insiders working in redmond i'd say you're talking out of
your arse on this one...

The avoiding of FDISK /MBR till now is the result
of a scare campaign that was initiated by the AV producers, and not of users
preference.

the avoiding of fdisk /mbr was initiated at a time when many of the
prevalent boot infectors were ones which fdisk /mbr didn't handle well
or at all... add to that that /mbr was an undocumented switch for which
there were no caveats or safe usage rules...

fdisk /mbr was a quick hack that someone discovered worked with some
boot infectors and started advising as a general boot infector cure -
that didn't make it so...

Fact that FDISK /MBR is suggested time and again as the more common cure to boot
infectors, and you as well as others would render a better service to users in
explaining how to use it safely, and when to avoid it. You'll be surprised how
few are the instances where FDISK /MBR should not be used. Where FDISK /MBR
should be avoided, antivirus won't help either - they'll need Bob Green's
assistance, or mine.

and there's that vested interest popping up again...

 

[FromTheRafters]

Yes !! Your bypassing the OS in the first place and DDA is at the
hardware level before the OS Kernel is even loaded to prevent it and
it can hide in ANY place that has any cache where ever it is
successful in writing itself too including FLASH, a HARDWARE flush of
ALL memory spaces and Cache's on the motherboard every drive including
CD-ROMS and Floppies and a reflush and check by the OS would help
prevent this, IF you do not give it a place to live it dies and
becomes useless, worthless and obsolete ...

....and if it can't replicate recursively on those OSes, it might not
be considered a virus on those OSes - I had overlooked the
*other* possible places a replicant could be written to.

Thanks.

 

[Zvi Netiv]

"Until Win ME" (which isn't NT based)?

That correct, Win Millennium isn't NT based. You could tell from the fact that
ME doesn't recognize NTFS. Other tell tales are the ME system files, IO.SYS,
and MSDOS.SYS, while NT based OS load through NTLDR and NTDETECT.COM. The last
two aren't part of the ME startup.

But what about Win ME? Did you mean precisely what you wrote? It's
confusing.

Win ME is the last of the DOS based OS. The fact that ME *seems* to boot
directly into Windows shouldn't fool you. Just replace the copy of IO.SYS in
C:\ with the one in %windir%\command\EBD and you will be able to start ME in
plain old DOS command prompt mode (by aid of the F8 key). That little trick is
at the base of my MAKERESQ utility, in ME's case. ;-)

What made you think that ME is based on NT?

Regards, Zvi

 

[null]

That correct, Win Millennium isn't NT based.

I know that, of course.

Win ME is the last of the DOS based OS. The fact that ME *seems* to boot
directly into Windows shouldn't fool you. Just replace the copy of IO.SYS in
C:\ with the one in %windir%\command\EBD and you will be able to start ME in
plain old DOS command prompt mode (by aid of the F8 key). That little trick is
at the base of my MAKERESQ utility, in ME's case. ;-)

What made you think that ME is based on NT?

I didn't. It was your phraseolgy that's confusing. When you said
"until ME" you implied ME is included along with NT based OS.
The confusion is probably because english isn't your first language,
but I wasn't being picky. I wondered if, for some odd reason, ME is
also included in the "deprived of the INT 13h routines". But I guess
you hadn't meant to say that it is.


Art
http://www.epix.net/~artnpeg

 

[cquirke (MVP Win9x)]

I am referring to posts of the last couple to three days. I wouldn't consider
that old.

The news service might ;-)

Since you post as lot on Usenet, then it could be worth to subscribe to a
specialized news server.

I don't think so, for a couple of reasons:
- I volunteer time to read this stuff, I'm not about
to pay extra money too
- accessing a server located elsewhere is slower++,
due to local peculiarities of WAN traffic flow

It's also not often that I break continuity - just when I travel
overseas, really, which is usually once a year. At such times, the
prospect of 5000 catch-up posts on re-entry is quite daunting, so I
often delay re-entry for a couple of days, then catch up, read/respond
to threads I'm already watching, purge (unread) new headers, get new
headers again, and *then* look for new threads of interest.

That stops me rejoining threads on posts that may be several days old,
but also means I only have the latest posts in existing threads.

Perhaps a point worth making is that each post has to function within
itself - you cannot assume readers will have read previous posts, for
a variety of reasons, such as...
- mis-ordered propagation
- users (re-)joining midway through a thread
- news servers that have flushed previous posts
....etc. Where advice becomes dangerous when stripped of prior thread
content, it's good practice (though tedious, I know) to retain
sufficient quotage or precis to properly contextualise the advice.

IOW it doesn't help if I get a better news service to read the whole
thread, if some newbie pops in out of the blue to look up what to do
with a suspected BSV and reads one post in isolation.

Newsgroup posts are also sometimes harvested and re-used in other
contexts; for example, the URLs you gave to Google up Simon's past
posts finds these posts but not the rest of the threads they were in.

I mention the above as a general discussion and a heads-up to us all,
not as a specific critisism of Zvi and other posters in this thread!

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

Who is General Failure and
why is he reading my disk?

 

[cquirke (MVP Win9x)]

An infected floppy can infect (corrupt?) the harddrive, but can
the process work the other way under those OSes? That is,
from the harddrive to the floppy?

Yes and no. If a BSV doesn't do anything to alter the picture, it may
prevent NT from loading at all. If it was able to exist after NT
loads, then NT would theoretically disallow it from accessing
diskettes etc. at the low level required to infect them.

In Win9x, it's a bit different. A BSV will typically redirect the
low-level raw disk service interrupt vectors, and when Win9x loads, it
interprets this as custom raw disk code that should not be supplanted
with the standard Win9x driver code. As a result, affected drives are
left in DOS compatibility mode, which also means there's no longer an
OS barrier to the low-level access required to infect those drives.

That's an interesting situation, in that diskettes and HDs have
different low-level code - so typically a HD infected with a BSV might
drop the HD's code into DOS compat mode (and thus infectability) while
the diskette subsystem remains natively driven and uninfectable.
That's assuming the BSV hasn't grabbed the ISVs for both diskette and
HD disk services, as would usually be the case.

So AFAICR some BSVs take steps to knock down Win9x's native diskette
handling code, so as to force that subsystem into infectable DOS
compatibility mode. I can't remember whether this logic was within
the BSV itself, or within a BSV dropper that arrives via some other
vector. The latter approach makes sense for a number of reasons:
- opportunities to infect via the boot process are fewer nowadays
- modern OSs are more difficult to survive in and infect through
- BSVs are small, easy to carry in and drop from the bomb bay
- BSVs enjoy direct hardware access for more destructive payloads
- chance to infect boot media from insufficiently formal clean-ups
- the above allows local but off-PC persistance though clean-up

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

No, perfection is not an entrance requirement.
We'll settle for integrity and humility

 

[Norman L. DeForest]

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?

[snip]

You could get it the way I got infected once. A brief power-failure
followed immediately by the BIOS skipping the hard drive and booting off
a floppy disk because the power-failure made the hard drive controller
fail the POST (even though the BIOS was set to try the hard drive first).
(I was half way through typing an "f-prot" command to check the floppy
disk when the power went off for about a second and came back on and then
the computer booted from the floppy drive even though the CMOS was set to
the order, C: then A:.)

In cases like that, even Linux systems could get infected because the
boot-sector virus gets to do its thing before any of the operating system
is loaded.

 

[Nemo S.]

it might not be considered a virus on those OSes

No it's still a virus by it's nature, construction and processes, just
not one that is able to function any longer within the boundries of
its programed matrix and in a very short period of time could / should
be extinct as scanners are SUPPOSE detect and remove ALL fragments
from all files in the first place, even IF some one keeps re-releasing
the damn thing, once a virus always a virus unless of course it has a
built in evolutionary or mutating processes, virus > worm > trojan >
worm > virus > trojan etc.. etc.. etc .. of course that is where
Hueristics are SUPPOSE to work but who knows ...

My own Opinion is that NONE of these little nasties should have EVER
been released outside of an isolated and controlled enviroment.

~Nemo~


~Nemo~

 

[Zvi Netiv]

I know that, of course.

Speaking of ambiguity, your phrasing and punctuation could be understood the way
I did. Terminating the phrase with a question mark, with no other punctiuation
that indicates anything else, suggests that the whole phrase should be
interpreted as a question. If you wanted the phrase in parentheses to be
interpreted as an assertion, then you could either add an exclamation mark
before closing the parentheses, or better, split the phrase into two separate
ones, a question, and an assertion.

As follows: "Until Win ME" (which isn't NT based!)? or "Until Win ME"? Which
isn't NT based, AFAIK!

I didn't. It was your phraseolgy that's confusing. When you said
"until ME" you implied ME is included along with NT based OS.

Specifying a range, by "to", "till", or "until", may include or exclude the
upper limit. Normally, the correct meaning is resolved from context, or as was
the case here, common knowledge.

The confusion is probably because english isn't your first language,
but I wasn't being picky.

You were.

I wondered if, for some odd reason, ME is
also included in the "deprived of the INT 13h routines". But I guess
you hadn't meant to say that it is.

What I meant is that ME supports the Int 13h BIOS routines, just like Windows
9x.

Regards, Zvi

 

[Zvi Netiv]

Zvi Netiv wrote:
[snip]

No. The reason is the way AV implement BSI detection under NT based OS, when
deprived of the INT 13h routines that were available to them until Windows
Millennium. Direct disk access BIOS routines are disallowed under NT based OS.

this is a non-issue... why, exactly, would one be trying to deal with a
boot infector in any circumstance other than after booting from a
clean, bootable floppy disk (which won't be an NT based OS) which has
been the de facto advice for boot infectors for years and years?...

As I said, purely formalistic knowledge. Or shall I say dogmatic? Rather
surprising for someone that poses for a non-conformist.

[snip]

the routines were updated (as necessary) to deal with larger drives and
fat32... those were around long before nt based OSes became popular -
boot infectors were still being written back then... i think you've
made a hasty generalization here...

You have no clue on the subject, and you are plain wrong.

[snip]

no, in promoting the view that conventional av's are ill suited to deal
with boot infectors... your interest lies in the fact that you have a
not-so-conventional av that, among other things, deals with boot
infectors...

There is no gain in promoting that. My boot handling utilities
(www.invircible.com/iv_tools.php) are free and so is the assitance I extend on
Usenet.

[...]

oh really? and you know it was put there for that reason how? unless
you've got insiders working in redmond i'd say you're talking out of
your arse on this one...

Is this the strongest argument you can come with? Very weak!

[...]

and there's that vested interest popping up again...

A vested interest in what, in soliciting free assitance? Check
http://groups.google.com/groups?q=+ivinit+OR+resqdisk+author:netiv&scoring=d and
let's see if you can match that.

Regards, Zvi