0strodamus

I would like to suggest the following relatively minor improvements to NOD32: 01) Allow the HIPS rules window to remember the last size and position. It is tedious to have to resize this window every time. 02) Add a setting to make the alerts popups open the advanced options drop-down as default. 03) Better wildcard support for the HIPS module. For example, allow items such as "C:\Windows\*.log". 04) Allow wildcards for Source Applications in HIPS rules. As the final rule of 3 out of 4 policies is to allow the action (including the default policy), this would NOT be a dangerous modification. There are instances where this would be quite useful. Some examples: a.) on a system running the Surun application every application needs to be able to launch surun.exe b.) many applications may need to write to "C:\Windows\Rescache\rc000*\rescache.hit" c.) many applications may need to write to "C:\Windows\CSC\v2.0.6\namespace\localhost" It would make rulesets much smaller to integrate all these actions into a single rule for Source Applications "C:\Program Files\*" and "C:\Program Files (x86)\*", instead of so many separate rules. If you've made it this far into my post, thanks for taking the time to read. Any consideration of these changes by the ESET developers would be greatly appreciated.

This is happening to me too, but with EAV, not ESS. It is not the Application update. That worked fine. It is the virus signature database update. This happened with the scheduled update and also a manual update I initiated after a reboot. The last successful update was 8704 (20130819). The update GUI needs a Stop or Cancel button added (unless there's another way to cancel an update I'm unaware of). FYI: There's a couple other users affected who posted in the beta feedback thread.

I don't see anything in the link you provided that states that Windows Defender will disable itself when a 3rd party AV is installed. My post was not intended to be negative. In my opinion, wrong and inaccurate information can often cause more harm than good. I think the information you provided may not be accurate, but of course I could be wrong. That is why I asked about a reference. The burden of proof is on you because you made the statement. This is the nature of having a dialog. I'm sorry if you perceived this as some sort of a personal attack. At any rate, it doesn't matter and I don't want to contribute any more than I already have to derailing this thread.

Where are you getting this information from? IMHO, this beta feedback thread is getting derailed by too much conjecture.

Thanks for the reply Marcos. I'm a home user, so I'll have to just use ecls.exe and go without the GUI results window. I found the knowlegebase article on how to use it, so I should be all set.

Is there any way to manually run a GUI scan other than via the Windows explorer context-menu? I know I can use ecls.exe to perform manual scans. I am just wondering if there is a way to use the GUI from a command line or sendto shortcut and launch a scan of folders and/or files like the context-menu does. I searched the knowledge base and Wilders without success, so I am guessing that it can't be done and would like confirmation. Thanks!

Jetico has released an updated version that fixes the compatibility issues. My sincere thanks to JavierSeguraNA for kindly replying to my thread and for confirming the compatibility issues.

If a user chooses to limit the context menu items displayed in the settings, it causes the context menu text to be too long. Can you revert the text back what it was in version 6 when a user limits the context menu items? I know it was added for clarity, but if a user has selected what to display in the settings, then they don't need the extra text for clarity as they already know what they chose. I hope that made sense. version 6: version 7:

I miss the eye icon, but the e icon isn't so bad. I'm happy the animations are still in place. For me, they are what's most helpful as far as the tray icon is concerned.

Good luck with that! I'm having a hard time finding anything wrong with it too!

I agree that these types of rules can be dangerous, however, they can also cut down greatly on the size of a ruleset. I don't know how much of an effect this has on performance, but it can't hurt. For example, on my system I have a bunch of applications that try to write to "C:\Windows\Rescache\rc0005\rescache.hit" and "C:\Windows\CSC\v2.0.6\namespace\localhost". It would be nice to just allow these file accesses under a rule with source applications "C:\Program Files\*.*" and "C:\Program Files (x86)\*.*" instead of having to add each application one by one. I also use many NirSoft applications and they all write to separate configuration (.cfg) and report (.html) files in the Nirsoft folder that I have them all in. Again, it would be nice to be able to add as the source application "C:\Program Files\NirSoft\*", instead of adding them all individually. Another, example is that I use SuRun and run in a limited account. Many applications need to launch SuRun and it is the only HIPS allowed access that they need. In my opinion, it would be better to create a rule allowing "C:\Program Files\*.*" and "C:\Program Files (x86)\*.*" to launch Surun.exe instead of adding them all individually. And honestly, when the behavior of ESET's HIPS module in, for example, interactive mode is Rules > Ask > Allow on Failure, what is so dangerous? The HIPS will allow anything without a rule anyway. Am I wrong in this conclusion? I can only see the merit of it being too dangerous if a user is running in Policy-based mode as it is the only mode of the 4 available that will block by default. Thanks for the tip regarding quicker editing of the rules. That will come in handy.

