How to avoid DeepScreen as developer?

system · 2015-10-26T12:29:24.000Z

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?

BeSecure · 2015-10-26T14:07:11.000Z

How to avoid DeepScreen as developer?

Just untick the Deepscreen.

system · 2015-10-26T15:55:37.000Z

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 · 2015-10-26T15:58:11.000Z

@ 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.

system · 2015-10-26T16:01:09.000Z

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

DavidR · 2015-10-26T16:12:54.000Z

You’re welcome.

system · 2015-10-30T13:46:20.000Z

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 · 2015-10-30T14:29:31.000Z

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

igor0 · 2015-11-03T08:14:16.000Z

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

system · 2015-11-03T08:22:41.000Z

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?!)

igor0 · 2015-11-03T17:38:25.000Z

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).

system · 2015-11-04T09:08:14.000Z

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.

igor0 · 2015-11-04T10:38:08.000Z

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.

igor0 · 2015-11-04T10:47:44.000Z

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 · 2015-11-04T11:03:36.000Z

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

system · 2015-11-04T11:44:39.000Z

I have a attached a sample innosetup script (with private portions being censored by ***) and compiled it using InnoSetup 5.5.6 in InnoIDE 1.0.0.0078.
Downloadsource: http://www.baeckerprogramm.de/downloads/setup.exe
It “features” the same errors as in my screenshot from earlier.

Thanks for clarifying the certificate root issue and reassuring a trusted installer would be excepted. I will forward this information, so we will decide when to apply for a trusted code signing certificate.

PS: Extention limitation fail… due to .iss being blocked my whole text is lost now. So this is just a summary.
PS2: “winsdk” obviously refers to signtool.exe from the Microsoft Windows SDK (7.1A in my case).

igor0 · 2015-11-04T16:18:40.000Z

Just a note: I can see you signed even the inner setup (Setup.e32 from Inno installation) with the self-signed certificate. In this case, it actually causes a second DeepScreen to be performed.
The original (untouched) Setup.e32 wouldn’t be DeepScreen even when unsigned because its prevalence is very high (it’s been run on millions of machines already).

system · 2015-11-05T11:16:00.000Z

Just as a note:
I never configured anything like creating an installer in an self-extraction binary or which files to sign. All I did using InnoSetup was creating a most basic setup and telling him “this is how to use the signtool”. Anything else is “how innosetup works”. All setups used with that great tool work like that.

That simple setup does not contain anything complex like our real setup does like component downloading, running lot of pascal scripting (checking for need of optional components), fiddling with registry (like adding a trusted location for Access) and potential system files (like C:\Program Files (x86)\Common Files\System\ado\msado60.tlb which is provided by Win7 SP1, but missing in anything earlier - but with the version check it should never try to overwrite them). But isn’t it interesting that all you need to do is hit the wizzard button, click together your “setup example” and you can create a setup files that Avast considers suspicious? To be honest, I’d totally understand that Avast signature heuristic would consider our internal setup as suspicious, because we are doing really a lot of stuff that could have dramatic impact on system security, if it was with malice intend. So I’d actually except Avast to deep screen the inner setup, it really has enough suspicuous content. But what really bugs it is the fact it deep screens the same setup twice. Maybe the 2nd deep screening is caused because the first deep screening is interrupted at the error? I have not enough insight into the interna of how far it can execute before deep screeing interrupts it. The fact that I don’t even get asked for “do you want to run this file as administrator” by Windows I am tempted to assume the execution is interrupted, before the process attempts to invoke admin privileges.

igor0 · 2015-11-05T11:26:33.000Z

When you run an Inno-based installer, it extracts its own executable into the TEMP folder and launches another process - and that’s where those two scans come from. One is performed on the outer executable, the second one (potentially) on the executable launched from the TEMP folder.

system · 2015-11-05T11:32:15.000Z

I am aware of that… in theory. But doesn’t the deep screen sandbox go so far to track child process spawns as well? In that understanding I’d expect the deep screen to follow both processes at least to moment the process is actually showing the first dialogue which is to ask for admin privileges. That’s why my theory would be that the sandbox of the deep screen crashes the self extractor before it can fully spawn the child process (the error message would even suggest that it exactly fails at the moment to try to spawn it). Because the previous deep screening was not able to scan that child process it obviously recognizes it as “unscanned” and does what it was programmed to.

Announcements