ESET version 5.2.9.1

it is not a "random scan" but a "scan of startup objects" executed as soon as low CPU usage is reached after user logon OR virus signature update.

If you want the scanning during screensaver|logoff|computer lock then you must change the default task parameter "lowest priority" to "when idle".

 

1. The filtering bug is not fixed.

2. If i scan a long path, i won't see a threat name.

 

Rolled back. Maybe next time.

 

Try manually uninstalling using our Uninstaller Tool in safe mode and try reinstalling. If installation keeping rolling back, it could be due to a missing Base Filtering Engine. Try the KB article below:

http://kb.eset.com/esetkb/soln2861&ref=wsf

 

Too many full stops.

 

I rolled back as well. Tired of being on the bleeding edge for vendors.

 

What issue did you have with 5.2.9? Actually it addresses all known issues so I don't see any reason for downgrading to an older one, quite the contrary.

 

Hi Marcos:

When 5.2.9 was downloadable I removed the older version, cleaned up and installed fresh.

Well the first thing that happened I had an h..L of a time turning off the HIPS it was busy generating rules for me and I rely on OP FW Pro for HIPS service and I reply on Nod32 for web control.

I had no idea if these rules would clash with OP's so erroring on the side of caution I reversed the process, put the old one back and restored my configuration. OP looks for Nod as you know and defers to it for web control etc. My issue is I'd like Nod to show the same courtesy in reverse an not assume they control my setup and that Nod is the only product I use.

This was the first time I went early into an update that has yet to appear as available when I check available version it still shows the version I have now.

When that changes I'll try again.

 

I think it must be same with v. 5.0 as nothing has changed in 5.2 in this regard.

 

Given that is the case, the opition to NOT install the HIPS or activate it must have been missed by ME.

I'll still wait till the normal update check says it's ready.

When is that likely to happen?

 

HIPS as well as Self-defense can be disabled under HIPS in the main setup. In learning mode, it's normal that a lot of new rules are created automatically if this is the problem you complained about.

 

Hi Marcos:

Yes this is the problem I had. Here are 2 specific questions for you.

1. Does this mean that IF I had seen and disabled the feature for HIPS Nod 5.2.9.1 would NOT have generated learning mode HIPS rules?
2. Does this mean that IF I had seen and disabled the feature for Self-defense Nod 5.2.9.1 would NOT have generated learning mode Self-defense rules?

 

I don't believe installing 5.x without HIPS is an option. I am as sure as I can be that it is something you have to disable after you have installed NOD32. Obviously, that was a problem when you first installed NOD32 5.x. I don't know what would have happened to me if I had still been using Comodo firewall with Defense + when I first installed 5.x. It might have been a similar experience to yours with OP FW.

 

Yes, I agree with the HIPS part. It matches what I observed. I'm waiting for Marcos. But I'm not frothing over it as I'm stable at 5.0.95.0.

As near as I can tell I have 2 questions outstanding here with no answers yet from Nod32. Silence is golden....

At one time I thought/heard OP and Nod were going to "merge" what a product that would have been

It would have meant Nod32 could focus on malware, and OP could have ignored AV work and focused on FW improvements.

So I have to do it for them. Exclude them from scanning each other. Turning off duplicate HIPS functions etc etc. What a waste.

 

It is still not clear to me what the problem is. With HIPS disabled, no rules are created automatically if it had been enabled and working in learning mode before.

 

Hi Marcos:

I am truly sorry to be unclear. It wastes everybody's time.

Let me be very very blunt.

When I install 5.2.9.1 I want NO HIPS rules to be generated during it's install process it's learning process or any other process invented by Nod32.

Reason is I have HIPS working in OP.

The problem is finding out from you I guess as the man assigned to make it clear how to do this or just say straight out that what I want can't be done.

 

I hope Marcos will clarify this, but it is difficult for me to believe that Outpost FW Pro would be reading any rules file created by Eset NOD32. So, even if there are rules generated before you can disable HIPS in NOD32, I don't believe that OP FW will be affected by these rules. If HIPS is disabled in NOD32, then NOD32 also will not be using any rules. The only way to be sure that there is no conflict is to disable HIPS in NOD32 and watch what happens with OP FW.

 

