Bug report: Application modification detection - Exclusions change after reboot

[Utini 1]

Hey there, I have disabled the "exclude trusted apps from modification detection" and added two exclusions myself. When I reboot the exclusions change to completely other files. 

 

E.g. instead of HitmanProAler.exe I had skype.exe

instead of mbam.exe I had dnscrypt.exe

 

Please fix that

 

If you need a video / screenshots: let me know

[Utini 1]

This this bug get accepted by ESET or is this the wrong place to repot a bug ?

 

Thanks

[TomasP 317]

Hello Utini,

For starters, we would need to know what version of our product you are using and on which operating system. Then we can have a look at the issue and tell whether it is a regular bug, or just some incorrect behaviour in your case.

[Utini 1]

Hello Utini,

For starters, we would need to know what version of our product you are using and on which operating system. Then we can have a look at the issue and tell whether it is a regular bug, or just some incorrect behaviour in your case.

 

ESS v8 (latest)

Windows 8.1 x64

[rugk 397]

So the "latest" is 8.0.304.x I think.

[TomasP 317]

Hi Utini,

So I tested the situation in the same environment (ESS 8.0.304 on Win 8.1 x64, disabled checkbox "Allow modification of signed /trusted/ applications") and the selection of apps excluded from checking (which I added manually) stayed the same even after a reboot of the system.

Therefore, this might be a specific issue on your PC, so I recommend to submit this as a support ticket to your local ESET office.

[rugk 397]

...and if you do so, I think it would be helpful to create a full SysInspector log and include it in the support case too.

[Utini 1]

Hi Utini,

So I tested the situation in the same environment (ESS 8.0.304 on Win 8.1 x64, disabled checkbox "Allow modification of signed /trusted/ applications") and the selection of apps excluded from checking (which I added manually) stayed the same even after a reboot of the system.

Therefore, this might be a specific issue on your PC, so I recommend to submit this as a support ticket to your local ESET office.

 

Where can I reach the local ESET office ? Btw I tried the same on my HTPC and the same problem occured. Will the SysInspector log help if I post it here in the forum? I am from Austria (Europe)

Edited December 22, 2014 by Utini

[TomasP 317]

The most efficient way would be to contact our Austrian partner by means of email, you can find all their contact data at https://www.sicontact.at/hilfe/kontakt

You can attach the ESET SysInspector output to the email.

[rugk 397]

https://www.sicontact.at/hilfe/kontakt

 

Mhh...

Could you tell your partner that they still have the icon of the old ESET versions as their favicon?

Generally their site seems to be a bit outdated. (e.g. they talk about ThreadSense.NET which is today named ESET LiveGrid and they have still images of ESS v6 on their website)

 

BTW This is the "official" Austrian ESET site: hxxp://www.eset.com/at/

(but the support link there redirects to the site @TomasP has pointed to)

Edited December 22, 2014 by rugk

[Utini 1]

Hmm okay I can't reproduce the bug anymore. How ever, I noticed that the *.exe files (when you want to add a file to the list) are all written in capital letters while on my other systems it is written in the original way (e.g. mbam.exe instead of MBAM.exe).

[rugk 397]

Okay and what are the differences of the "buggy system" compared to the other systems?

[Utini 1]

The "buggy system" shows the filenames with CAPITAL letters while the "virtualbox system" (Which works correctly) shows the filenames as they are origrinally.

 

On the buggy system the whitelisted apps will change after a reboot. E.g. I add "mbam.exe" to the whitelist but after a reboot it will be "skype.exe".

[rugk 397]

Hmm...
Do you have the same firewall mode in both systems and do you had installed a few applications in the VM?
Are really every characters of all application paths in capital letters? Or only the filenames?
 
If I look on my installation I have very different file paths:

• there are the correct paths lowercase, e.g.: C:\example\filename.exe
• there are paths which are completely in capital letters, e.g.: C:\EXAMPLE\FILENAME.EXE
  I saw that this were in my case only files which doesn't exists anymore.
• and one time there is even this path:
  

 

On the buggy system the whitelisted apps will change after a reboot. E.g. I add "mbam.exe" to the whitelist but after a reboot it will be "skype.exe".

At first there will be shown the full path to the file, so the whole path "switches"? And the path is a valid one (so the file exists)?

And in your example: What about the capital letters? So am I right with this assumption?

You add [...]\mbam.exe → it will be converted into [...]\MBAM.EXE → at the next reboot it will be [...]\skype.exe? Or is it [...]\SKYPE.EXE?

 

[Utini 1]

The paths are: C:\example\FILENAME.EXE

 

After the reboot it changes to a valid application (and it seems like it is always the same application). I have to check if it is capitalized after the reboot or not (will do when I get home from work).

 

Firewall mode is "learning" in virtualbox and "interactive" on my main machine (this is where the bug happens).

[Utini 1]

I tried to solve it together with the support team via remote (teamviewer). At first it looked like it was a problem with UAC and ESET:

 

Altough ESET prompts with an UAC request when ever you change settings and try to save them, UAC and ESET don't work along well. I would need to run ESET as admin from the start menu in order to make some setting work. And at the beginning it looked like this would solve the bug but it didn't. As it was hard to re-produce the bug there wasn't any real solution to this.

 

How ever, the support team told me that this feature is only network related and no other app (or anti virus) would need to be excluded in order to make it more compatible with ESET. So it sounds like I don't need the feature but it is still buggy anyway.