[pcalvert]

This runs on Windows 98 and does not rely on signatures: System Safety Monitor

[Prozactive]

herbalist has had many long discussions about the use of SSM. I'll try to find the references.

[billyb]

Don't know if this needs to be a new Win 98x Security thread for "2012" topic

Clamwin looks interesting for win98se. I do have the old Norton antivirus 2002... not sure what the "intelligent update" service is that someone mentioned for that. I stopped using Norton 2002 a long time ago when (I think) they sent an email saying no more updates for that one.

Networking the win98se machines to some of my other winxp or win7 machines that have avg free 2012 on them sounds like a do-able plan.

I don't use my win98se machines online much. Maybe I will though after I get the sp3 on.

What about this idea...

My win 98se C drivers are in removable ide bay/trays. So are a couple of my online winxp machines (all have extra drive bays inside for addl drives) that have avg free 2012.

Do you suppose I can slide a win98se fat32 system drive from one machine into ide bay 2 of a winxp online machine, do an avg free 2012 scan of all and catch problems that way? That would certainly be the fastest way for me to do things right now. Anyone try that so far?

I could even do that on a few of the win7 machines that have external ide bays connected.

That would certainly beat the problem of dealing with an antivirus program that may stop win98 support at any moment.

This post has been edited by billyb: 19 April 2012 - 01:16 PM

[JorgeA]

billyb, on 19 April 2012 - 01:10 PM, said:

What about this idea...

My win 98se C drivers are in ide bay/trays. So are a couple of my online winxp machines that have avg free 2012. Do you suppose I can slide a win98se fat32 system drive from one machine into bay 2 of a winxp online machine, do an avg free 2012 scan of all and catch problems that way? That would certainly be the fastest way for me to do things right now. Anyone try that so far?

I could even do that on a few of the win7 machines that have external ide bays connected.

That would certainly beat the problem of dealing with an antivirus program that may stop win98 support at any moment.

I don't use AVG, so I can't speak directly to that, but -- if your AV software can find the 98SE drives where you normally keep them, you should be able to scan them without needing to physically move the drives around.

This is what I do with my Win98 systems and the ESET NOD Online Scanner. Within the application, I tell it to search the network and then I select the drive(s) that I want scanned.

I've also done this with Avast, installed on an XP machine, scanning a 98SE machine over the network. SuperAntiSpyware will do it, too, IIRC.

Hope this helps.

BTW, you can still install and use Spybot Search & Destroy 1.6.2 on Win98 systems (any flavor), including the real-time protection portions of the program.

--JorgeA

[CharlotteTheHarlot]

UPDATE: Success using the latest DATs v6845 with McAfee v6 on Win9x.

• See above Post #40 for the first time I tried this using DATs v6346 ( has detailed instructions ).
  
• See above Post #57 when I tried it again using DATs v6511.

Note that the time/dates shown for these files reflects the download and extraction, which was today. The three downloads that I found ...
- 2012-09-24 ... 16:29 ... 108,306,264 ... 6845xdat.exe
- 2012-09-24 ... 16:31 ... 106,425,344 ... Avvdat-6845.tar
- 2012-09-24 ... 16:31 ... 114,108,032 ... Sdat6845.exe

All three packages contain the same three DAT definition files ...
- 2012-09-24 ... 06:40 ....... 718,817 ... Avvclean.dat
- 2012-09-24 ... 06:40 ....... 487,057 ... Avvnames.dat
- 2012-09-24 ... 06:40 ... 105,206,916 ... Avvscan.dat

As described previously, just strip the "AVV" prefix from the default filenames and replace CLEAN.DAT, NAMES.DAT and SCAN.DAT. Note that the SCAN.DAT actually is smaller by about 20 MB this time compared to last.

The McAfee scan engines contained in the SDAT package still hasn't been changed ...
- 2009-07-31 ... 06:40 ..... 3,182,712 ... Mcscan32.dll
- 2009-07-31 ... 06:40 ..... 4,706,936 ... Mscan64a.dll
... so I updated no other files beyond the three DATs.

As before, it took a long time for McAfee to initialize and load the DATs ( likewise when I changed directories to test scan some known infected files ). But all went well and McAfee scanned files and folders successfully once again.

Pretty impressive because the main executable McAfee file is VSMAIN.EXE v6.01.2000.1 is dated: 2001-11-16. Almost 11 years old.



P.S. Maybe the OP should change the title to: Windows 9x/Me Security Thread for 2011-2012

[jds]

I have previously reported that Symantec Antivrus 9 "real time" (auto protect) functionality was broken if you installed virus definitions post ca. Aug. 2009, although "on demand" (manual) scanning remained functional.