Well maybe, BUT there is a difference twxt belief and knowing. Nobody is suggesting that OP will "read" Nod 32 rules. This is my computer and I want to control it and not have Nod or OP make decisions for me.

I have less faith in vendor software than others and the less vendors do that I have covered in another tool the better.

I'm waiting for Marcos who should be able to find out for sure so be don't have to post our speculations.

 

Yes, but in the end, the proof is in the use of the software. Else, beta testing would not be necessary because the vendor could state the logical basis for not being concerned about a conflict, but without testing in the real world, over time, there is no certainty that the vendor's position is correct.

As an example, I think that the settings for HIPS in NOD32 should work differently from the way they do. I think that if HIPS is disabled, you should still be able to have self-defense working. Self-defense should be only for the purpose of protecting NOD32 from being controlled by or infected by malware. It should do nothing else. The HIPS enabling option should be for NOD32 to apply HIPS to the rest of the applications running on the computer. Disabling HIPS should allow other software such as Outpost or Comodo to perform the HIPS function without interference from NOD32. That's how it should work, but does it do that in the real world, regardless of what may be said by anyone associated with Eset? The proof is in testing.

 

We the users vary in our testing skills. I hate the notion of having to test om MY time and MY pc to get answers that the vendors has in his/her hip pocket but for some reason just doesn't want to answer.

You are saying that self protrection for Nod 32 is linked to HIPS on or OFF.
On my older version that is the same.

I'm unsure what Nod 32 means by self defense.

I have it password protected which prevents it from being tampered with or hopefully shut down. there is a test. see if it can be shut down while on password protection.

 

Password protection has to do with access to setup, so that is something that can be tested locally. I have not botthered with password protection lately because I have no one else who has local access to my system and no remote access, either. I can set it up to test, however. I will do that later today and see whether it makes any difference. I doubt that it will, but it's worth trying because things don't always work logically with NOD32.

 

That password controls access to specific parts of the ESET GUI, is not intended for registry protection.

Use Regedit.exe instead and you will see how the SelfDefense rules in the HIPS will block that.

For example, try disabling an scheduled task in the scenarios described above

 

As you said, regardless of password protection in Eset NOD32, the task manager can be used to end the egui.exe process IF the settings in NOD32 are that HIPS is disabled but self-defense is enabled. Without HIPS, there is no protection for egui.exe. I verified this myself. However, if you are in a situation where more than one user is set up on a single computer, you would probably want to enable User Account Control so that the ability to access the Task Manager would be restricted to the Administrator and other users would not be able to load that or to run regedit.exe from the command line. Being able to run regedit.exe would allow a user to change many settings on the system.

In the end, I don't think there is much that can be protected if someone has physical access to your system, though whole drive encryption could protect your sensitive data assuming that you don't have the password taped to the underside of a drawer somewhere in the vicinity of your computer.

I would like to add to that this scenario assumes that you have disabled HIPS but left self-defense enabled. In that scenario, it is true that the Task Manager (assuming you have authority to run it) can be used to remove egui.exe. However, the task manager does not remove ekrn.exe in that scenario. Removing ekrn.exe happens ONLY if BOTH boxes, Enable HIPS and Enable self-defense, are UNCHECKED. So, leaving self-defense checked does have some effect. Whether it is a useful effect is open to debate, I guess. Additionally, egui.exe cannot be restarted properly (running the program still leaves the Eset icon showing red) in 5.2.9.1 if it is removed by the Task Manager. This seems to be fixed in beta 6.0. Check the beta 6.0 announcement above and go to the beta forum to see what else might be said about version 6.0 beta.

 

If you Untick both checkboxes you can kill the ESET Service ekrn.exe

Before trying to do that, you must change the Windows Service Recovery options.

 

I have password protection on so malware can't disable or close Nod32 AND if my notebook is lost or stolen it will irritate the crook!

Anyway we continue to work here to help eset debug multiple versions in an open forum.

I checked for newest available version on the update and it still says 5.0.95.0 so all you guys must be debugging 5.2.9.1 and beta 6.

My questions asked multiple times are STILL not answered by Nod 32.