Emsisoft Anti-Malware & Emsisoft Internet Security 10 available

If you could reproduce it then sure, go ahead! It might be easier for Emsisoft to fix this problem that way

 

Just did it.

 

We are currently looking into it. Can you disable SSL encryption in the privacy settings and check if you continue to experience these issues?

 

The only SSL connection I have during updating is to www.emsisoft.com. That connection is not the issue. The multiple connections previously described all occur for connections to Edgecast servers I believe EAM uses for BD signature updates. None of those are HTTPS; all are HTTP.

 

Just to be sure:

You have over a hundred connections open at the same time in some kind of waiting state to Edgecast servers?

 

Yes. Today it was 263 connections with no more than 8 - 10 actually being used.

 

In general there will be at least one connection for every file to be downloaded, sometimes more. An hourly update from Bitdefender can easily change 30 files. So keeping your PC off for a night can easily result in a hundred or more files in need of updates in the morning. Connections should be closed after they have been used though and you shouldn't end up with that many connections in parallel. If connections end up being half-open (CLOSE_WAIT, FIN_WAIT or FIN_WAIT2 state) that is definitely not intended. It may however not be in our power to fix them. It could be that one of the routers in between you and the server is filtering out FIN or ACK packages, which usually result in these half open connections. If you were using Windows 95 this could be a potential issue, as the hard limit of TCP/IP connections was 256. But on modern operating systems this technically shouldn't pose an issues. So while it may look like a big issue, it isn't. Nonetheless, we are looking into ways of preventing them.

 

You were right on the file count. Just checked update log and 264 files were downloaded this morning. Most were under 1000 bytes. Appears BitDefender when it comes to updates is still in the Stone Age. Or perhaps the price you have to pay for using their engine; the brute force update technique versus finesse?

Eset updates 3 times a day, does so in a few seconds, and uses no more than a couple of ports. Ditto for the first boot of the day; a few ports used and update completes in seconds.

 

FWIW, Between 3 and 7 VSD updates are released per day:
http://virusradar.com/en/update/info

But when your PC receive them depends on how/when you use your PC of course, and if it is connected to the Internet at all times.

 

I think you have the wrong impression. There is nothing wrong with how the updates are delivered and it is solely dependent on whether the author of the scan engine decided to put all signatures into one database file or distribute it over many small files.

Malwarebytes or IKARUS for example are examples of products where the signatures are stored in a single file. Using a single large database file almost always required differential updates. Meaning updates are distributed as so called delta files that describe the differences from an older version of the file compared to the newest version. Applying the delta means replaying the changes recorded in the delta, essentially "updating" the file to the newer version. That approach has some problems though. First of all, you need to provide different delta files from different starting points to the new version. If your version of the file is not supported by the update server as a valid "source" version you will have to download the entire database file again, wasting tons of network traffic. But there are more subtle issues. For example, even differential updates can become quite large quite quickly. So while a delta file that updates the database from version 99 to 100 may only be a few kb, the update from version 90 to 100 may be several MBs big, depending on how complex the underlying file format is. Databases are also usually compressed and encrypted. Delta encoding doesn't work on encrypted or compressed data as the resulting differential files will be almost as big as the original due to the nature of these methods. That means to apply the delta on your system, the AV will have to decompress and decrypt the old file first, apply the delta and then compress and encrypt the database again. This process can be very CPU intensive, resulting in huge CPU spikes during updates.

Bitdefender, Kaspersky or our own engine for example split signatures into many small files. When we add signatures or change signatures, chances are the majority of the files won't have changed and to get the new version of the database, you would only have to download the files that have changed, which automatically gets you some benefits of the differential updates (reducing download traffic) but without the disadvantages of having to repack and reencrypt large amounts of data during every update. The disadvantage though is, that you will obviously have more files, meaning there will be more connections during an update.

Bottom line is though, neither of these systems is clearly superior compared to the other. If you have a slow CPU or disk, chances are differential updates will really screw you over because unpacking, decrypting, packing and encrypting a 100 - 400 MB file on every update can put a huge toll on your system. If you have a high latency connection to the update server, downloading many files will waste a ton of time (not system resources though, as the system is pretty much idle during the process) as a lot of time is spent just establishing and closing down connections. So depending on what the bottleneck in your setup is, one or the other system is preferable.

In our specific case people were very concerned about download volume. As a result we came up with our own update mechanism, that is based on differential updates as well as splitting databases into many files, essentially combining both techniques. These "hybrid" updates were introduced in 8.0 if I remember correctly and work pretty well for the majority of our users. Since we do still have many small files though, high latency will still negatively impact update speed in a much greater way than it would if we used a purely differential system. If your connection to the update servers is decent though, even getting almost 24 hours worth of updates is usually quite quick. On my workstation for example, using a database from yesterday 5 PM and updating to the current database (3:24 PM) which included more than 138 changes signature files, took less than 10 seconds and only transferred about 1.2 MB worth of data:

Code:

General Information:

Update started: 5/21/2015 3:24:38 PM
Update ended: 5/21/2015 3:24:46 PM
Time elapsed: 0:00:08

Update successful

Detailed Information:

138 modules, 1219718 bytes

