Simple Date Change Renders Smart Security Disabled

[MoRbIdBoY 0]

As a programmer I often have to change the date on my PC to test out the logic of certain scripts and calendar events. (Of course I change it straight back after I've compiled, executed and tested the programs I'm working on).

However, I've noticed a major flaw in ESET Smart Security 10. Setting the date to (for example) 1/1/2050 renders "Real-time file system protection" completely disabled. It doesn't matter if your connected or disconnected from the internet before you change the date. It doesn't matter if you immediately change the date back and/or reboot.

The only way to re-enabled "Real time protection" is to completely uninstall and reinstall ESET Smart Security.

What is the world possibly coming to, when a SIMPLE batch file (for example) which changes the date to some point in the future:

IE Script:

C:\>DATE 1/1/2050

Can render an apparently "Award Winning" anti virus security suite's "Real Time Protection" completely disabled and leave users possibly open to massive virus infection with any event AFTER this simple script?

Absolutely appalled.

 

[Marcos 5,070]

I was unable to reproduce it. Changing the system date to the future will alert the user that the license has expired but the product remains fully functional and continues to download updates.

By the way, I was unable to permanently change the system date. Windows sets it back despite the "Set time automatically" being off.

If ESET stops updating after actual license expiration and is not renewed, Windows will activate Windows Defender protection instead of ESET. However, this does not seem to happen after shifting the system date.

[itman 1,659]

I can verify it is an issue.

The following was performed on Win 10 x64 1607, Smart Security v10 .390. Warning: The following will "trash" your Eset installation and you will have to uninstall and re-install to get Eset working again.

1. Open an admin command prompt window.

2.  Type "Date 3/18/2018" less the quotes for example.

At this point, you will receive a notification from Eset that realtime protection is disabled. After a minute or so, you will receive a notification that Window Defender has been enabled. I forgot to open Process Explorer, so I have no way of verifying that WD was immediately enabled after Eset's realtime protection was disabled. However since the notification took a minute, I suspect there was a period of time when no real time protection was in effect.

3. Repeat above step 2 to reset to current date.

At this point, Eset is "trashed." Eset GUI status on desktop does not indicate any issues. However when the Eset GUI is opened, it indicates realtime scanning is disabled. Opening up Windows security center notes that Eset needs to be renewed with a "Renew" button displayed. Pressing the button does nothing. It also shows that only Windows Defender is running.

Subsequent various attempts to enable Eset realtime scanning were fruitless. This included an attempted repair install. Only fully uninstalling Eset and subsequently re-installing put Eset back to full operational status with Windows Defender turned off.

[Marcos 5,070]

@itman Was Defender still active after a reboot? On my Windows 10, a correct system date was set automatically (despite having the appropriate setting disabled) so after a reboot ESET's real-time protection was active again.

[itman 1,659]

9 hours ago, Marcos said:

@itman Was Defender still active after a reboot? On my Windows 10, a correct system date was set automatically (despite having the appropriate setting disabled) so after a reboot ESET's real-time protection was active again.

Yes. And as I previously posted, I could not get it disabled.

Additionally, Eset was in the status previously described in that desktop GUI icon status showed no issues but opening up the GUI showed Eset realtime protection was disabled.

I forgot to note the Win 10 system date after reboot. If it was reset to current date, it did not have any effect on correcting Eset current status as noted above.

I suspect the issue after reboot was that Win 10 was overriding WD's disabling since Eset's realtime scanning was disabled. Appears system was in some type of realtime scanning "deadly embrace" in that WD couldn't be disabled since Eset realtime scanning was disabled and Eset realtime scanning couldn't be enabled since WD was enabled

There also might be a BIOS factor involved. My motherboard is a bit dated and not UEFI based. Suspect that updating Win 10 system date also updated BIOS date -EDIT- Saw at least one web posting that noted "As time settings tend to be saved to BIOS at time of shutdown." In that case, date change would have persisted after a reboot.

Edited March 21, 2017 by itman

[xxJackxx 85]

For any development or testing we do Virtual Machines are used. I highly recommend one for such things if you have the disk space and RAM to do it. Then you don't have to deal with these issues anymore. Take a VM snapshot, do your test, roll back to the snapshot, nothing broken in any way, and you're still left with a clean test environment.

[Kerma 0]

I can confirm this is still a major issue. I actually made an account just to post this.

I changed the date to test something on my computer, and it "invalidated" my subscription because it was over during the fake date period. Windows defender sent me a notice going "hey, we're taking over because your subscription needs to be renewed, no problem here!". Ok sure, just a simple restart should fix it. I changed the date back using auto date/time and restarted, now it's stuck having real time protection off. The only thing I can see to do is to reinstall or disable windows defender through the registry, both of which are such massive pains I'm considering looking at other antiviruses since I don't want this to happen every time I have to change the date a year or so ahead.