How to avoid DeepScreen as developer?

[REDACTED]

Hello,

we are developing a software which we sell (or rather rent) to our customers. We regularly create new setup files with updated versions. We use InnoSetup to create the setup. Since we did not use code signing we kind of understood Avast could not determine "I have already verified that file" since there was no way to relate from version A to version B. But now we have even enabled code signing (even if the certificate used is selfsigned, the used private key behind the signing is still "save"). Then I started wondering: Why would Avast scan repeatly on the same machine a signed setup from us, but will ignore an unsigned open source setup like miranda-im-v0.10.37-unicode.exe (just the first example I found avoiding strong name signed files like from Microsoft itself). So there must be a trick for Avast to recognize "this file is fine, no need to deepscreen it". I tried to search the FAQ and forums, but to no avail.

So what can we as a developer do to make/appear our setup more trustworthy?

[Be Secure]

How to avoid DeepScreen as developer?

Just untick the Deepscreen.

[REDACTED]

So we should tell our customers using Avast to disable DeepScreen at all on their PCs? I don't care what happens on my PC or from my co-workers, I wanted a solution to avoid inconveniencing our customers (especially since DeepScreen seems to tend to Access Violate InnoSetups and does a double DeepScreen of seemingly the same file). And telling a customer to disable a feature that's intended to enhance security is definitely inconveniencing them.

[DavidR]

@ Be Secure
This will do nothing to resolve the problem and would leave the end user less well protected.

This is about a software developer trying to get past the end users being alerted by the DeepScreen notification.

@ Markus Strunz
First I'm avast user not an avast employee, so I'm not privy to the process.

I don't know if your executables, etc. are signed as this can help - though I'm not sure about the signing process - but I wonder is self signing would hold the same weight.

I would suggest contacting avast using the support ticket system and see advise on your software (perhaps submitting samples, etc.
Try the following: https://support.avast.com/support/tickets/new.

[REDACTED]

Thanks, I'll do that. I thought that idea could not have been so rare to be unknown to the user base here.

[DavidR]

You're welcome.

[REDACTED]

Just to leave an update... normal support referred me to business support and after some ping pong of misunderstandings I am now referred back to normal support. It seems no-one has an answer for this.

[DavidR]

I have reported this in the hope of drawing some attention to it.

[igor]

I'm afraid a self-signed executable is currently considered exactly the same as an unsigned - the self-signed signature simply doesn't validate.

[REDACTED]

We kind of noticed that by comparing the behaviour of our (locally) fully trusted setup compared to unsigned setups from other sources (like the mentioned setup from Miranda IM). The question is less aimed at the signing itself, but rather at the: What would we have to change for Avast to recognize our setup not as suspicious enough to trigger a double deepscreen (and potentially Access Violate the InnoSetup). The last copy&paste answer I got refered me to report a false positive... but is that even correct? I never mentioned it actually reporting it any error, it just uses deepscreening on our setup in a really annoying and error prone way which obviously would not strengthen the trust of our potential customers in our software.

PS: For Avast support members interested into looking into more private informations about the setup or want to answer in a more private manner can lookup either the ticket:
https://support.avast.com/support/tickets/10882
https://support.business.avast.com/hc/en-us/requests/49359 (seems the ticket has been marked deleted for me now?!)

[igor]

The answer is signing all the program executables with a regular certificate (so that when I rightclick the executable and select Properties, the Digital Signature tab will verify the signature as OK - even on a machine where the program isn't installed).

[REDACTED]

Does Avast actually provide it's own trusted certificate chain? I have added our own certificate in my Windows certificate trust store and it's locally fully trusted as if it had a level 2 code signing certificate. Please refer the screenshot (it's actually cut together from 3 screenshots) showing the certificate trusting at 2 positions and the deepscreening window with an example of the error popping up (today not an Access Violation, but time "only" a failed ShellExecuteEx() call which is only for knowledgeable people a non-critical message).

Do you still affirm that a proper signed setup file would be excepted from deepscreening behaviour? Because if a proper certificate would solve the issue the ~120 $ per 2 years would be totally worth (providing your are maintaining your own certificate store and StartSSL is part of it), but seeing it already fails the local test, I am not sure it would change anything. Setup is created using current version of InnoSetup which is 5.5.6.

[igor]

Yes, Avast uses its own set of trusted root certificates and doesn't use the Windows store (that's why I wrote "even on a machine where the program isn't installed"). The Avast trusted roots are a subset of common Windows trusted roots (and if any significant is missing, we can add it), but we don't want to use the Windows store directly because if a malware is already running there, it could have added its own root and then e.g. verify all its executables as being signed by Microsoft.

[igor]

As for the nature of the errors though... are you doing any special multithreaded processing, for instance? The thing is that the API call that started the program (being DeepScreened) should be properly blocked until the DeepScreen is done... so unless there's some other thread trying to access something from that process (and assuming it must be already running by then), everything should be working correctly - just the CreateProcess() call takes more time than usual.

Is the problem reliably reproducible with your program? Would you maybe have a simple proof-of-concept that the DeepScreen developers could test and check what's going wrong?
Thanks.

[Eddy]

The software can be found here : http://www.systemarena.de/