After getting my bearings running v6 for a couple weeks, I went ahead and took the plunge with v7.0.104.0. So far, it is running smooth as silk. Great job ESET!

I would like the same feature to be added to the HIPS. I don't think you'll find an answer until ESET decides to add this ability. I've found some clever ways around other limitations in the HIPS, but not this one!

That's what makes ESET special! Why would you want them to just be average like all the other antiviruses?? You can always disable PUA if you don't want the detections. ESET should continue to detect all PUA!

Some improvements that I would like to see in the next beta. ALERTS: Add option to open the advanced options drop-down as default HIPS: Improve rules window to remember position / size HIPS: Allow adding a folder to "Source applications" like "Target applications"; i.e. C:\Program Files\*.* HIPS: Improve file wildcard support; i.e. C:\Program Files\*.ico or C:\Windows\*.log HIPS: Add command line parameter with wildcard support for cmd.exe

First off, I'm not from ESET! I'm just another user like you. If I was you, I wouldn't uncheck self-defense and if you're not having any issues, I would probably leave everything turned on in NOD32 and not worry about it. You'll have to wait until someone from ESET replies to know exactly what to do though. Sorry for any confusion.

I'm curious to hear what responses you get too. Are you on x64? Have you considered using version 4 which doesn't have HIPS?

I'm glad to hear that keeping older versions available makes sense to ESET. It is one of the reasons why I am returning as a customer after an extended absence. Some other industry stalwarts have decided to force customers to upgrade to the most recent versions. However, for reasons you have mentioned this isn't always feasible or desired. Newer versions typically introduce new features and perhaps a customer has another separate application that they like to provide that functionality. And installing two applications that perform the same functions is both redundant and prone to clashes.

I very much like that ESET allows customers the option to run older versions, even if it isn't recommended to do so.

@JavierSeguraNA: Do you have any data yet?

Along with file and folder exclusion, an option to exclude a process would be a nice addition to the beta.

That sounds great! Thanks JavierSeguraNA!

I like the old eye logo better too.

Hi JavierSeguraNA, Thanks for the reply and apology. I am just anxious for a solution, but I also understand that these things happen. Hopefully, when this incompatibility is fixed if I ever need the official support my experience will be better next time. I've been using Jetico since back in the day and it has served me very well. They did update the website recently and it looks nice. I read through the article you referenced and must say that I am impressed with ESET's transparency regarding the specific addresses the software will contact and the reason why. Unfortunately, allowing all of these addresses didn't make any difference with the issues I'm having. I also tried again to simply activate all of the bypass rules within Jetico Firewall without success. In my opinion, this issue goes much deeper than a simple misconfiguration of the firewall's rules. This seems fairly apparent to me based on the symptoms I have observed and that renaming eamonm.sys in safe mode eliminates all of the symptoms. Plus NOD32 version 3 with eamon.sys works fine. Just versions 4-6 and beta 7 with eamonm.sys cause the problems. Something changed between drivers eamon.sys and eamonm.sys. Because of this, I am curious on the testing that has been done on your end. Can you share with me what you are seeing when you test? The Jetico developer confirmed that he was seeing the eamonm.sys issue too, so I'm curious if you guys have as well. Thanks again and I'm looking forward to hearing back from you. EDIT: Grammatical corrections.

I've installed JPF in tandem with EAV v7 beta fine, simply created allowing rules for all operations during installation and both apps seem to be running just fine. If you created allowing rules during installation, too and it doesn't work for you, please create a new topic where we could try to help you troubleshoot the issue. Also post some screen shots to illustrate the issue or give us more details about the issue you encountered, Marcos, did you use the x64 versions? I should have specified that in my original post, which I have updated. The x86 versions do not conflict, only the x64 versions. I just tried again and the conflict remains. I did create a topic located here. I'm not sure how you created allowing rules during installation. NOD32 doesn't prompt for any rules during install. Jetico Personal Firewall only prompts for trusted and blocked network IP addresses. The application rules it creates during install are via the template wizard and I did allow all of the rules it created. I have also completely bypassed all rules in the firewall without success. Unfortunately, the issue goes deeper than a simple misconfiguration of the rules by the end user. Thanks for the reply.