I am a technical consultant and I develop a LOT of prototypes and every time I compile a program and run it, it gets auto-sandboxed by Comodo CIS. I have my own internal certificate authority, so I used it to generate a code signing certificate, and then added a digital signature to my program (I verified the signature’s validity with some other 3rd party tools, as well). I then went into the Trusted Vendors configuration section and tried to add the digitally-signed executable and it keeps coming back and saying:
“The file does not seem to be a valid signed executable.”
So I finally went to GeekBuddy to try and see if they could help me, but all I got was pretty much just the canned responses and then the first guy didn’t seem to understand what a digital signature was. I had the information on my screen and via remote control, he just sort of bumbled around in the file property / digital signature dialog boxes for about 3 minutes and then abruptly stopped and said his “shift had ended” (strangely, his shift “ends” at 1:40 AM - sort of an arbitrary time that coincides with him not seeming to know the answer).
Both reps tried to get me to send the file to an email address at Comodo, but both of them didn’t seem to understand the concept of an “internal” self-signed CA (as in, I don’t want my own internal CA being published anywhere - it’s only for my own purposes), and both seemed to think Comodo was just going to add me to the “Trusted Vendors” list and that THAT was the only way to do this.
So I asked if that was the only way to do it, why do they even have a feature in the product to add a signed executable / running process??? No answers there, so GeekBuddy has utterly failed to understand their own product, in my eyes (not to mention the quality of customer service). If anyone at COMODO wants the chat transcripts, I can provide them. It was pretty ridiculous. It’s definitely enough to never recommend GeekBuddy to anyone else.
However, I don’t really care about GeekBuddy (I’m just venting a little because it was such an irritating experience).
All I want to do is add my own CA to the Trusted Vendors list on my own machine.
Can anyone help here?
When you go to select read from a signed executable, do you leave the file type as executable or do you change to all files from the drop down list. What is the file extension you are trying to add the signature from?
It’s an executable (.exe) written in C# and signed with the signtool (timestamp included). Here’s the output of the signtool verification on a simple tool application.
D:.…\bin\Debug>signtool verify /pa SaveLoadClipboard.exe
File: SaveLoadClipboard.exe
Index Algorithm Timestamp
0 sha1 Authenticode
Successfully verified: SaveLoadClipboard.exe
Interesting, and you did try using the option to read from a running process while your application was running and it still gave you that error? You should be able to add a digital signature from any .exe, .dll, and .ocx file so I don’t know why it is not working.
Yep, tried it as a running process and got the same result.
Anyone else? Comodo support?
Please provide more details. I’m guessing that you used Sigcheck ?
Also, did you make any changes to default configuration?
I used both signtool and sigcheck to verify:
D:\...\bin\Debug>sigcheck.exe -a SaveLoadClipboard.exe
Sigcheck v2.51 - File version and signature viewer
Copyright (C) 2004-2016 Mark Russinovich
Sysinternals - www.sysinternals.com
D:\...\bin\Debug\SaveLoadClipboard.exe:
Verified: Signed
Signing date: 10:36 AM 6/2/2016
Publisher: <my domain>.com Code Signer
Company: n/a
Description: SaveLoadClipboard
Product: SaveLoadClipboard
Prod version: 1.0.0.0
File version: 1.0.0.0
MachineType: 32-bit
Binary Version: 1.0.0.0
Original Name: SaveLoadClipboard.exe
Internal Name: SaveLoadClipboard.exe
Copyright: Copyright ⌐ 2016
Comments: n/a
Entropy: 5.806
D:\...\bin\Debug>signtool verify /pa SaveLoadClipboard.exe
File: SaveLoadClipboard.exe
Index Algorithm Timestamp
========================================
0 sha1 Authenticode
Successfully verified: SaveLoadClipboard.exe
When you say, “changes to default configuration” - what configuration are you specifically talking about? COMODO’s configuration? Configuration related to signtool or sigcheck? Something else?
In most cases, the answer is going to be no. For COMODO, I ran things on their default settings, although over time I have added various files as “Trusted” files in the file ratings area so they don’t get sandboxed. The file being added was not one of those files that was manually trusted at the time that I tried to do the signing. (Previous compiled versions probably got trusted, but every time I recompile, it’s technically a different program).
I think the only real impacting change here is simply that I added my own internal CA to the trusted root CAs store, specifically so that my local machine could use a valid code-signing certificate. But that’s sort of the whole point here - to establish a local, trusted certificate for signing, and then tell Comodo to trust it.
So the trust chain looks like:
ca..com ← Internal CA, which is in my trusted root CAs store
__ .com Code Signer ← Code-signing certificate, used for signing the executable.
NOTE: I’m intentionally scrubbing out my real domain name and changing those references to . So just to be clear, it’s not literally “” in the certificate details.
I’m happy to provide just about any amount of details you ask for.
Consider one application that it is being virtualized and check if there’s any streams info.
Could you kindly provide the output?
My application here doesn’t use alternate NTFS streams - it’s an extremely simply application (just a hair above “Hello World”), but just to honor your request, I downloaded and ran streams against it, and it came up empty:
D:\...\bin\Debug>streams.exe SaveLoadClipboard.exe
Streams v1.56 - Enumerate alternate NTFS data streams
Copyright (C) 1999-2007 Mark Russinovich
Sysinternals - www.sysinternals.com
D:\...\bin\Debug>
That means streams are stripped in the process-- application is virtualized due to nonexistent data like file zone and process that created the file. This is fixed with next major version since a database is utilized to keep track of things.
I’m not sure I understand what you’re saying. Again, my application does not use alternate streams. That output from streams.exe remains the same when executed against a computer that does not have Comodo, as well.
Can you try to explain what you’re saying?
Auto-Sandbox makes use of “file source tracking” feature. On each file it stores info like which process generated it and where it comes from by utilizing alternate data streams (not a centralized database). In a certain phase you are actually stripping such info from file(s). The result is that application is virtualized being unknown file with unknown origin. This is a known issue which is fixed in version 10.
How does this relate to not being able to add an entry to the Trusted Vendor list? That’s the main question here…
It sounds like you’re talking about Comodo using an alternate stream to track this particular file. I’m assuming that recompiling the application is probably what is stripping away that stream, since a rebuild is going to delete the existing file and place a new one in its place…
ANother way of solving your problem is involves using HIPS rules.
Give your compiler the Installer/Update policy and start your executables from there. In this scenario you can leave the sandbox enabled.
When you want to start the applications you’re working on from Explorer and the name of the file stays the same you can give make a HIPS rule for the application (typically Trusted Application) and disable the sandbox. The sandbox needs to be disabled because the sandbox takes precedence over the HIPS in CIS’s current guise.
I definitely don’t want to disable the auto-sandbox - that saved my bacon just last week when a small hand tremor (probably too much coffee) made me double-click something that I was trying to single-click to select and delete.
I may do that extra step of giving the compiler the installer/update policy, but I really do want to figure out this CA thing. I’m about to roll the dice and upgrade to Windows 10 this weekend, so I don’t have Comodo installed at the moment. After I re-install everything, I’ll give it another shot. One thing I didn’t try was adding my code signing certificate to the Trusted Publishers store. That really shouldn’t be necessary, since the code-signing certificate is issued by a trusted CA, which should delegate trust to the code-signing certificate automatically, but maybe Comodo isn’t following those rules.