Avast WEBforum

Consumer Products => Avast Free Antivirus / Premium Security (legacy Pro Antivirus, Internet Security, Premier) => Topic started by: MotherDawg on February 26, 2018, 10:59:22 AM

Title: Why does AVAST keep using new process for updates?
Post by: MotherDawg on February 26, 2018, 10:59:22 AM
To update to the 18.1.2326 version, Avast created a new folder and started a new executable to do the update.

Do Avast Software s.r.o. programmers have any clue how computer works?

Most people run firewalls. Hardware or software, these firewalls don't just block unknown incomings, they also block all unauthorized outgoings.

So when Avast creates new folders with new executables in them, do you think the firewalls are going to let it go through like there was nothing?

NO!

So what is the result? Avast does not get updated. Avast users are not well protected.

Avast is coded like its employees do not care if its users are updated or not. The method used for updates is bound to get blocked.

So users, when they figure that an update is available but it's just stays available, never gets installed, users must go out of their way to look at the file structure to inspect for new executables, go through their event viewers and figure that there's some new process wants internet access. That process is a one off. The firewall rule that was just added is instantly obsolete and should be remove as the next update will use a different executable in a different location.

You guys need to fix that. Continuing to use a method that is will always be blocked is not good practice... any which way you want to look at it, it's flawed.

A connection was blocked by the outbound rule:
   PID:      4856   \device\harddiskvolume2\XYZ\avast\setup\new_12010916\instup.exe
   Direction:      Outbound
   Source Address:      10....
   Source Port:      57408
   Destination Address:   10....
   Destination Port:      53
   Protocol:      UDP

A connection was blocked by the outbound rule:
   PID:      3848   \device\harddiskvolume2\program files\common files\avast software\overseer\overseer.exe
   Direction:      Outbound
   Source Address:      10....
   Source Port:      58081
   Destination Address:   192....
   Destination Port:      53
   Protocol:      UDP


Do you guys think that instup.exe or overseer.exe got their return?
Title: Re: Why does AVAST keep using new process for updates?
Post by: ds47uk on February 26, 2018, 11:27:15 AM
Glad I found this message. I use "Windows Firewall Control" and when Avast refused to update I checked and it was being blocked by WFC! Allowing the updater through and ... off it went as usual. Incidentally if you haven't heard of WFC it's worth a look.
Title: Re: Why does AVAST keep using new process for updates?
Post by: MotherDawg on February 26, 2018, 11:56:07 AM
I just edited my original post, ds47uk, understand:
The firewall rule you just added, "Allowing the updater through", is instantly obsolete and you should remove it as the next update will use a different executable in a different location.
Title: Re: Why does AVAST keep using new process for updates?
Post by: igor on February 26, 2018, 06:17:28 PM
I'm afraid the answer to "why" is "because overall it would be worse the other way".

I do understand that it doesn't work well in your situation, but that case (blocking outgoing connections) is very rare. Over the years, using the new setup to do the update has helped us many times overcome various problems (a bug was found in the existing/old setup that would prevent the update to be performed correctly, or the update required functionality that the old setup simply didn't have).
Also, if a personal firewall blocks outgoing connections, the firewall rules may as well be based on file content (i.e. allow only a specific executable with a given hash to access the network). In that case, not getting the program update can actually be a better outcome - if the program was updated and a new version installed, the executables could be blocked, not getting even the virus definition updates...

I don't work on the setup part, but if I should guess, I'd say this will not change, sorry.