I can sadly report that "on demand" (manual) scanning is now also broken with the latest virus definitions.

To add insult to injury, their 'Norton_Removal_Tool_9x.exe' tool now reports it's expired and I can't figure a way to convince it otherwise. Typically, it directs you to a Symantec site for an updated version, but it's still the same version and it still reports it's expired. As some of you will know, the normal uninstall for SAV still leaves behind lots of files and registry settings, which is why the removal tool was created.

Joe.

[CharlotteTheHarlot]

jds, on 14 January 2013 - 02:30 AM, said:

To add insult to injury, their 'Norton_Removal_Tool_9x.exe' tool now reports it's expired and I can't figure a way to convince it otherwise. Typically, it directs you to a Symantec site for an updated version, but it's still the same version and it still reports it's expired. As some of you will know, the normal uninstall for SAV still leaves behind lots of files and registry settings, which is why the removal tool was created.

Four ideas, though I'll bet you tried the first two already ...

- It may simply read the date/time. Set the clock back ( I know, it's obvious )

- It may phone home. Disconnect internet first, prevent it from getting the current date/time or status from a server somewhere.

- It may have flagged itself as expired. Use a clean original non-executed copy of the Symantec file if you have one, this is to prevent self-modification which happens more frequently than people might imagine. It can easily flag a bit in itself as expired which would make the clock setting irrelevant.

- It may have flagged an external bit as expired. Use a clean original non-executed copy of the file on a computer that has never seen the program run before. Save registry export and filelist before and after. The idea is to capture any changes such as a registry value or even a changed file date/time somewhere that it reads before execution.

Unless I am completely senile I cannot imagine any other avenue it could use to stop working on Win9x. But I could be wrong.

[jds]

CharlotteTheHarlot, on 14 January 2013 - 04:11 AM, said:

jds, on 14 January 2013 - 02:30 AM, said:

To add insult to injury, their 'Norton_Removal_Tool_9x.exe' tool now reports it's expired and I can't figure a way to convince it otherwise. Typically, it directs you to a Symantec site for an updated version, but it's still the same version and it still reports it's expired. As some of you will know, the normal uninstall for SAV still leaves behind lots of files and registry settings, which is why the removal tool was created.

Four ideas, though I'll bet you tried the first two already ...

- It may simply read the date/time. Set the clock back ( I know, it's obvious )

- It may phone home. Disconnect internet first, prevent it from getting the current date/time or status from a server somewhere.

- It may have flagged itself as expired. Use a clean original non-executed copy of the Symantec file if you have one, this is to prevent self-modification which happens more frequently than people might imagine. It can easily flag a bit in itself as expired which would make the clock setting irrelevant.

- It may have flagged an external bit as expired. Use a clean original non-executed copy of the file on a computer that has never seen the program run before. Save registry export and filelist before and after. The idea is to capture any changes such as a registry value or even a changed file date/time somewhere that it reads before execution.

Unless I am completely senile I cannot imagine any other avenue it could use to stop working on Win9x. But I could be wrong.

Hi Charlotte,

Yes, you're right in thinking I'd have already thought of the first two ideas. Alas, so have Symantec, evidently. (Sigh, why can't things be easy for once?)

The file doesn't self-modify. I downloaded a fresh copy (hoping it was actually an updated version) but it was in fact byte-identical to my existing copy.

Unfortunately, I don't have a spare machine to risk installing this now worse-than-useless Symantec bloatware. However, I have used RegMon and FileMon to try to see what this Removal Tool is looking at. I can see it takes a keen interest in some encryption stuff in the registry (apart from looking up what Symantec packages are installed) and also seems to rewrite WIN.INI, however, nothing in either place seems relevant to my eyes.

Because of its keen interest in encryption, it occurs to me that this Removal Tool may actually use its signing certificate to decide if it's expired. Looking at this, I see that it was signed on 2008/2/9 with a certificate valid from 2007/6/15 to 2012/6/15. Now normally, if the signing timestamp is within the validity period, the package is deemed to be valid in perpetuity. However, I suspect Symantec have chosen to use the certificate expiry date as the expiry date for this tool. No doubt when it checks for the validity of the signing certificate, the system will report it is valid but also that the certificate is expired. I'm sure the security checks used on certificates can't be fooled into thinking an expired certificate isn't, by setting the system date or any other simple means.

Going with the "signing certificate validity date" theory, I signed the tool with my company's code signing certificate (which is still current, of course). Unfortunately however, the tool then reported that it wasn't signed, which in other words, meant it was specifically looking for Symantec's signing certificate. Grrr!

Joe.

[dencorso]

jds, on 17 January 2013 - 02:13 AM, said:

The file doesn't self-modify. I downloaded a fresh copy (hoping it was actually an updated version) but it was in fact byte-identical to my existing copy.

That statement put me in action. And I have good news: the following procedure works. I have just tested it for you. Disconnect the machine physically from the internet. Reset the machine date to some day (I used 19) in January, 2009. Turn off the machine. Wait 10 minutes. Turn it on and boot Win 9x (if it runs Scandisk or NDD, abort the scan or it'll find many "wrong dated" files). Once at the desktop, run Norton_Removal_Tool_9x.exe and it'll run OK. Nothing will be installed, the Norton_Removal_Tool_9x.exe is stand-alone. It removed all Norton products all right, except the Norton CrashGuard, which it didn't touch (then again, I'm possibly the last user of the much maligned CrashGuard, but it works all right for me)!

jds, on 17 January 2013 - 02:13 AM, said:

Yes, you're right in thinking I'd have already thought of the first two ideas. Alas, so have Symantec, evidently. (Sigh, why can't things be easy for once?)

Sure. And in the present case they actually are.

[submix8c]

dencorso, on 19 January 2013 - 03:35 PM, said:

<snip>Wait 10 minutes<snip>

Huh? Really? Hot dates?

Ennyhoo, I appreciate the "hey, did it occur to you?" about using it because - I haven't used it for some time now. It appears that I'm running 9x sans-AV but using Outpost (the free one)...

[dencorso]

submix8c, on 19 January 2013 - 05:57 PM, said:

dencorso, on 19 January 2013 - 03:35 PM, said:

<snip>Wait 10 minutes<snip>

Huh? Really? Hot dates?

No. Delivery chinese food.

[JorgeA]

dencorso, on 19 January 2013 - 03:35 PM, said:

jds, on 17 January 2013 - 02:13 AM, said:

The file doesn't self-modify. I downloaded a fresh copy (hoping it was actually an updated version) but it was in fact byte-identical to my existing copy.

That statement put me in action. And I have good news: the following procedure works. I have just tested it for you. Disconnect the machine physically from the internet. Reset the machine date to some day (I used 19) in January, 2009. Turn off the machine. Wait 10 minutes. Turn it on and boot Win 9x (if it runs Scandisk or NDD, abort the scan or it'll find many "wrong dated" files). Once at the desktop, run Norton_Removal_Tool_9x.exe and it'll run OK. Nothing will be installed, the Norton_Removal_Tool_9x.exe is stand-alone. It removed all Norton products all right, except the Norton CrashGuard, which it didn't touch (then again, I'm possibly the last user of the much maligned CrashGuard, but it works all right for me)!

This sounds VERY promising. I ran into this Norton problem with lingering remnants the last time I had to reinstall Win98FE -- couldn't reinstall Norton Internet Security, no matter what I tried with that Removal Tool or how many references to Symantec/Norton I deleted from the Registry. Ended up installing Avast! 4.8 instead, but as of the end of 2012 that's no longer receiving updates (must have been due to the Mayan Calendar) so I may as well uninstall that and try your procedure. Thanks very much for reporting it.

--JorgeA

[Foxbat]

JorgeA, on 19 January 2013 - 11:55 PM, said:

Ended up installing Avast! 4.8 instead, but as of the end of 2012 that's no longer receiving updates (must have been due to the Mayan Calendar) so I may as well uninstall that and try your procedure.

Avast continues to release definitions for 4.8, despite their official announcement of not releasing new definitions after May 2012.

[JorgeA]

Foxbat, on 20 January 2013 - 01:43 AM, said:

JorgeA, on 19 January 2013 - 11:55 PM, said:

Ended up installing Avast! 4.8 instead, but as of the end of 2012 that's no longer receiving updates (must have been due to the Mayan Calendar) so I may as well uninstall that and try your procedure.

Avast continues to release definitions for 4.8, despite their official announcement of not releasing new definitions after May 2012.

I have installations of Avast! 4.8 Home Edition on two different Win98 systems, installed months apart. On one of them the virus database last updated on December 29, on the other it was January 2. When I click to manually update the database, they hang as if they can't connect to the server.

Are you using Avast! 4.8, and are you still getting virus database updates?

--JorgeA

[Giant2011]

Hello I registered Avast 4.8 until November 1 2013. I do not know what happens if Ï would install it off course.

[Foxbat]

JorgeA, on 20 January 2013 - 10:35 AM, said:

I have installations of Avast! 4.8 Home Edition on two different Win98 systems, installed months apart. On one of them the virus database last updated on December 29, on the other it was January 2. When I click to manually update the database, they hang as if they can't connect to the server.

Are you using Avast! 4.8, and are you still getting virus database updates?

You will need to download the update directly from the website yourself. The file can be obtained from this link.
http://www.avast.com...download-update
The definitions are updated daily. I have the link bookmarked for easy access. It is unknown how much longer Avast will continue to provide 4.8 updates. Expect support to cease at any moment.

[JorgeA]

Foxbat, on 21 January 2013 - 12:46 AM, said:

You will need to download the update directly from the website yourself. The file can be obtained from this link.
http://www.avast.com...download-update
The definitions are updated daily. I have the link bookmarked for easy access. It is unknown how much longer Avast will continue to provide 4.8 updates. Expect support to cease at any moment.

That's great to hear, thanks for the link! I'll go in and try that. It'll be a nice "excuse" to fire up IE6 again.

--JorgeA

[jds]

dencorso, on 19 January 2013 - 03:35 PM, said:

jds, on 17 January 2013 - 02:13 AM, said:

The file doesn't self-modify. I downloaded a fresh copy (hoping it was actually an updated version) but it was in fact byte-identical to my existing copy.

That statement put me in action. And I have good news: the following procedure works. I have just tested it for you. Disconnect the machine physically from the internet. Reset the machine date to some day (I used 19) in January, 2009. Turn off the machine. Wait 10 minutes. Turn it on and boot Win 9x (if it runs Scandisk or NDD, abort the scan or it'll find many "wrong dated" files). Once at the desktop, run Norton_Removal_Tool_9x.exe and it'll run OK. Nothing will be installed, the Norton_Removal_Tool_9x.exe is stand-alone. It removed all Norton products all right, except the Norton CrashGuard, which it didn't touch (then again, I'm possibly the last user of the much maligned CrashGuard, but it works all right for me)!

jds, on 17 January 2013 - 02:13 AM, said:

Yes, you're right in thinking I'd have already thought of the first two ideas. Alas, so have Symantec, evidently. (Sigh, why can't things be easy for once?)

Sure. And in the present case they actually are.

Hi Den,

Thanks for trying this out for me. Unfortunately however, MMDV (think YMMV).

I tried many times and also with several "variations on the theme" (disabling the NIC in Device Manager, re-installing SAV, installing NAV, double Ctrl-Alt-Delete, reboot, changing date in DOS), but always the result was the same expiry error. The version I have of this tool has an MD5 hash of 316b61ce6f827a8ee48944e5b076f37c.

BTW, I didn't get any "invalid date" errors from ScanDisk. If you get this, it means Symantec has usurped 'scandisk.exe'. If I recall correctly, the way to restore normal ScanDisk behavior is to delete a file called 'scandisk.alt'.

Joe.

[dencorso]

It's the same file. The MD5 is the same (and the SHA1 is BC6F1C1EB7DCD4FA88A2F8C861A492F36A73C047). The key-points in my method are changing the date in the BIOS to a date later than PE Timestamp of the NRT_9x, but before its certificate's expiry date, and then rebooting with the internet cable disconnected. There remains no way the NRT_9x can ascertain the true date, but it can check it's later than the BIOS default date, so it accepts it as the true date, IMO.
You're right: I deliberately use NDD, so there is a 'scandisk.alt' which is another copy of NDD. I had forgotten the "invalid date"is an NDD thing, though. Please do give it another try, just in case. Good luck!

[jds]

dencorso, on 21 January 2013 - 06:15 AM, said:

It's the same file. The MD5 is the same (and the SHA1 is BC6F1C1EB7DCD4FA88A2F8C861A492F36A73C047). The key-points in my method are changing the date in the BIOS to a date later than PE Timestamp of the NRT_9x, but before its certificate's expiry date, and then rebooting with the internet cable disconnected. There remains no way the NRT_9x can ascertain the true date, but it can check it's later than the BIOS default date, so it accepts it as the true date, IMO.
You're right: I deliberately use NDD, so there is a 'scandisk.alt' which is another copy of NDD. I had forgotten the "invalid date"is an NDD thing, though. Please do give it another try, just in case. Good luck!

Hi Den,

Alas, I still get the same expiry problem. Here are the stats : PE = 2008/2/9, signature = 2008/2/9, certificate expiry = 2010/11/25, file (directory) = 2009/1/14, BIOS (system) = 2009/1/22, network disconnected. I think that complies with the above recommendation. I can only think the security system (already) knows the certificate is expired and that the tool uses that fact to decide it is too.

Joe.

This post has been edited by jds: 22 January 2013 - 02:33 AM