Exactly as the title says…
I work with several systems and one corporate system operating Norton symantec end-point protection flags the exe files produced by HE as a suspicious MLapp and refuses to let me even unzip them. It sends them directly to Jail.
This could be a major problem for me if I can’t distribute the software without being flagged by over-eager antivirus systems.
This never happened with my previous compiler software.
Is there anything GDG can do about it?
No, it’s a false positive of Norton AV. Symantec has to fix their signatures so that your EXE isn’t detected.
Another recommended solution: digitally sign your EXE files with a code signing certificate. For HTML Executable customers, we have a special offer from a Comodo partner, see: http://www.htmlexe.com/help/codesigning.htm
I am having the same problem, A project I built three weeks ago works fine. One I build this week and any project I have built since then on serveral different machines gets killed by norton as soon as I try to run them, and sometimes just when it reads the folder the exe is in. Not talking download, this is on the same machine as it was built on. I have run the same html files through “Site in File” compiler and it works perfect, and a software I built with “Tiger Software Builder” works fine too. It has something to do with the HTML.exe it does not like. I don’t know what has changed but it is going to be a problem. I always have to turn of norton when I use HTML.EXE to get it to compile properly. FYI
Any more thaughts?
Here is an email I received from Symantec (Norton AV)
We are writing in relation to your submission through Symantec's on-line False Positive Submission form for your software being detected by Symantec Software. We are unable to locate the software you specified on the website from the URL you submitted. Without the software we are unable to further investigate this issue.
Due to not being able to retrieve the software in question, we ask that you do the following:
* Provide a screen shot or log message to help us identifying the issue
* Submit the detected file to us via the link below and reply with the tracking number:
https://submit.symantec.com/retail/
Please note that the submission form above will not accept files larger than 10MB in size. Please respond to this email within 14 days with all questions or requests above answered. Failure to respond to this email within 14 days will deem the False Positive Report submission to be no longer valid and initiate a closure procedure. Once closed a new submission for the same issue can be opened up to two times. Each new submission is subject to the time frame for response of a further week from the submission date.
Sincerely,
Symantec Security Response
We should all fill in the false positive form at the link above, uploading a file made by HE (less than 10Mb)
Message from Symantec:
We are writing in relation to your submission through Symantec's on-line Security Risk / False Positive Dispute Submission form for your software being detected by Symantec Software. In light of further investigation and analysis Symantec is happy to remove this detection from within its products.
The updated detection will be distributed in the next set of virus definitions, available daily, or weekly via LiveUpdate, depending on Symantec product version, or daily from our website at
http://securityresponse.symantec.com/avcenter/defs.download.html.
Decisions made by Symantec are subject to change if alterations to the Software are made over time or as classification criteria and/or the policy employed by Symantec changes over time to address the evolving landscape.
If you are a software vendor, Symantec offers the possibility of adding your software to its database of known clean files in order to reduce the possibility of false positives. If you wish to participate in this program, please complete the following form.
https://submit.symantec.com/whitelist
Sincerely,
Symantec Security Response
Thanks for the follow-up.
Since upgrading to version 4, we have had consistent problems of Norton deleting the generated .exe file immediately. We have reported the false negative to Norton and are awaiting a reply from them in the next day. What is interesting to us, .exe files created with version 3.6.5 do not incur Nortons curse of being immediately deleted yet the version 4.0 files do! This is interesting and I wonder why files created with different versions of the same program should be treated differently by the same Anti-Virus software?
Good question, however, you should ask it to Symantec. HE 4 was built with a different compiler than HE 3.6 so maybe it could explain?
Is there no way that GDG could contact Norton to explain this situation.
After all you compile and market the software that is causing the problem.
Norton offer a whitelisting service for commercial applications. Can you not discuss including GDG software and their products in Norton’s whitelist?
Sure, we are contacting them but there is no guarantee:
After reading this thread, I did some tests with an older version of Symantec AV. This is not End Point but the definitions are up to date. I’m also very concerned with false positives because I won’t know what AV software my users will be running.
After scanning some test compilations, they were all supposedly infected with Suspicious.MLApp See the link below.
I then recompiled a couple of tests without the runtime embedded and then the scans found nothing. It appears attaching the runtime is causing the issue, at least with my tests.
Now the surprising part and I think I need to change AV programs. When detected, the programs with the runtimes, were not automatically deleted or quarantined, they were cleaned. I did a byte for byte comparison and nothing was changed or deleted in the file after being cleaned. After scanning again, the files was supposedly cleaned again and again no changes to the files took place. A little more digging and supposedly something was deleted in the Internet cache but nothing was actually changed in the EXE files.
I would suggest scanning with End Point without the runtime embedded and see if that makes a difference.
{edit}
I found no issues when scanning the runtime EXE’s. One possible workaround is to keep your EXE and the runtime separately and possibly install the runtime from your installer app. Hopefully the runtimes will support silent installs. I plan on testing this in the next couple of days.
Tech Support: Can the runtimes be installed silently?
Later,
HawkeyeTX
Yes, runtimes are in MSI installers. And MSI installers can be silently installed. See http://msdn.microsoft.com/en-us/library/windows/desktop/aa372024(v=vs.85).aspx
Regarding the suspicious MLapp error from Norton, see http://www.symantec.com/connect/forums/how-exclude-suspiciousmlapp-detected
This just boggles the mind. If HE.exe v 4 has a different compiler than the previous version, and the old compiler compiles files that do not trigger the Norton effect-seems to me that you should try to ascertain why new compiler not creating clean files. I too rely on distributing HE.exe files that change often. Currently, I must upload a newly created exe file to Norton and have them add to their “clean” list, but as soon as I change the file in any way, the Norton curse returns. I cannot continue in this manner. I feel this is a matter that should be cleared up by the software creator and should not be the responsibility to the users of your software.
netsurf, I am curious on a couple of items since I have not distributed mine as yet.
Thanks,
HawkeyeTX
Yes, embedded runtime. No code signing
Hi Hawkeye,
My runtime is embedded mainly because I don’t know how to compile without it! I am using code signing from Comodo as advised, but it does not help.
My situation is that I have built up a (small) business using a compilation competitor and I switched to HE as it seemed to offer me the extras I was looking for (zoom mainly), but also a support community.
Now it seems that there are issues that can’t be resolved and I can’t rely on software that is flagged by antiviruses. Having said that, the competitor compilation software had a similar problem with AVG some time ago but AVG resolved it immediately a a false positive. But it didn’t flag every build as a different program, it just required one test and that was that.
I have made a demo.exe for analysis by Symantec which they agree is a false positive, but my actual compiled commercial software is still flagged. I can’t send a copy to Symantec as it is over 20 Mb in size (their limit), so I am stymied.
My feeling (echoing the post from netserf) is that if there was no problem with version HE3.6 then I would be prepared to use that instead. I simply cannot afford to use HE4.0.2 if my customers lose faith.
It seems to me that GDG should revert to a version with no known issues and improve that rather than introducing one that is causing problems. Without a solution to this issue I am going to have to revert to my old software or seek another alternative.
Cheers
Charco
netsurf, thanks for your response.
I guess that the code signing is meaningless to AV software based on two responses, one with and one without codesigning still flags the AV software. .
Charco, to compile without the runtime module, go to the ***Application Output ***of your project and then select the Runtime Module. Select the option, Do not merge the runtime module: I’ll distribute it separately and then compile your EXE and see if it still gets flagged by your AV software.
In my tests, with and without the runtime module, Symantec only flagged the one with the runtime module embedded.
If there is no other way around this and I have not completely tested this myself as yet but I have built other installations without the need of a runtime.
Use an installation program so both the runtime and your EXE are in the same installation package and put in the same directory, using the information below, you can run the runtime installation separately and silently without the user knowing.
After it is run, if possible, test that the runtime is installed, by a return code or by checking that the runtime exists. On Windows, XP, it is here, C:\Program Files\Common Files\HTML Executable Viewer{A528D704-C323-4636-A1F2-E9E8A725CDA9\HEIERun.dll, for the IE version, and then the runtime installer can be deleted. It is still in your installation package.
My installation will include shortcuts for the current user’s desktop and a menu item which will start the EXE in full screen mode.
My original plan was above with the runtime embedded so I can have the menu’s updated and the shortcuts created but by installing the runtime separately just adds a couple of more steps.
Post if you have any questions, on the above.
HawkeyeTX
Just to keep you informed: I think that I identified the reason why Norton triggers this false alarm so we are working on the next update of HTMLExe that will be scheduled (hopefully) before Christmas. This update should fix the Norton problem and offer the ability to create real stand-alone EXE files (currently, when it is merged into the EXE, the runtime module is unpacked to the temporary folder, this is probably one of the reasons why Norton flags the program as suspicious). With this new feature, the EXE file will not unpack anything to the temporary folder.
FYI, When I did the tests, as listed earlier, with the runtime embedded and not, I never attempted to actually run the EXE’s directly and it was never run on that machine before. I did a custom scan on the folder on where the EXE’s resided and only the runtime embedded one was flagged.
Is it possibly the way the internal code looks to Symantec that would invoke the runtime. I would assume, Symantec is seeing the EXE with a possible piggyback program embedded and automatically flags it. I am curious how or what the differences are between the ver 4 and ver 3 compilers when they attach the runtime.
Hope this helps.
HawkeyeTX
I believe that Norton once detected an EXE that unpacked the runtime to the temporary folder, and sent some footprint about the EXE format to its cloud database. So now every EXE is detected.
Regarding the differences, maybe there is something in the new runtime that Norton disliked, in addition to the fact that it was unpacked to the temporary folder (this seems to increase the suspicion of antivirus programs…)