So as in most cases, all approaches have advantages and disadvantages. If there was a system that would work for everyone without any disadvantages, most vendors would have migrated to it a long time ago. But there is none. So pick a product that uses a system that suits your circumstances, if you are concerned about update times.

 

I am using Emsisoft on a daily basis since version 6.5 and I have to say that hybrid updates was a amazing feature, it really made updating much more quick and consuming less bandwidth.

I dont understand the details like Fabian but I can clearly see the benefits of Emsisoft approach.

About the connections I dont see any problem because it doesnt affect system or browsing performance.

 

To add further to what Fabian said, I've just updated EAM 24 hours later since the last one. It took 1 minute 12 seconds to download 147 modules which transferred 1.6MB of data.

 

http://blog.emsisoft.com/2015/05/21...cker-panel-to-quickly-spot-potential-threats/

 

Emsisoft Anti-Malware & Emsisoft Internet Security 10.0.0.5409 released
May 25, 2015
http://changeblog.emsisoft.com/2015...isoft-internet-security-10-0-0-5409-released/

 

Didn't even notice the programme update, just shows how seamless it's become.
Thanks guys

 

It has been awhile since I tried any Emisoft product. Just installed EIS and truly pleased with it. The GUI is exactly what I want to see from a information need on opening it. Product is very light and honestly, this is not how I remember their products. In the last 2 years they have done a remarkable job at refining and creating. This one is a keeper, as many are not for me. Thumbs up Emisoft.

 

Likewise i haven't tried an Emsisoft makings aside from EEK. Being always and forever that everyday proverbial information junkie per experience with so many Classical HIPS over the span of Windows O/S's (particulary where concerns XP), and on the suggestion of a close member here in the forums, i'm not beyond taking a new try with Emsisoft Anti-Malware release. I still recall first using A2Squared back in the days of 98.

 

+1. Hadn't tried Emsisoft (other than EEK) since a2squared and Online Armor way back, very pleased with EIS and their support.

 

I don't know about anyone else, but I am not happy with the changes made to the behavior blocker in this release. This is a big deal for me since it is the primary reason I use EAM.

Gone in ver. 10 release are:

- file change alert option. I assume we no longer get alerted when a .exe changes?

- option to opt in/out of clould rep scanning. Appears now that is done automatically with the following results. Either the app is classified as "known" and fully trusted or "bad" and quarantined. If is "unknown" as far as the cloud goes, BB appears to do nothing with the app including monitoring of it.

- no granularity in BB configuration options. Threshold % parameter is gone as is "paranoid" mode.

Bottom line - appears the BB is 100% clould driven in this release.

If I want automatic control, I could just install Norton.

 

I am talking about the options shown in the below screenshot.

I couldn't find a screen shot of the old ver. 9 global file change alert settings; I am not referring to the opt out notification that exists at the app rule level:

 

I still get alerts. For example, when I update Filezilla to a newer version, EAM alerts me because it is in my list of application rules. If I edit the rule I see the list of monitored behaviour options that is in the screenshot above. There is even an option to select if you don't want to be alerted when the file being monitored changes. Obviously, I've not selected that.

 

Still getting this...

 

There have been no changes to the behavior blocker whatsoever.

Such an option never existed. That is also the reason why you can't find it on screenshots. You must have mixed up products here. Both EAM as well as EIS will ask you what to do with your existing rule if the application the rule refers to changes.

Those options haven't been removed. They have merely been moved into the new Privacy settings tab. Previously privacy related settings were scattered all over the user interface, which was kind of ugly when people wanted to know how to turn off anything cloud related and you gave them instructions that involved half the GUI dialogs available. That is why we decided to consolidate these settings into a single dialog.

I already told you that the decision of what to monitor and what not is not based on cloud information or reputation but solely based on the circumstances of how the application was started. This has been the case since version 1.7 when the behavior blocker was first introduced. The reputation only matters when a potentially malicious behavior was detected. If the application has a good reputation and you enabled the "Automatically allow programs with good reputation" setting, the behavior is allowed. If the application has a bad reputation and you enabled the "Automatically quarantine programs with bad reputation" the application is quarantined. If the program is unknown, EAM will simply ask you what to do.

The threshold parameters were useless. Of the 170 million files or so the cloud recognizes, only a couple of hundred will potentially return these percentage values. In all other cases the verdict is absolute (either good, unknown, or bad), no percentages involved.

We did remove paranoid mode, yes. Paranoid mode used to disable a lot of the internal whitelisting logic that is going on. As a result it produced a lot of useless alerts. Is it really useful to get an alert that your browser changed the browser settings after you changed the homepage or the proxy settings in your browser for example? Or is it useful to get an alert about Notepad changing your HOSTS file, because you just opened it using Notepad and made a few changes to it? These are examples of the type of alerts you used to get with Paranoid Mode enabled. Things get even more absurd when you enabled Paranoid Mode and enabled Cloud Lookups. In those cases all Paranoid Mode would get you is a few second delay while you used your system because EAM was querying the cloud and the cloud uses the same method to automatically allow certain actions that you just disabled locally by enabling Paranoid Mode. It's a legacy option that nobody should have used in the first place.

Not more or less than in previous versions, as again the behavior blocker didn't change at all in version 10.