PerlSvc 9.5.1 exe is flagged by Syamtec Enpoint Protection as a virues and gets quarantined.

Posted by thloeber on 2017-05-30 02:43
Forums: PDK discussion | OS: Windows

I've written a Windows service using PerlSvc 9.5.1. When the complied exe is placed in a directory on the c: drive of a Windows 32 bit server, SEP flags the exe as a virus and quarantines the module. If I disable SEP before placing the exe on the system, I can successfully start the service, but when SEP is restarted, it flags and quarantines the exe. All the service does it opens up a listening SSL protected socket on a port which accepts socket connections. Does support have any suggestions on why this is happening? The same perl code, when compiled on a 64 bit windows system with PerlSvc and placed on a Windows 64 based system does not get flagged by SEP.

i-shenl
ActiveState Staff
Tue, 2017-05-30 07:37

Is the DB for SEP on the Win 32 box not up to date? What I would suggest doing is setting SEP so that it doesn't block/flag PerlSVC.

grahams
ActiveState Staff
Wed, 2017-05-31 13:19

The design of wrapped Perl executables is identical to certain classes of virus.

This problem is one of the reasons why Perl Dev Kit has been discontinued.

As long as AntiVirus software uses either Reputation Based rules or Behavioural Based rules (and that will likely be for ever), wrapped Perl executables will be blocked by these generic definitions. It takes a whitelist entry from your AV vendor, in most cases, to let the suspicious file run.

This is only one of the liabilities or compromises that using a wrapped Perl file forces. Work-around the problem by writing your service so that you don't need to wrap it.

thloeber | Fri, 2017-06-09 08:11

One of the comments I received relative to my forum post (https://community.activestate.com/node/21498) was to write my service so it would not need to PerlSvc wrapper. I've been trying to do this using Win32::Daemon with it's call backs. I've run into an issue though. This service opens a listening ssl socket (IO::Socket::SSL) and sits in a loop waiting for, and handling) client socket connections. When the service enters a running state, the running callback routine tries to create a socket using IO::SOCKET::SSL->new(). The call to that never returns when I start the service. If I run the executable as a command (not start it as a service) the socket connection gets created and the listening loop processes as normal. This worked perfectly when wrapped with PerlSvc so I know it should work without it, but I'm at a loss to figure out why the new socket call never returns. I'm hoping to get some insight here.