I looked recently into signing my application. The price is AT LEAST one hundred euros/dollars per year for EV (anything less than EV seems pointless anyway).
My application uses a basic installer (self-extracting WinRar) that requires no admin password. But the drawback of this is that I cannot install the app in Program Files.
The actual problem here is that you will find lots of resources that tell you how to sign your app but not so many (at all) that tell you if there is any real advantage. For example: do the regular PC users care when they install and app and Windows shows "Publisher: unknown" or they just quickly hit the OK button to have the installation process done as soon as possible?
Honestly, I don't think that the user reads and cares about "unknown". That might stop him is actually the yellow color (instead of blue).
So, my question for those that already did code signing for their apps is: have you seen an improvement (downloads, installations, sales) after signing your app?
Should I invest any time/money/energy in this?
Update: It seems that having the app signed is not enough. After that, you have to keep fighting to improve your reputation factor, otherwise, Microsoft SmartScreen might pop-up: https://mkaz.blog/code/code-signing-a-windows-application/
For those interested in prices, here a few random offers sorted by price. I will also post the documents required:
Signing a Windows EXE file
For those interested in prices (and few extra tips), here a few random offers sorted by price.
The documents required (by Sectigo, in my case) for obtaining an OVL are:
company's registration certificate
a photo of you holding your ID close to your face
a phone landline so they can call you for verification (it as actually a robot calling you to give you a number, that you have to enter then into the browser).
The whole verification process (especially phone) took like 2 months because they involved some kind of automatic calling that did not work on my line/phone?.
I will post soon the number of downloads necessary to get reputation for your newly signed exe file. At this point, I can tell you that 1000 downloads are not enough.
I noticed that my fan goes up a lot on occasion for no apparent reason. Investigation shows that it's the process Antimalware Service Executable, the service Windows Defender Antivirus Service and the file executed is MsMpEng.exe.
I want it to be able to run still but not go bananas, so I tried to set its priority to low. However, Windows barked at me that the operation could not be completed and that access was denied.
How can I force the service to run at a limited performance?
You can't, by design. That "by design" means that if you find a hack, a future security update of Windows will likely render your hack inoperable.
The key word here is "security". The whole point of anti-malware is that detects malware even when the malware tries to avoid detection. To make that work, Windows treats anti-malware software as a special case, and offers it additional protection. If there was an answer to your question, it would be treated by Microsoft as a bug.
Let me describe my situation, I develop some accounting software of VB winform to use, normaly my software will modify registry to set offcie trusted location and whether the user who reads in registry has admin authority. However, I found here that it is no problem for VirusTotal to scan my exe on the first day after I developed the software. But after a few days, VirusTotal will appear and say that my exe is a virus,this makes my exe in the another computer antivirus detect as a virus, even if I run scaning on VirusTotal on the first day.
Why is it not a virus on the first day, but later diagnosed as a virus?
Is reading registry or modifying registry the cause of the diagnosed virus?
Any documentation or any behavior that is not allowed?
What can be done to avoid this problem other than to file a false positives list after it is detected as a virus
Antivirus software works based on heuristics and signatures. In your case an actual virus may have similar behavior, e.g. because it modifies the same registry entries, which leads to the false positive. The is no "documentation on what is allowed" otherwise somebody writing an actual virus would use that as a rule book to evade detection. The delay in detection is likely caused because the antivirus software performs a periodic scan, which only then checks your executable.
Most antivirus software allows to mark files or directories as trusted and exclude them from scanning. This may be a suitable solution for you.
Norton Antivrus is marking an installer of mine, foobar_revision_1922.exe improperly as a threat because it has Very Few Users ( less than 5 in the Norton Community, WS.Reputation.1 ) and places the file in quarantine. Has anyone encountered this situation?
What is the best way to prevent Norton from flipping out?
This seems tedious and a Catch-22.
For future releases, such as foobar_revision_2116.exe, I would need to have five trusted users of the new version to pass quarantine.
If I rename all releases to a common filename foobar_installer.exe than this removes the useful version information and I imagine that the filesize is stored by Norton and this would fail anyway.
Suggestions?
Thanks.
Edit:
I have found the answer after a little more searching - https://submit.symantec.com/whitelist/. Symantec has a whitelist program
Edit 2
Norton offers Apple-like response times:
We have received your recent request
to Symantec's Software White-list
Request program. Complete requests
with all necessary information will be
processed immediately. Once a
determination has been made regarding
your request you will be notified via
e-mail as to the decision made and the
next steps, if any. For a Software
White-list request, Symantec will
target a response of advising you of
our final determination within 3
weeks. This timeframe is subject to
Symantec being supplied with all the
necessary information to allow for a
proper determination. Requests of
incomplete information may result in a
delay of the final determination. Any
request for additional information
regarding your submission will be sent
to the contact email address you
provided at the time of submission.
I had a similar problem: Norton File Insight flagging my posted MSI as a possible threat. I did the white-list application and it was approved fairly quickly (I believe within a day or two). It was probably approved quickly because it was digitally signed allowing the Norton team to confirm the file quickly.
But Norton File Insight, like IE9's new SmartScreen Filter, is not very friendly to small software developers. Norton File Insight just does not recognize that my MSI is digitally signed with a certificate from a trusted certificate authority. AND, I lost my white-listed status as soon as I posted an update to the MSI. I post updates probably 20 times a week so I think Norton File Insight will keep giving my customers grief.
And of course it is perpetually stuck on Very Few Users have downloaded this.
So the solution is to keep petitioning Symantec to get its act together and to keep filing White-List requests. Hardly ideal.
I have developed a software piece (with C and Python) which I want to protect with dongle so that copying and reverse engineering becomes hard enough. My dongle device comes with an api which provides these:
Check dongle existence
Check proper dongle
Write into a memory location in dongle
Read from a memory location in dongle etc. (I think the rests aren't that good..)
What I can do in the source code so that it becomes harder to crack. Dongle provider suggested that, I should check proper dongle existence in a loop or after an event, or I should use the dongle memory in an efficient way. But how? I have no idea how crackers crack. Please shed some light. Thanks in advance.
P.S: Please don't suggest obfuscating. I have already done that.
First of all, realize that the dongle will only provide a little bit of an obstacle. Someone who knows what they're doing will just remove the call to the dongle and put in a 'true' for whatever result that was called. Everyone will tell you this. But there are roadblocks you can add!
I would find a key portion of your code, something that's difficult or hard to know, something that requires domain knowledge. Then put that knowledge onto the key. One example of this would be shader routines. Shader routines are text files that are sent to a graphics card to achieve particular effects; a very simple brightness/contrast filter would take less than 500 characters to implement, and you can store that in the user space on most dongles. Then you put that information on the key, and only use information from the key in order to show images. That way, if someone tries to just simply remove your dongle, all the images in your program will be blacked out. It would take someone either having a copy of your program, grabbing the text file from the key, and then modifying your program to include that text file, and then knowing that that particular file will be the 'right' way to display images. Particulars of implementation depend on your deployment platform. If you're running a program in WPF, for instance, you might be able to store a directx routine onto your key, and then load that routine from the key and apply the effect to all the images in your app. The cracker then has to be able to intercept that directx routine and apply it properly.
Another possibility is to use the key's random number generation routines to develop UIDs. As soon as someone removes the dongle functionality, all generated UIDs will be zeroed.
The best thing to do, though, is to put a domain specific function onto the dongle (such as the entire UID generation routine). Different manufacturers will have different capabilities in this regard.
How much of a roadblock will these clevernesses get you? Realistically, it depends on the popularity of your program. The more popular your program, the more likely someone will want to crack it, and will devote their time to doing so. In that scenario, you might have a few days if you're particularly good at dongle coding. If your program is not that popular (only a few hundred customers, say), then just the presence of a dongle could be deterrent enough without having to do anything clever.
Crackers will crack by sniffing the traffic between your app and the dongle and either disabling any code that tests for dongle presence or writing code to emulate the dongle (e.g. by replaying recorded traffic), whichever looks easier.
Obfuscation of the testing code, and many scattered pieces of code that perform tests in different ways, as well as separating spatially and temporally the effect of the test (disabling/degrading functionality, displaying a warning etc.) from the test itself make the former method harder.
Mutating the content of the dongle with each test based on some random nonce created each run or possibly even preserved between runs, so that naively recording and replaying the traffic does not work, will make the latter method harder.
However, with the system as described, it is still straightforward to emulate the dongle, so sooner or later someone will do it.
If you have the ability to execute code inside the dongle, you could move code that performs functions critical to your application there, which would mean that the crackers must either rederive the code or break the dongle's physical security - a much more expensive proposal (though still feasible; realise that there is no such thing as perfect security).
How to maximize protection with a simple dongle?
Use API together with Enveloper if an enveloper exists for your resulting file format. This is a very basic rule. Because our enveloper is already equipped with some anti-debugging and obfuscating methods to prevent common newbie hackers to give up hacking the program. Only using enveloper is also not recommended, because once a hacker can break the enveloper protection in other program, they can also break yours.
Call dongle APIs in a LOT of places in your application. For example when first start up, when opening a file, when a dialog box opens, and before processing any information. Also maybe do some random checking even when there's nothing done at all.
Use more than one function to protect a program. Do not just only use find function to look for a plugged dongle.
Use multiple dlls/libraries (if applicable) to call dongle functions. In case one dll is hacked, then there are still other parts of the software that uses the functions from another dll. For example, copying sdx.dll to print.dll, open.dll, and other names, then define the function calls from each dll with different names.
If you use a dll file to call dongle functions, bind it together with the executable. There are quite some programs capable of doing this; for example PEBundle. 3
I have got this article on PRLOG and found it quite useful on maximizing protection with a simple dongle. Maybe this link may help you
Maximizing Protection with a Simple Dongle for your Software
You can implement many check points in your application.
I don't know if you use HASP, but unfortunatelly, dongles can be emulated.
You may want to look into using Dinkey Dongles for your copy protection.
It seems a very secure system and the documentation gives you tips for improving your overall security using the system.
http://www.microcosm.co.uk/dongles.php
Ironically, the thing you want to discourage is not piracy by users, but theft by vendors. The internet has become such a lawless place that vendors can steal and resell your software at will. You have legal recourse in some cases, and not in others.
Nothing is fool-proof, as previously stated. Also, the more complex your security is, the more likely it is to cause headaches or problems for legitimate users.
I'd say the most secure application is always the one tied closest to the server. Sadly, then users worry about it being spyware.
If you make a lot of different calls to your dongle, then maybe the cracker will just emulate your dongle -- or find a single point of failure (quite common to change one or two bytes and all your calls are useless). It is a no-win situation.
As the author of PECompact, I always tell customers that they can not rely on anything to protect their software -- as it can and will be cracked if a dedicated cracker goes after it. The harder you make it, the more of a challenge (fun) it is to them.
I personally use very minimal protection techniques on my software, knowing these facts.
Use smartcard + encrypt/decrypt working files through secret function stored in card. Then software can be pirated, but it will not able to open properly encrypted working files.
I would say that if someone wants to crack your software protection, they will do so. When you say 'hard enough' - how should 'enough' be interpreted?
A dongle will perhaps prevent your average user from copying your software - so in that sense it is already 'enough'. But anyone who feels the need and is able to circumvent the dongle will likely be able to get past any other scheme that you engineer.