Handling boot viruses
Zvi Netiv
> "Zvi Netiv" <support@replace_with_domain.com> wrote in message
> [snip]
>
> > > So neither is recommended for removing boot viruses?
> >
> > I wouldn't entirely exclude FDISK and SYS, especially not FDISK, from the list
> > of available tools for repairing boot virus damage. After all, their respective
> > action on the boot sector or MBR is implemented in FIXBOOT and FIXMBR, two tools
> > used as part of the repair console of the newer OS.
>
> Understood. My intention was to caution against possibly doing more
> harm than good by implementing either of these without first determining
> exactly which boot virus one is attempting to remove, and the system
> specifics (dual boot, overlay, etc..) being dealt with.
Boot viruses is where AV software always did a lousy job. Lots of false alarms,
misidentification of the virus, and the worst - high percentage of unsuccessful
"disinfection" that ended in loss of access to partition(s), or loss of self
boot ability.
Having said that, you realize that the "exact" determination of the boot virus,
if there is one at all, is not always possible. Worse: Such determination by
AV cannot be trusted and shouldn't be acted upon, especially when multiple
products do not agree on the identification of the alleged virus, or what is
more often the case, only one product claims finding the virus, and the others
see none.
A better approach to boot viruses is the generic one. Follow some rules how to
safely use FDISK /MBR, or FIXMBR:
For platforms that run under DOS, Windows 9x, or Millennium:
- Prepare a boot disk on a clean PC that runs under the same OS which is
installed on the problem PC. Copy FDISK.EXE to the floppy and write-protect the
floppy. A utility that will prepare such floppy for the above mentioned
platforms is MakeResQ from www.invircible.com/iv_tools.php
- Boot the problem PC from the floppy you made.
- When at the A: prompt, run FDISK /STATUS. You should see the details of all
partitions on installed fixed drives. If these details conform with the known
configuration of your drives, especially of the first one, then it's safe to run
FDISK /MBR on that drive.
If your antivirus still finds a virus after having run FDISK /MBR, then change
the antivirus.
Dual boot and overlays:
As I explained elsewhere in this thread, Microsoft's dual-boot is initiated by
the boot sector (NOT the MBR), pointing to the NT loader (NTLDR, followed by
NTdetect.com) and by the content of C:\boot.ini. FDISK /MBR is perfectly safe
to run for such drive.
As to boot overlays: There are two types of these, one originally written by
Ontrack (Disk Manager) and the other known as EZ-bios. FDISK /MBR is the
manufacturer recommended method to rewrite the MBR loader of Disk Manager, in
case it has been corrupted or affected by a virus! For both overlays, you will
have to rewrite the overlay anyway in case of virus infection, as the overlay
was most probably punched by the virus, having relocated the original MBR and
overwritten part of the overlay.
W2K and XP: If Windows starts normally and your AV claims finding a virus in
the MBR, then start the repair console and run FIXMBR. If the AV still claims
that it finds the virus after having run FIXMBR, then replace the antivirus as
it's false alarming.
Regards, Zvi
--
NetZ Computing Ltd. ISRAEL www.invircible.com www.ivi.co.il (Hebrew)
InVircible Virus Defense Solutions, ResQ and Data Recovery Utilities
kurt wismer
[snip]
> Boot viruses is where AV software always did a lousy job. Lots of false alarms,
> misidentification of the virus, and the worst - high percentage of unsuccessful
> "disinfection" that ended in loss of access to partition(s), or loss of self
> boot ability.
and yet the google archives of alt.comp.virus (and to a lesser extent
alt.comp.anti-virus) are chock full of examples of people
*successfully* removing boot infectors with anti-virus products...
[snip]
> A better approach to boot viruses is the generic one. Follow some rules how to
> safely use FDISK /MBR, or FIXMBR:
if only people could remember the rules... generally they wind up doing
(or worse advising) fdisk /mbr totally blind...
--
"we're the first ones to starve, we're the first ones to die
the first ones in line for that pie in the sky
and we're always the last when the cream is shared out
for the worker is working when the fat cat's about"
Phil Weldon
remove! Using the BIOS option to write protect the boot sector of the boot
hard drive pretty well eliminates the possibility of infection by a boot
sector virus.
Repairing the boot sector is either done by booting with a DOS bootable
floppy for DOS or DOS based operating systems. Or the repair console or
booting from the installation disk for NT based windows keeping in mind that
you must have the Administrator account password, a password for another
account that has administrator privledges won't do.
The only way a single boot NT based Windows system can even GET a boot
sector virus is for another type of virus to drop a boot sector virus in the
interval between boot time and the time the protected mode of the operating
system loads and takes control.
--
Phil Weldon, pweldonatmindjumpdotcom
For communication,
replace "at" with the 'at sign'
replace "mindjump" with "mindspring."
replace "dot" with "."
"Zvi Netiv" <support@replace_with_domain.com> wrote in message
news:83cbb0pjkh4lp7ola...@4ax.com...
.
.
Frederic Bonroy
> Boot sector viruses are the easiest of all viruses to prevent and to
> remove! Using the BIOS option to write protect the boot sector of the boot
> hard drive pretty well eliminates the possibility of infection by a boot
> sector virus.
Oh please. That BIOS option is close to useless.
Zvi Netiv
> Zvi Netiv wrote:
> [snip]
> > Boot viruses is where AV software always did a lousy job. Lots of false alarms,
> > misidentification of the virus, and the worst - high percentage of unsuccessful
> > "disinfection" that ended in loss of access to partition(s), or loss of self
> > boot ability.
>
> and yet the google archives of alt.comp.virus (and to a lesser extent
> alt.comp.anti-virus) are chock full of examples of people
> *successfully* removing boot infectors with anti-virus products...
Wrong keywords for the search. ;-) There are more hits for failed disinfection
by AV than successful ones, especially if you limit the search to the last few
years. Nobody would dare having a hernia operation if it had similar mortality
rates to AV disinfection of BSI! :-)
> [snip]
> > A better approach to boot viruses is the generic one. Follow some rules how to
> > safely use FDISK /MBR, or FIXMBR:
>
> if only people could remember the rules... generally they wind up doing
> (or worse advising) fdisk /mbr totally blind...
If you suggested FDISK /STATUS before running FDISK /MBR, instead of sending the
poster on a wild goose chase, then the "rule" would now be common knowledge.
Phil Weldon
--
Phil Weldon, pweldonatmindjumpdotcom
For communication,
replace "at" with the 'at sign'
replace "mindjump" with "mindspring."
replace "dot" with "."
"Zvi Netiv" <support@replace_with_domain.com> wrote in message
news:670eb0dk1gefrqj9s...@4ax.com...
kurt wismer
> kurt wismer <ku...@sympatico.ca> wrote:
>>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...
Zvi Netiv
> 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.
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.
FromTheRafters
"Zvi Netiv" <support@replace_with_domain.com> wrote in message news:83cbb0pjkh4lp7ola...@4ax.com...
> 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
--
Phil Weldon, pweldonatmindjumpdotcom
For communication,
replace "at" with the 'at sign'
replace "mindjump" with "mindspring."
replace "dot" with "."
"Zvi Netiv" <support@replace_with_domain.com> wrote in message
news:beshb0tgqniltqsuf...@4ax.com...
Phil Weldon
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" <support@replace_with_domain.com> wrote in message
news:99phb09fega7n32r6...@4ax.com...
Zvi Netiv
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.
Robert Green
"Phil Weldon" <notdis...@example.com> wrote in message
news:4M9uc.15224$Tn6....@newsread1.news.pas.earthlink.net...
> 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
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.
cquirke (MVP Win9x)
>> 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.
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?
>-------------------- ----- ---- --- -- - - - -
Phil Weldon
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 "."
"Robert Green" <sig...@earthlink.net> wrote in message
news:Smfuc.30589$zO3....@newsread2.news.atl.earthlink.net...
Phil Weldon
--
Phil Weldon, pweldonatmindjumpdotcom
For communication,
replace "at" with the 'at sign'
replace "mindjump" with "mindspring."
replace "dot" with "."
"Zvi Netiv" <support@replace_with_domain.com> wrote in message
news:jm0jb0pdhotub0e0p...@4ax.com...
Phil Weldon
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 "."
"Zvi Netiv" <support@replace_with_domain.com> wrote in message
news:k3tib0pof0be1fkeb...@4ax.com...
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.
Phil Weldon
--
Phil Weldon, pweldonatmindjumpdotcom
For communication,
replace "at" with the 'at sign'
replace "mindjump" with "mindspring."
replace "dot" with "."
"Robert Green" <sig...@earthlink.net> wrote in message
news:omquc.31202$zO3....@newsread2.news.atl.earthlink.net...
Ant
> Kindly refrain from top posting, please.
Says the person who left in a ton of superfluous quoted text below
his sig.
Phil Weldon
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 "."
"Ant" <n...@home.today> wrote in message
news:c9di7f$j9f$1...@news6.svr.pol.co.uk...
FromTheRafters
"cquirke (MVP Win9x)" <cquir...@nospam.mvps.org> wrote in message news:i5ajb05pcbvo71jau...@4ax.com...
> 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
"Phil Weldon" <notdis...@example.com> wrote in message news:_touc.16987$be.1...@newsread2.news.pas.earthlink.net...
> "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
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 "."
"FromTheRafters" <!00...@nomad.fake> wrote in message
news:10bkrja...@corp.supernews.com...
Ant
> "Ant" wrote:
>> "Robert Green" wrote...
>>
>>> Kindly refrain from top posting, please.
>>
>> Says the person who left in a ton of superfluous quoted text below
>> his sig.
> 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
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 "."
"Ant" <n...@home.today> wrote in message
news:c9e4k8$ae1$3...@newsg3.svr.pol.co.uk...
Beauregard T. Shagnasty
> 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? :-)
--
-bts
-This space intentionally left blank.
Phil Weldon
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 "."
"Beauregard T. Shagnasty" <a.non...@example.invalid> wrote in message
news:%Nxuc.109057$hY.9...@twister.nyroc.rr.com...
Beauregard T. Shagnasty
> 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
> >kurt wismer <ku...@sympatico.ca> wrote:
> >> 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.
>
> 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.%20widlake
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]
> >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 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]
> >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).
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.
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.
Gabriele Neukam
> To much too wrong to reply to.
And for that one sentence, you have to quote 300 lines below?
Exchange-Users, bah.
Gabriele Neukam
--
Ah, Information. A good, too valuable these days, to give it away, just
so, at no cost.
Ant
> Well, generally, when I read a post, I have already read the
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
kurt wismer
> kurt wismer <ku...@sympatico.ca> wrote:
>>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.
>>>>
>>>>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.
i didn't say they were... i was using the activity in these groups as a
sample, not a census...
[snip]
>>>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.
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...
>>> 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.
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]
>>>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.
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...
--
"we're the first ones to starve, we're the first ones to die
the first ones in line for that pie in the sky
and we're always the last when the cream is shared out
for the worker is working when the fat cat's about"
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"...
cquirke (MVP Win9x)
>> >kurt wismer <ku...@sympatico.ca> wrote:
>> >> 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.
>>
>> 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.
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...
...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...
...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.
>> 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.
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 :-(
>> >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).
>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.
>> 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.
I can't read previous posts, they're gone!
>> - you had a DDO to overcome BIOS addressing limitations
>> - you had an MBR-based partition/boot manager
>Addressed in details, in this thread.
Good.
>> 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.
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
news:c9fjcv$9pb$1...@newsg4.svr.pol.co.uk
"For a different take on the top/bottom posting argument, and why
contextualized inline posting is a good thing, see here:
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 "."
"Ant" <n...@home.today> wrote in message
news:c9fjcv$9pb$1...@newsg4.svr.pol.co.uk...
FromTheRafters
"kurt wismer" <ku...@sympatico.ca> wrote in message news:UgIuc.81071$tb4.3...@news20.bellglobal.com...
> 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
"Phil Weldon" <notdis...@example.com> wrote in message news:bTNuc.17020$Tn6....@newsread1.news.pas.earthlink.net...
> 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" <n...@home.today> in message
> news:c9fjcv$9pb$1...@newsg4.svr.pol.co.uk
> "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
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 "."
"Ant" <n...@home.today> wrote in message
news:c9gonl$1m8$1...@news8.svr.pol.co.uk...
.
.
.
Big Will
Yes, how do you think they get on the floppy?
--
William
If it don't work, hit it.
If it still don't work, kick it.
If it works after that, than it doesn't matter if that helped, what's
important is it works.
Nemo S.
<!00...@nomad.fake> wrote:
>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.
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.
> > 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?
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.
> > 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...
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.
[...]
> > 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...
What vested interest, in refuting all the nonsense that has been said about
FDISK over the years? That's ridiculous.
[...]
> > 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...
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. ;)
nu...@zilch.com
<support@replace_with_domain.com> wrote:
>> 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.
"Until Win ME" (which isn't NT based)?
>Direct disk access BIOS routines are disallowed under NT based OS.
But what about Win ME? Did you mean precisely what you wrote? It's
confusing.
kurt wismer
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
>>>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...
>>>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?
>
>
> 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...
>>> 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...
>
> 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...
> [...]
>>>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...
>
>
> 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...
> [...]
>>>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...
>
> 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...
>>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.
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]
>>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.
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
"Big Will" <SPAMwSPAMiSPAMlSPAMlSPAMbSPAM4SPA...@nIeDONTtLIKEzSPAMero.net> wrote in message
news:40bc114e$1@darkstar...
> FromTheRafters wrote:
>
> > "kurt wismer" <ku...@sympatico.ca> wrote in message news:UgIuc.81071$tb4.3...@news20.bellglobal.com...
> >
> >
> >>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?
> >
> >
> Yes, how do you think they get on the floppy?
From another OS on which the BSI *is* viable by multi-partite
actions or the ability to run resident. I can see how code beneath
the OS can transmit between devices, but wondered if those NT
based OSes, which as I understand it do not allow any boot code
to remain resident, still allowed the reverse to happen if one booted
from an infected harddrive while a receptive floppy was in the "a"
drive.
...I'm still trying to process Nemo's reply - I had overlooked option
ROM which might not be strictly ROM anymore.
FromTheRafters
"Nemo S." <Ne...@Nemo.net> wrote in message news:2l8ob0tn6g5k06ldi...@4ax.com...
...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
> On Tue, 01 Jun 2004 13:37:18 +0300, Zvi Netiv wrote:
> >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.
>
> "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.
> >Direct disk access BIOS routines are disallowed under NT based OS.
>
> 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
> Art
> http://www.epix.net/~artnpeg
nu...@zilch.com
<support@replace_with_domain.com> wrote:
>nu...@zilch.com wrote:
>> On Tue, 01 Jun 2004 13:37:18 +0300, Zvi Netiv wrote:
>
>> >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.
>>
>> "Until Win ME" (which isn't NT based)?
>
>That correct, Win Millennium isn't NT based.
I know that, of course.
>> 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?
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.
cquirke (MVP Win9x)
>> 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.
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)
>> 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?
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
On Sun, 30 May 2004, Phil Weldon wrote:
> 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.
--
Norman De Forest http://www.chebucto.ns.ca/~af380/Profile.html
af...@chebucto.ns.ca [=||=] (A Speech Friendly Site)
"One suspects that by now even *Nigerians* have Nigeria blacklisted ;)."
-- Jim Seymour on 419 scams, news.admin.net-abuse.email, Tue, Nov 19, 2002
Nemo S.
wrote:
> 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
> 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]
> > 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...
You have no clue on the subject, and you are plain wrong.
[snip]
> > 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...
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.
[...]
> > 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...
Is this the strongest argument you can come with? Very weak!
[...]
> > 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...
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.
kurt wismer
> surprising for someone that poses for a non-conformist.
keep this up and i'm going to wear out the keys on my keyboard that are
involved in typing "argumentum ad hominem"...
> [snip]
>
>>>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...
>
> You have no clue on the subject, and you are plain wrong.
so declareth king zvi... now we shall all go forth and spread his gospel...
> [snip]
>
>>>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...
>
> 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.
and neither of which serve as advertising for your non-free products?
this was covered years ago, zvi... your status as a developer/creator
of anti-virus software (of any type) means that you should not be
casting aspersions on the products of other av vendors... not only are
the statements suspect on their face, it reflects poorly on you...
Zvi Netiv
> "Big Will" wrote in message'
> > > 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, how do you think they get on the floppy?
>
> From another OS on which the BSI *is* viable by multi-partite
> actions or the ability to run resident. I can see how code beneath
> the OS can transmit between devices, but wondered if those NT
> based OSes, which as I understand it do not allow any boot code
> to remain resident, still allowed the reverse to happen if one booted
> from an infected harddrive while a receptive floppy was in the "a"
> drive.
Boot code does not get transferred from HD to floppy during boot time, i.e. the
execution of the partition / boot sector loader. Such transfer takes place with
the OS as intermediary.
Yet the inverse does work (transfer of virus code from floppy to the HD boot
areas).
Big Will
Actually, I'm curious myself to know if a bootvirus can infect after
boot on an NT bases system when after the OS has loaded. Sorry Rafters,
didn't really understand your question, but I think I got it now.
Wouldn't know because I don't have 1) a bootsector virus, and 2) a test
PC running XP. I do remember, however, that it was possible after boot
for a boot virus to infect a floppy disk's boot sector on FAT based
systems. Of course, this was way back when, when we still used DOS and
CPAV was the top-of-the-line scanner.
Peter
Peter
On Thu, 27 May 2004 12:20:07 +0300, Zvi Netiv
<support@replace_with_domain.com> wrote:
>"FromTheRafters" <!00...@nomad.fake> wrote:
>> "Zvi Netiv" <support@replace_with_domain.com> wrote in message
>
>> [snip]
>>
>> > > So neither is recommended for removing boot viruses?
>> >
>> > I wouldn't entirely exclude FDISK and SYS, especially not FDISK, from the list
>> > of available tools for repairing boot virus damage. After all, their respective
>> > action on the boot sector or MBR is implemented in FIXBOOT and FIXMBR, two tools
>> > used as part of the repair console of the newer OS.
>>
>> Understood. My intention was to caution against possibly doing more
>> harm than good by implementing either of these without first determining
>> exactly which boot virus one is attempting to remove, and the system
>> specifics (dual boot, overlay, etc..) being dealt with.
>
>Boot viruses is where AV software always did a lousy job. Lots of false alarms,
>misidentification of the virus, and the worst - high percentage of unsuccessful
>"disinfection" that ended in loss of access to partition(s), or loss of self
>boot ability.
>
>Having said that, you realize that the "exact" determination of the boot virus,
>if there is one at all, is not always possible. Worse: Such determination by
>AV cannot be trusted and shouldn't be acted upon, especially when multiple
>products do not agree on the identification of the alleged virus, or what is
>more often the case, only one product claims finding the virus, and the others
>see none.
>
>A better approach to boot viruses is the generic one. Follow some rules how to
>safely use FDISK /MBR, or FIXMBR:
>
>For platforms that run under DOS, Windows 9x, or Millennium:
>
>- Prepare a boot disk on a clean PC that runs under the same OS which is
>installed on the problem PC. Copy FDISK.EXE to the floppy and write-protect the
>floppy. A utility that will prepare such floppy for the above mentioned
>platforms is MakeResQ from www.invircible.com/iv_tools.php
>
>- Boot the problem PC from the floppy you made.
>
>- When at the A: prompt, run FDISK /STATUS. You should see the details of all
>partitions on installed fixed drives. If these details conform with the known
>configuration of your drives, especially of the first one, then it's safe to run
>FDISK /MBR on that drive.
>
>If your antivirus still finds a virus after having run FDISK /MBR, then change
>the antivirus.
>
>Dual boot and overlays:
>
>As I explained elsewhere in this thread, Microsoft's dual-boot is initiated by
>the boot sector (NOT the MBR), pointing to the NT loader (NTLDR, followed by
>NTdetect.com) and by the content of C:\boot.ini. FDISK /MBR is perfectly safe
>to run for such drive.
>
>As to boot overlays: There are two types of these, one originally written by
>Ontrack (Disk Manager) and the other known as EZ-bios. FDISK /MBR is the
>manufacturer recommended method to rewrite the MBR loader of Disk Manager, in
>case it has been corrupted or affected by a virus! For both overlays, you will
>have to rewrite the overlay anyway in case of virus infection, as the overlay
>was most probably punched by the virus, having relocated the original MBR and
>overwritten part of the overlay.
>
>W2K and XP: If Windows starts normally and your AV claims finding a virus in
>the MBR, then start the repair console and run FIXMBR. If the AV still claims
>that it finds the virus after having run FIXMBR, then replace the antivirus as
>it's false alarming.
>
>Regards, Zvi
Zvi Netiv
> Zvi Netiv wrote:
> > "FromTheRafters" <!00...@nomad.fake> wrote:
> >>From another OS on which the BSI *is* viable by multi-partite
> >>actions or the ability to run resident. I can see how code beneath
> >>the OS can transmit between devices, but wondered if those NT
> >>based OSes, which as I understand it do not allow any boot code
> >>to remain resident, still allowed the reverse to happen if one booted
> >>from an infected harddrive while a receptive floppy was in the "a"
> >>drive.
> >
> > Boot code does not get transferred from HD to floppy during boot time, i.e. the
> > execution of the partition / boot sector loader. Such transfer takes place with
> > the OS as intermediary.
> >
> > Yet the inverse does work (transfer of virus code from floppy to the HD boot
> > areas).
> Actually, I'm curious myself to know if a bootvirus can infect after
> boot on an NT bases system when after the OS has loaded.
Once NT/W2K/XP loaded, there is no way a boot infector can infect. The boot
areas of the hard drive are inaccessible as the OS doesn't allow direct disk
access. Floppies won't become infected either as there is no resident virus
that will initiate the transfer cycle.
> Sorry Rafters,
> didn't really understand your question, but I think I got it now.
> Wouldn't know because I don't have 1) a bootsector virus, and 2) a test
> PC running XP.
Not worth wasting your time on this, there is nothing to explore there.
> I do remember, however, that it was possible after boot
> for a boot virus to infect a floppy disk's boot sector on FAT based
> systems. Of course, this was way back when, when we still used DOS and
> CPAV was the top-of-the-line scanner.
CPAV !? Wasn't it one of the species rescued in Noah's Ark?
The governing factor isn't the file system type, FAT or NTFS, but the operating
system. It so happens that OS that sustain boot infector activity, run on FAT.
The inverse isn't true, i.e. a FAT capable OS doesn't necessarily allow boot
virus propagation. Both W2K and XP will run on FAT/FAT-32, and NT4 will run on
FAT, yet neither sustain boot virus activity once the OS loaded.
Zvi Netiv
> Please see my contribution in alt.comp.anti-virus
There are more effective methods to do that: One is crossposting to all groups
where the thread runs, another method is to point the reader to Usenet archives.
Here is where your contribution is kept for posterity. ;)
http://groups.google.com/groups?selm=cs6ub09cdj86gtpheqgf0siiktd91oqtdp%404ax.com
Regards, Zvi
cquirke (MVP Win9x)
>Boot code does not get transferred from HD to floppy during boot time, i.e. the
>execution of the partition / boot sector loader. Such transfer takes place with
>the OS as intermediary.
I don't see how one can be categorical about that, assuming the boot
code is running at all. It's perfectly positioned to write to
diskette, running as it is before the OS loads.
>------------------------ ---- --- -- - - - -
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet?
cquirke (MVP Win9x)
>> As I said, purely formalistic knowledge. Or shall I say dogmatic? Rather
>> surprising for someone that poses for a non-conformist.
>keep this up and i'm going to wear out the keys on my keyboard that are
> involved in typing "argumentum ad hominem"...
Actually, some of the tone has been so unlike what I've come to expect
from Zvi over the years, that I'm ondering if he isn't being forged.
Or he's having a really bad week ;-)
>-------------------- ----- ---- --- -- - - - -
Trsut me, I won't make a mistake!
>-------------------- ----- ---- --- -- - - - -
nu...@zilch.com
<cquir...@nospam.mvps.org> wrote:
>On Wed, 02 Jun 2004 14:27:00 -0400, kurt wismer <ku...@sympatico.ca>
>>Zvi Netiv wrote:
>>> kurt wismer <ku...@sympatico.ca> wrote:
>>>>Zvi Netiv wrote:
>
>>> As I said, purely formalistic knowledge. Or shall I say dogmatic? Rather
>>> surprising for someone that poses for a non-conformist.
>
>>keep this up and i'm going to wear out the keys on my keyboard that are
>> involved in typing "argumentum ad hominem"...
>
>Actually, some of the tone has been so unlike what I've come to expect
>from Zvi over the years, that I'm ondering if he isn't being forged.
>
>Or he's having a really bad week ;-)
You must have a very short memory. This is very tame stuff for Zvi :)
kurt wismer
[snip]
> Actually, some of the tone has been so unlike what I've come to expect
> from Zvi over the years, that I'm ondering if he isn't being forged.
>
> Or he's having a really bad week ;-)
i think you might be right... hopefully june will provide some better
weeks...
Zvi Netiv
> On Thu, 03 Jun 2004 11:40:37 +0300, Zvi Netiv
>
> >Boot code does not get transferred from HD to floppy during boot time, i.e. the
> >execution of the partition / boot sector loader. Such transfer takes place with
> >the OS as intermediary.
>
> I don't see how one can be categorical about that, assuming the boot
> code is running at all. It's perfectly positioned to write to
> diskette, running as it is before the OS loads.
No boot virus code from those that I disassembled contained routines that will
autonomously seek for a floppy to infect. Clearly, boot virus writers preferred
to concentrate on infecting the hard drive through their autonomous code. As to
infecting further floppies of the hard drive, here they could count on the OS to
participate in the process.
It isn't sufficient that something is just "perfectly positioned" to happen, it
takes the right conditions for it to actually happen, and aren't fulfilled in
our particular case.
cquirke (MVP Win9x)
>> On Thu, 03 Jun 2004 11:40:37 +0300, Zvi Netiv
>> >Boot code does not get transferred from HD to floppy during boot time, i.e. the
>> >execution of the partition / boot sector loader. Such transfer takes place with
>> >the OS as intermediary.
>> I don't see how one can be categorical about that, assuming the boot
>> code is running at all. It's perfectly positioned to write to
>> diskette, running as it is before the OS loads.
>No boot virus code from those that I disassembled contained routines that will
>autonomously seek for a floppy to infect. Clearly, boot virus writers preferred
>to concentrate on infecting the hard drive through their autonomous code.
Nonetheless, the opportunity is there - so I wouldn't want to assume
it won't happen, especially in the context of unknown malware.
>As to infecting further floppies of the hard drive, here they could count
>on the OS to participate in the process.
Or rather, they might have to work around the OS, as well as av
heuristics. I know that's ben done in Win9x, but to do this in NT, a
more lateral approach may be needed, e.g. trojanize the code that
formats diskettes, or drill into some unrelated code with Ring 0
access (a la Witty) and do it from there.
>It isn't sufficient that something is just "perfectly positioned" to happen, it
>takes the right conditions for it to actually happen, and aren't fulfilled in
>our particular case.
If an opportunity exists, it's likely to be exploited someday
>--------------- ------- ----- ---- --- -- - - - -
Sucess-proof your business! Tip #37
When given an NDA to sign, post it on your web site
>--------------- ------- ----- ---- --- -- - - - -
Zvi Netiv
> On Mon, 07 Jun 2004 18:15:06 +0300, Zvi Netiv
> >> >execution of the partition / boot sector loader. Such transfer takes place with
> >> >the OS as intermediary.
>
> >> I don't see how one can be categorical about that, assuming the boot
> >> code is running at all. It's perfectly positioned to write to
> >> diskette, running as it is before the OS loads.
>
> >No boot virus code from those that I disassembled contained routines that will
> >autonomously seek for a floppy to infect. Clearly, boot virus writers preferred
> >to concentrate on infecting the hard drive through their autonomous code.
>
> Nonetheless, the opportunity is there - so I wouldn't want to assume
> it won't happen, especially in the context of unknown malware.
No chance it can happen with the known BSI. Prove me wrong and bring one virus
name that will do that! Or perhaps you claim that someone may still write such
virus? ;-) What for?
FromTheRafters
"Zvi Netiv" <support@replace_with_domain.com> wrote in message news:v1aec09gsqub3hr5k...@4ax.com...
> No chance it can happen with the known BSI. Prove me wrong and bring one virus
> name that will do that! Or perhaps you claim that someone may still write such
> virus? ;-) What for?
POC of course.
How to use this virus:
1) Use the BIOS setup program to allow the machine to boot first from
the floppy.
2) Boot the machine with an infected floppy.
3) Use the setup program to allow the machine to boot first from the
harddrive while a new clean writable floppy is in the floppy drive.
4) Reboot the machine so that the harddrive's virus code can infect the
floppy.
5) Bring the floppy to another machine.
6) Repeat.
I'm sure it will be widespread in no time. ;o)
Big Will
I suppose it would be theoretically possible, however, to write a virus
that alters the OS such that write to and from bootsectors is possible.
However, this wouldn't be a pure bootvirus, but a mixed boot virus and
file-infector virus.
kurt wismer
> FromTheRafters wrote:
[snip]
>> How to use this virus:
>>
>> 1) Use the BIOS setup program to allow the machine to boot first from
>> the floppy.
>> 2) Boot the machine with an infected floppy.
>> 3) Use the setup program to allow the machine to boot first from the
>> harddrive while a new clean writable floppy is in the floppy drive.
>> 4) Reboot the machine so that the harddrive's virus code can infect the
>> floppy.
>> 5) Bring the floppy to another machine.
>> 6) Repeat.
>>
>> I'm sure it will be widespread in no time. ;o)
> I suppose it would be theoretically possible, however, to write a virus
> that alters the OS such that write to and from bootsectors is possible.
> However, this wouldn't be a pure bootvirus, but a mixed boot virus and
> file-infector virus.
you've misread something... the above process does not mention anything
about the virus operating *while* the operating system is running... it
all happens before the the OS loads...
FromTheRafters
"Big Will" wrote in message news:40c75002$1@darkstar...
> I suppose it would be theoretically possible, however, to write a virus
> that alters the OS such that write to and from bootsectors is possible.
I think it is possible anyway, don't these OSes routinely write to
the bootsector? I thought it was only application level software
that wouldn't be able to do this under those OSes.
> However, this wouldn't be a pure bootvirus, but a mixed boot virus and
> file-infector virus.
...but we weren't talking about multipartite viruses, and bootsector virus
code runs before there is a filesystem with which to access most files on
the harddrive. Only files stored in a known physical location could be
accessed by this code to the best of my knowledge.
cquirke (MVP Win9x)
>> On Mon, 07 Jun 2004 18:15:06 +0300, Zvi Netiv
>> >No boot virus code from those that I disassembled contained routines that will
>> >autonomously seek for a floppy to infect.
>> Nonetheless, the opportunity is there - so I wouldn't want to assume
>> it won't happen, especially in the context of unknown malware.
>No chance it can happen with the known BSI. Prove me wrong and bring one virus
>name that will do that! Or perhaps you claim that someone may still write such
>virus? ;-) What for?
What for do any viruses get written? :-)
For every virus, there was a time before that virus existed. During
that time, several practices that we'd view as insane today appeared
to be quite safe and appropriate (at least to some).
Pure BSVs, as we know them (i.e. diskette to HD to diskette) are
unlikely to attract new writers, but MBR and PBR are useful places to
be, for certain ojectives. So I do see future malware using these,
tho more likely after entry via some other route.
As part of av-awareness, such malware might attack other boot media
such as diskettes and USB drives. Diskette is easy - there are BIOS
service routines available for use - but USB more of a challenge.
>---------- ----- ---- --- -- - - - -
NNA Tech Support, 2037:
"Double-click 'My Silo', click Map..."
>---------- ----- ---- --- -- - - - -
Norman L. DeForest
This long thread has left me puzzled. If NT-based versions of Windows
don't allow any low-level access to floppies, how does a Windows NT/2K/XP
user format a floppy disk for use?
FromTheRafters
"Norman L. DeForest" <af...@chebucto.ns.ca> wrote in message
news:Pine.GSO.3.95.iB1.0.104...@halifax.chebucto.ns.ca...
I think that it is only application level software that is denied low-level
access, and I'm not too sure what the OS replaces the BIOS routines
with. Witty apparently found a way to circumvent the barrier between
application and system software, as yet I haven't seen it explained.
Zvi Netiv
> On Wed, 09 Jun 2004 18:19:44 +0300, Zvi Netiv
>
> >> >autonomously seek for a floppy to infect.
>
> >> Nonetheless, the opportunity is there - so I wouldn't want to assume
> >> it won't happen, especially in the context of unknown malware.
>
> >No chance it can happen with the known BSI. Prove me wrong and bring one virus
> >name that will do that! Or perhaps you claim that someone may still write such
> >virus? ;-) What for?
>
> What for do any viruses get written? :-)
>
> For every virus, there was a time before that virus existed. During
> that time, several practices that we'd view as insane today appeared
> to be quite safe and appropriate (at least to some).
>
> Pure BSVs, as we know them (i.e. diskette to HD to diskette) are
> unlikely to attract new writers,
What I have been saying, when you jumped into the discussion. ;)
Regards, Zvi
Zvi Netiv
> This long thread has left me puzzled. If NT-based versions of Windows
> don't allow any low-level access to floppies, how does a Windows NT/2K/XP
> user format a floppy disk for use?
Formatting floppies under NT uses the Windows own functions that replace the
BIOS interrupt 13h services.
Int 13h calls are denied under NT-based OS only if the destination drive is a
fixed one (i.e. hard drive). Floppies are served.
Regards, Zvi
Robert Green
> "Norman L. DeForest" <af...@chebucto.ns.ca> wrote in message
> news:Pine.GSO.3.95.iB1.0.104...@halifax.chebucto.ns.ca...
[snip]
> > This long thread has left me puzzled. If NT-based versions of Windows
> > don't allow any low-level access to floppies, how does a Windows NT/2K/XP
> > user format a floppy disk for use?
>
> I think that it is only application level software that is denied low-level
> access, and I'm not too sure what the OS replaces the BIOS routines
> with. Witty apparently found a way to circumvent the barrier between
> application and system software, as yet I haven't seen it explained.
This should help clarify the matter:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/createfile.asp
<QUOTE>
Physical Disks and Volumes
You can use the CreateFile function to open a physical disk drive or a
volume. The function returns a handle that can be used with the
DeviceIoControl function. This enables you to access the disk's
partition table. It is potentially dangerous to do so, since an
incorrect write to a disk could make its contents inaccessible. The
following requirements must be met for such a call to succeed:
The caller must have administrative privileges. For more information,
see Running with Special Privileges.
The dwCreationDisposition parameter must have the OPEN_EXISTING flag.
When opening a volume or floppy disk, the dwShareMode parameter must
have the FILE_SHARE_WRITE flag.
When opening a physical drive, x, the lpFileName string should be of
the form \\.\PHYSICALDRIVE<x>. Hard disk numbers start at zero. The
following table shows some example physical drive strings.
String Meaning
\\.\PHYSICALDRIVE0 Opens the first physical drive.
\\.\PHYSICALDRIVE2 Opens the third physical drive.
For an example showing how to open a physical drive, see Calling
DeviceIoControl.
When opening a volume or floppy drive, the lpFileName string should be
of the form \\.\<x>:. Do not use a trailing backslash. This would
indicate the root directory of the drive. The following table shows
some example drive strings.
String Meaning
\\.\A: Opens drive A (floppy drive).
\\.\C: Opens drive C (volume).
You can also open a volume by referring to its volume name. For more
information, see Naming a Volume.
</QUOTE>
Bob
--
Robert Green
BootMaster Partition Recovery
http://bootmaster.filerecovery.biz
cquirke (MVP Win9x)
>This long thread has left me puzzled. If NT-based versions of Windows
>don't allow any low-level access to floppies, how does a Windows NT/2K/XP
>user format a floppy disk for use?
The small print is that NT doesn't allow normal applications to
perform low-level disk access - but device drivers, system tools such
as the formatter, and other apps running in Ring 0 still have full
access. I guess that's how Witty gets to splat raw disk writes
through all the nominal NTFS security, as it's acting as the hand
using Black Ice Defender as glove puppet.
>-------------------- ----- ---- --- -- - - - -
Trsut me, I won't make a mistake!
>-------------------- ----- ---- --- -- - - - -
Norman L. DeForest
On Sun, 13 Jun 2004, Zvi Netiv wrote:
> "Norman L. DeForest" <af...@chebucto.ns.ca> wrote:
>
> > This long thread has left me puzzled. If NT-based versions of Windows
> > don't allow any low-level access to floppies, how does a Windows NT/2K/XP
> > user format a floppy disk for use?
>
> Formatting floppies under NT uses the Windows own functions that replace the
> BIOS interrupt 13h services.
>
> Int 13h calls are denied under NT-based OS only if the destination drive is a
> fixed one (i.e. hard drive). Floppies are served.
>
> Regards, Zvi
Thanks! That clears up *one* thing for me. I got the impression from the
discussion here that *all* low-level access to *all* drives was blocked on
NT systems.
However, doesn't that enable multipartite infectors (combination boot
*and* file infectors) to spread to floppy boot sectors from NT systems?
Other discussion here implied that it wasn't possible.
FromTheRafters
"Norman L. DeForest" <af...@chebucto.ns.ca> wrote in message
news:Pine.GSO.3.95.iB1.0.104...@halifax.chebucto.ns.ca...
> However, doesn't that enable multipartite infectors (combination boot
> *and* file infectors) to spread to floppy boot sectors from NT systems?
> Other discussion here implied that it wasn't possible.
I'm pretty sure that this discussion was excluding multipartite viruses.
...but it has been so long....I don't remember...
I think that the multipartite's boot vector would at best only cause the
boot sector to be corrupted if booting to NT based OSes. The file
infector would have the only viable vector.
Zvi Netiv
> On Sun, 13 Jun 2004, Zvi Netiv wrote:
> > > This long thread has left me puzzled. If NT-based versions of Windows
> > > don't allow any low-level access to floppies, how does a Windows NT/2K/XP
> > > user format a floppy disk for use?
> >
> > Formatting floppies under NT uses the Windows own functions that replace the
> > BIOS interrupt 13h services.
> >
> > Int 13h calls are denied under NT-based OS only if the destination drive is a
> > fixed one (i.e. hard drive). Floppies are served.
> Thanks! That clears up *one* thing for me. I got the impression from the
> discussion here that *all* low-level access to *all* drives was blocked on
> NT systems.
Note: Read "NT-based operating systems" anywhere I refer to NT, plain, below.
NT doesn't allow low-level disk access. What you perceive as such are actually
Windows services that replace the BIOS and DOS interrupts by NT's own functions.
Even where NT virtually allows direct disk access, these services aren't a full
substitute for the original Int 13h. For example, Int 13 allows both the
creation and access to and from non-standard tracks on floppies (like higher
than track 80 for 1.44 floppies, or sectors with numbers beyond 18, for same
size floppies). Requests to access sectors outside the range of the standard
format aren't supported under Windows disk access, actually since Win 95.
That fact may have been noticed by users that had protected software which
required the presence of a "key floppy" in the drive, to authenticate that the
software wasn't pirated. These copy protection were based on the creation and
reading from special and non-standard tracks on the "key" floppy. The
introduction of Windows 95 killed the production of these protection schemes as
Win32 couldn't read the special tracks.
For how this is relevant to multipartites, see below.
> However, doesn't that enable multipartite infectors (combination boot
> *and* file infectors) to spread to floppy boot sectors from NT systems?
> Other discussion here implied that it wasn't possible.
Your last question suggests a common misconception about multipartite infectors.
Contrarily to common knowledge, multipartite do not exchange virus code from
floppy to hard drive boot areas, and back. Except Junkie (I was the first to
analyze it, see
http://groups.google.com/groups?selm=0012.9407071059.AA08426%40bull-run.ims.disa.mil
) and Natas, multipartite do not affect the boot area of floppies, only that of
the hard drive (and files, of course).
The multipartite infection mechanism is this: When an infected file is opened,
the virus code copies itself into an overlay on the hard drive, usually to
unused sectors on track 0. The MBR loader is also modified so that the virus
overlay will run the next time the PC is booted. On next boot, the virus goes
resident on reading the overlay under control of the BIOS and the MBR, waits for
the OS to load, and infects additional files by intermediary of the OS services.
The OS is essential to multipartite's file infection, these will not occur
autonomously during boot time, when only BIOS services exist. Basically,
multipartite are *file infectors*, and their boot phase serves just as an
alternate channel to assist propagation.
As you can see, NT poses several obstacles on the way of multipartite: First
and foremost, reverse infection from the hard drive boot areas/overlay to floppy
boot area doesn't occur during the boot stage, not in existing boot infectors.
nor multipartite. For a multipartite to infect the boot sector of a floppy, the
resident code of the virus overlay must survive the transition from the BIOS
controlled phase and the loading of the OS. This doesn't happen as NT purges
memory before loading.
Lastly, even if a multipartite like Natas managed to load under NT, (no chance,
but suppose it did, just for the sake of the discussion) then it would fail
infecting the boot sector of floppies as Windows will not let it create the
non-standard track required on the floppy for the huge overlay that Natas uses.
An overlay of sufficient size is essential to multipartite (the Natas overlay
occupies 4096 bytes, which are eight sectors. One_Half, another multipartite
that was once common, occupies even more!). The latter is one of the reason why
Natas became extinct when Windows 95 appeared.
Zvi Netiv
>
> >This long thread has left me puzzled. If NT-based versions of Windows
> >don't allow any low-level access to floppies, how does a Windows NT/2K/XP
> >user format a floppy disk for use?
>
> The small print is that NT doesn't allow normal applications to
> perform low-level disk access - but device drivers, system tools such
> as the formatter, and other apps running in Ring 0 still have full
> access.
Actually, NT-based OS disallow direct drive access only to hard drives, floppies
are served under NT even by plain 16 bit applications such as FORMAT.COM!
To prove how wrong your above statement is, here is a simple demonstration that
everyone can repeat, and learn from on the internals of Win 9x and NT-based OS.
With XP/W2K running, insert a formatted floppy into drive A:, open the CMD
shell, and issue the DEBUG command (DEBUG is a DOS command, implemented by a 16
bit application program, just as FORMAT). At the debug prompt (a dash) issue
the command L100 0 0 1 (load to memory offset 100 the first sector read from
logical drive A:). Follow with the D command (dump), repeat four times, and you
get the entire content of the boot sector read from A:.
The screen dump below is the boot sector of a floppy that was formatted under XP
by aid of the FORMAT command, issued in the command shell. To exit DEBUG simply
issue the Q command (quit). Here is how the sequence looks on the display:
C:\>debug
-l100 0 0 1
-d
1900:0100 EB 3C 90 4D 53 44 4F 53-35 2E 30 00 02 01 01 00 .<.MSDOS5.0.....
1900:0110 02 E0 00 40 0B F0 09 00-12 00 02 00 00 00 00 00 ...@............
1900:0120 00 00 00 00 00 00 29 7E-A3 DC C8 4E 4F 20 4E 41 ......)~...NO NA
1900:0130 4D 45 20 20 20 20 46 41-54 31 32 20 20 20 33 C9 ME FAT12 3.
1900:0140 8E D1 BC F0 7B 8E D9 B8-00 20 8E C0 FC BD 00 7C ....{.... .....|
1900:0150 38 4E 24 7D 24 8B C1 99-E8 3C 01 72 1C 83 EB 3A 8N$}$....<.r...:
1900:0160 66 A1 1C 7C 26 66 3B 07-26 8A 57 FC 75 06 80 CA f..|&f;.&.W.u...
1900:0170 02 88 56 02 80 C3 10 73-EB 33 C9 8A 46 10 98 F7 ..V....s.3..F...
[ middle sections snipped ]
-d
1900:0280 8B F4 8A 56 24 CD 13 61-61 72 0B 40 75 01 42 03 ...V$..aar.@u.B.
1900:0290 5E 0B 49 75 06 F8 C3 41-BB 00 00 60 66 6A 00 EB ^.Iu...A...`fj..
1900:02A0 B0 4E 54 4C 44 52 20 20-20 20 20 20 0D 0A 52 65 .NTLDR ..Re
1900:02B0 6D 6F 76 65 20 64 69 73-6B 73 20 6F 72 20 6F 74 move disks or ot
1900:02C0 68 65 72 20 6D 65 64 69-61 2E FF 0D 0A 44 69 73 her media....Dis
1900:02D0 6B 20 65 72 72 6F 72 FF-0D 0A 50 72 65 73 73 20 k error...Press
1900:02E0 61 6E 79 20 6B 65 79 20-74 6F 20 72 65 73 74 61 any key to resta
1900:02F0 72 74 0D 0A 00 00 00 00-00 00 00 AC CB D8 55 AA rt............U.
-q
Repeat now the "debug" sequence but this time try reading the boot sector of the
C: (hard) drive, by modifying the load command as follows:
C:\>debug
-l100 2 0 1
NT will warn that an application is attempting to directly access the *hard
drive*, and terminate.
Rests to prove that both DEBUG and FORMAT, from XP, are plain 16 bit
applications. Here is how:
With Windows' Find, look for FORMAT.COM and DEBUG.EXE. Check that the files
found are the correct ones by double clicking them, one after the other,
verifying that they run under XP/W2K, and don't get an "incorrect DOS version"
message. Copy both programs to a Win 98 boot floppy (I checked and made sure
that both applications run under WinDOS 98!).
Boot of the Win98 floppy into pure DOS mode (the default when booting of floppy)
and run FORMAT and DEBUG, every one on its turn, to see that they function
properly, no "ring 0" whatsoever is required. ;-) As both programs run under
plain DOS, then it's clear that they are plain 16 bit applications (advanced
users could tell by the file structure, but the suggested method is preferred as
it will convince even the laymen).
Q.E.D.
Regards, Zvi
cquirke (MVP Win9x)
Thanks for this post and the previous one in which you explained how
current multipartite virus operate - this is great info :-)
>Actually, NT-based OS disallow direct drive access only to hard drives, floppies
>are served under NT even by plain 16 bit applications such as FORMAT.COM!
>With XP/W2K running, insert a formatted floppy into drive A:, open the CMD
>shell, and issue the DEBUG command. At the debug prompt (a dash) issue
>the command L100 0 0 1 (load to memory offset 100 the first sector read from
>logical drive A:). Follow with the D command (dump), repeat four times, and you
>get the entire content of the boot sector read from A:.
>Repeat now the "debug" sequence but this time try reading the boot sector of the
>C: (hard) drive, by modifying the load command as follows:
>C:\>debug
>-l100 2 0 1
>NT will warn that an application is attempting to directly access the *hard
>drive*, and terminate.
That shows you can read raw sectors from diskette through NT, but that
these attempts to so from HD are blocked by NT. Can you write to raw
diskette sectors through NT as well?
A modern, NT-capable bipartite would have several challenges:
- surviving from pre-OS boot into OS
- accessing raw HD from OS
- linkage between pre-OS and OS components
I don't see in-memory survival from pre-OS boot to OS; more likely
communication through the third challenge. The purpose of the pre-OS
code would be to do things that are blocked by the OS.
It could infect diskettes before the OS loads, though as you say,
there's no need to do that from pre-OS code if NT is happy to allow
malware running within NT to do raw diskette writes.
The "Ring 0 factor" may be relevant to the second challenge, i.e. how
the malware running within NT can drop boot code to run before the OS.
That's about as specific as I want to get in a public forum <g>
>--------------- ----- ---- --- -- - - -
Never turn your back on an installer program
Zvi Netiv
> Thanks for this post and the previous one in which you explained how
> current multipartite virus operate - this is great info :-)
Actually, the description applies to boot overlays in general, from BIOS
extenders that assist old BIOSes to access large capacity drives, through boot
managers, and drive access control (those that use a boot overlay).
> >Actually, NT-based OS disallow direct drive access only to hard drives, floppies
> >are served under NT even by plain 16 bit applications such as FORMAT.COM!
>
> >With XP/W2K running, insert a formatted floppy into drive A:, open the CMD
> >shell, and issue the DEBUG command. At the debug prompt (a dash) issue
> >the command L100 0 0 1 (load to memory offset 100 the first sector read from
> >logical drive A:). Follow with the D command (dump), repeat four times, and you
> >get the entire content of the boot sector read from A:.
>
> >Repeat now the "debug" sequence but this time try reading the boot sector of the
> >C: (hard) drive, by modifying the load command as follows:
>
> >C:\>debug
> >-l100 2 0 1
>
> >NT will warn that an application is attempting to directly access the *hard
> >drive*, and terminate.
>
> That shows you can read raw sectors from diskette through NT, but that
> these attempts to so from HD are blocked by NT. Can you write to raw
> diskette sectors through NT as well?
Of course. A thumb rule is that where function 2 (read) of int 13h is
supported, then function 3 (write) is supported too. You could try it for
yourself with DEBUG, by issuing the following sequence:
-RCX (CX register)
CX 000 (return)
:200 (set the CX register value to write 512 bytes)
-W100 0 0 1 (write 512 bytes from memory to sector 0 of drive A:)
(You'll have to format the floppy after the above test as the boot sector will
contain garbage)
> A modern, NT-capable bipartite would have several challenges:
> - surviving from pre-OS boot into OS
This is where your "NT-capable bipartite" concept collapses. We already
established that the transition cannot be done through memory, since NT clears
memory before loading itself. The only possible way to do the transition is by
intermediary of the hard drive. In other words, through file! Theoretically
this could be done by patching one of the NT files (NTLDR is the classic
candidate for the purpose).
The only problem with that scheme is that it doesn't work. Reminds me of the
scientist that could talk to dead, through direct access to the guy's brain via
super chip. The only problem was that the dead guy didn't reply! In order to
work, your bipartite boot code should be able to manipulate a file. The problem
is that only BIOS services are available at boot time and there is no way that
you can manipulate a file on base of these, prior to loading the OS. Not to
mention that there is no file system yet, that will let find and access the
targeted file.
To let you no escape, then let me add this: Suppose that the patching of the NT
file was done after the NT-based system loaded. What would then be the point in
patching NT to load your bipartite, since the virus is already active through a
common PE infection mechanism?
Sorry, but your NT-capable boot/bipartite concept is both logically flawed, and
pointless.
[snip]
> That's about as specific as I want to get in a public forum <g>
Anyway, I guess that we lost almost everyone at this point. ;-)
cquirke (MVP Win9x)
>> On Mon, 14 Jun 2004 20:45:07 +0300, Zvi Netiv
>> Thanks for how current multipartite virus operate - this is great info :-)
>Actually, the description applies to boot overlays in general, from BIOS
>extenders that assist old BIOSes to access large capacity drives, through boot
>managers, and drive access control (those that use a boot overlay).
Yep. They don't do raw writes to diskettes either :-)
>> Can you write to raw diskette sectors through NT as well?
>Of course. A thumb rule is that where function 2 (read) of int 13h is
>supported, then function 3 (write) is supported too.
Well, MS might have been smart enough to allow 13h/02h but block
13h/03h. Hey, it *could* happen!
>> A modern, NT-capable bipartite would have several challenges:
>> - surviving from pre-OS boot into OS
>This is where your "NT-capable bipartite" concept collapses.
I didn't say a BSV could surmount these challenges. I just stated
what a modern, NT-capable BSV would have to do. While these are
insurmountable, I agree we won't be seeing that type of malware.
>The only possible way to do the transition is by intermediary of
>the hard drive. In other words, through file!
Through storage. If raw or alternate access to storage was allowed,
it wouldn't have to be file. A factor is that all the most
interesting non-HD storage that the malware might use are not
supported by BIOS, so the pre-OS code would be bulked up by the
low-level code needed to access that storage.
I can't see a reason to code up reciprocal spreading viability through
BSV, except as a PoC. What I do see is the use of pre-OS access in
order to do things the OS won't allow. So anything that allows
low-level writes to bootable devices from within the OS is a problem.
For example, a NT-hosted malware could drop a data-destructive poison
pill code on diskettes. If any of those diskettes are left in a
bootable drive at boot time, the code could destroy that PC's file
system, even though it wouldn't "infect" it in spreadable form.
Mindset: Thinking malware rather than "virus".
>Theoretically this could be done by patching one of the NT files
>(NTLDR is the classic candidate for the purpose).
The BSV phase would have to know what raw sectors to write to, in
order to throw forward a file that could run within the OS.
Anything that allows...
- raw sector address of files to be determined
- writes to storage that can be read from the BSV phase
...would facilitate that platform shifting traffic.
For example, the NT phase of a malware could create an arbitrary file,
note the raw location of its content, and write that address into
storage somewhere. The BSV phase could get that address from storage
and then do raw writes to populate the file.
I can't think of a reason to do this; I'm just contemplating the
mechanics. The significance is that there's a safety/risk implication
to any function that allows raw sector address of files to be
determined, or that allows writes to BSV-accessible storage.
>..your NT-capable boot/bipartite concept is both logically flawed, and pointless.
I wasn't claiming pointedness; just describing the challenges
involved. If these challenges are currently impossible to overcome,
then that's all well and good - but one (e.g. MS) should keep them in
mind, because future things could drop the parking brake here. If so,
the safety/risk implications may be non-obvious unless etc.
>-- Risk Management is the clue that asks:
"Why do I keep open buckets of petrol next to all the
ashtrays in the lounge, when I don't even have a car?"
>----------------------- ------ ---- --- -- - - - -
FromTheRafters
"Zvi Netiv" <support@replace_with_domain.com> wrote in message news:383tc0l37rbbbjeel...@4ax.com...
[snip]
> This is where your "NT-capable bipartite" concept collapses. We already
> established that the transition cannot be done through memory, since NT clears
> memory before loading itself. The only possible way to do the transition is by
> intermediary of the hard drive. In other words, through file! Theoretically
> this could be done by patching one of the NT files (NTLDR is the classic
> candidate for the purpose).
While were on the subject (sort of), what is the last program (normally)
that is accessed by way of its physical location on disk, i.e. pre file system,
on the NT based systems? Does the active partition's volume boot code
pass program flow to NTLDR due to its physical location?
[snip]
Zvi Netiv
> "Zvi Netiv" <support@replace_with_domain.com> wrote in message
> [snip]
>
> > This is where your "NT-capable bipartite" concept collapses. We already
> > established that the transition cannot be done through memory, since NT clears
> > memory before loading itself. The only possible way to do the transition is by
> > intermediary of the hard drive. In other words, through file! Theoretically
> > this could be done by patching one of the NT files (NTLDR is the classic
> > candidate for the purpose).
>
> While were on the subject (sort of), what is the last program (normally)
> that is accessed by way of its physical location on disk, i.e. pre file system,
> on the NT based systems?
NTLDR starts on my dual boot system drive (XP/Win98SE on FAT-32) at cluster
197,158, which is rather deep in the data area. What do you learn from it?
Next, searching google for "NT boot sector structure" yields a wealth of
information from which I recommend reading:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;114841
http://www.pcguide.com/ref/hdd/file/ntfs/archSector-c.html
The last program that is accessed based on its raw location, prior to loading
the OS, is the active partition bootstrap code, found in the active boot sector,
to which your refer as "volume boot code" (you read the pcguide page, above!).
> Does the active partition's volume boot code
> pass program flow to NTLDR due to its physical location?
Think: Why would NTLDR need to be specified by *name* in the OS bootstrap
program if it could be accessed by its raw location? The available space for
the bootstrap program in the boot sector occupies just about 400 bytes (the rest
of the sector is taken by the BPB and boot signature) and every available byte
must be optimally used.
I believe I know where from your question stems: In early DOS versions, the OS
boot sequence required that the OS loader should be placed first, right after
the root directory, and unfragmented. This requirement doesn't exist anymore
since MS-DOS 4.x or 5 (I am not sure which exactly).
Zvi Netiv
> "Zvi Netiv" <support@replace_with_domain.com> wrote in message
> [snip]
>
> > This is where your "NT-capable bipartite" concept collapses. We already
> > established that the transition cannot be done through memory, since NT clears
> > memory before loading itself. The only possible way to do the transition is by
> > intermediary of the hard drive. In other words, through file! Theoretically
> > this could be done by patching one of the NT files (NTLDR is the classic
> > candidate for the purpose).
>
> While were on the subject (sort of), what is the last program (normally)
> that is accessed by way of its physical location on disk, i.e. pre file system,
> on the NT based systems?
NTLDR starts on my dual boot system drive (XP/Win98SE on FAT-32) at cluster
197,158, which is rather deep in the data area. What do you learn from it?
Next, searching google for "NT boot sector structure" yields a wealth of
information from which I recommend reading:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;114841
http://www.pcguide.com/ref/hdd/file/ntfs/archSector-c.html
The last program that is accessed based on its raw location, prior to loading
the OS, is the active partition bootstrap code, found in the active boot sector,
to which your refer as "volume boot code" (you read the pcguide page, above!).
> Does the active partition's volume boot code
> pass program flow to NTLDR due to its physical location?
Think: Why would NTLDR need to be specified by *name* in the OS bootstrap
program if it could be accessed by its raw location? The available space for
the bootstrap program in the boot sector occupies just about 400 bytes (the rest
of the sector is taken by the BPB and boot signature) and every available byte
must be optimally used.
I believe I know where from your question stems: In early DOS versions, the OS
boot sequence required that the OS loader should be placed first, right after
the root directory, and unfragmented. This requirement doesn't exist anymore
since MS-DOS 4.x or 5 (I am not sure which exactly).
Regards, Zvi
Robert Green
> "FromTheRafters" <!00...@nomad.fake> wrote:
> > "Zvi Netiv" <support@replace_with_domain.com> wrote in
message
[snip]
>>While were on the subject (sort of), what is the last
program (normally)
>>that is accessed by way of its physical location on disk,
i.e. pre file >>system, on the NT based systems?
>
>NTLDR starts on my dual boot system drive (XP/Win98SE on
FAT-32) at >cluster 197,158, which is rather deep in the
data area. What do you >learn from it?
>
> Next, searching google for "NT boot sector structure"
yields a wealth of
> information from which I recommend reading:
>
>
http://support.microsoft.com/default.aspx?scid=kb;EN-US;114841
> http://www.pcguide.com/ref/hdd/file/ntfs/archSector-c.html
Readers might find this page interesting as well...
http://bootmaster.filerecovery.biz/appnote3.html
Contains a brief description of the NTFS boot process with a
disassembly of the boot sector.
With NTFS the boot sector is part of the metadata file
$Boot, and all the boot sector IPL does is load $Boot to
memory and jump into it.
$Boot itself contains code to locate and load NTLDR, which
is a fairly complicated process, since it requires parsing
MFT file record segments as well as the root index.
To add to the speculation on this thread, a look at either
the FAT or NTFS boot sequence should make it clear that is
perfectly possible to have a multi-partite virus which can
replicate on NT via the floppy disk vector. Not practical,
just possible.
Bob
FromTheRafters
"Robert Green" <bob....@filerecovery.biz> wrote in message news:4d7a56ac.04061...@posting.google.com...
> "FromTheRafters" <!00...@nomad.fake> wrote in message news:<10cn86v...@corp.supernews.com>...
> > "Norman L. DeForest" <af...@chebucto.ns.ca> wrote in message
> > news:Pine.GSO.3.95.iB1.0.104...@halifax.chebucto.ns.ca...
>
> [snip]
>
> > > This long thread has left me puzzled. If NT-based versions of Windows
> > > don't allow any low-level access to floppies, how does a Windows NT/2K/XP
> > > user format a floppy disk for use?
> >
> > I think that it is only application level software that is denied low-level
> > access, and I'm not too sure what the OS replaces the BIOS routines
> > with. Witty apparently found a way to circumvent the barrier between
> > application and system software, as yet I haven't seen it explained.
>
> This should help clarify the matter:
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/createfile.asp
Thanks, Bob.
FromTheRafters
"Zvi Netiv" <support@replace_with_domain.com> wrote in message news:a0svc0lutk7h2bfh3...@4ax.com...
> "FromTheRafters" <!00...@nomad.fake> wrote:
> > "Zvi Netiv" <support@replace_with_domain.com> wrote in message
>
> > [snip]
> >
> > > This is where your "NT-capable bipartite" concept collapses. We already
> > > established that the transition cannot be done through memory, since NT clears
> > > memory before loading itself. The only possible way to do the transition is by
> > > intermediary of the hard drive. In other words, through file! Theoretically
> > > this could be done by patching one of the NT files (NTLDR is the classic
> > > candidate for the purpose).
> >
> > While were on the subject (sort of), what is the last program (normally)
> > that is accessed by way of its physical location on disk, i.e. pre file system,
> > on the NT based systems?
>
> NTLDR starts on my dual boot system drive (XP/Win98SE on FAT-32) at cluster
> 197,158, which is rather deep in the data area. What do you learn from it?
Not much really. ;o)
> Next, searching google for "NT boot sector structure" yields a wealth of
> information from which I recommend reading:
>
> http://support.microsoft.com/default.aspx?scid=kb;EN-US;114841
> http://www.pcguide.com/ref/hdd/file/ntfs/archSector-c.html
Thanks for the links, I mightn't have found them myself.
> The last program that is accessed based on its raw location, prior to loading
> the OS, is the active partition bootstrap code, found in the active boot sector,
> to which your refer as "volume boot code" (you read the pcguide page, above!).
Evidently the MFT contains enough information to allow the next code to be
found in the filesystem prior to that filesystem's mechanisms being implemented.
Nice trick - part of the fault tolerance aspect no doubt.
> > Does the active partition's volume boot code
> > pass program flow to NTLDR due to its physical location?
>
> Think: Why would NTLDR need to be specified by *name* in the OS bootstrap
> program if it could be accessed by its raw location?
Sometimes things are as they are despite any *need* to be so.
> The available space for
> the bootstrap program in the boot sector occupies just about 400 bytes (the rest
> of the sector is taken by the BPB and boot signature) and every available byte
> must be optimally used.
Understood.
> I believe I know where from your question stems: In early DOS versions, the OS
> boot sequence required that the OS loader should be placed first, right after
> the root directory, and unfragmented. This requirement doesn't exist anymore
> since MS-DOS 4.x or 5 (I am not sure which exactly).
Yes, that was it. It was in a known physical location and contiguous and
thereafter the file system was in place.
Thanks for your explanation(s).
FromTheRafters
"Robert Green" <las...@hotmail.com> wrote in message news:10d0jab...@corp.supernews.com...
> Readers might find this page interesting as well...
>
> http://bootmaster.filerecovery.biz/appnote3.html
>
> Contains a brief description of the NTFS boot process with a
> disassembly of the boot sector.
Nice. Thanks Bob.
> With NTFS the boot sector is part of the metadata file
> $Boot, and all the boot sector IPL does is load $Boot to
> memory and jump into it.
>
> $Boot itself contains code to locate and load NTLDR, which
> is a fairly complicated process, since it requires parsing
> MFT file record segments as well as the root index.
Yeah, this is what prompted my question about how it was located.