How to disable the «exe compression» in order to avoid false (virus) positives

[Joris Claassen]

A couple of anti virus programs mark all my compile results as viruses:

         (13:CLAMAV:PUA.Win32.Packer.PellesC400450Ex-1 ()).

I can't control the anti virus programs which clients use. At least one client uses one of these to scan all incoming mail. So my e-mail with the program attached (in a zip) is never "delivered to the person". (i.e. the e-mail is removed by the virus scanner before it arrives in the mail inbox.) After searching at the web for a few days, I have only found that this is caused by the «runtime packed» a.k.a. «execution compression» feature of the compiler (or linker?). But I could find nowhere how to disable this feature. Does anyone know a pragma directive (or anything else) to achieve this?

I already installed UPX and tried to undo the compression (on the compile result «test.exe») with « packer -d  test.exe » resulting in the message:

         packer: test.exe: NotPackedException: not packed by UPX

[CommonTater]

Pelles C does not produce compressed or packed executables.  They're in standard windows Portable Executable (PE) format.  Provided you are not actually writing virii .. if the AV scanner is complaining about them it is most likely a "false positive".  What I would suggest is that you find out which AV programs are tagging your code and contact the companies to get this straightened out. 
 
In the mean time there are some things you can investigate on your own...

1) Do the programs that get tagged have something in common?   eg. A self-written function or library that might be causing the problem? 

2) Do your programs include manifests?  If not this may be the cause.

3) Are the programs in installers?  It may be the installer that's triggering the AV alert.
 
4) Are you using the Pelles C wizards to create your programs?  It could be that the wizard template is the problem.

... and probably more.
 
 

[Joris Claassen]

Thanks CommonTater, that explains why I can't find anything about disabling the packer ...

Strange for a virus scanner to mark something as PUA.Win32.Packer.PellesC and then explain in their FAQ (http://www.clamav.net/lang/en/faq/pua/):

PUA – Possibly Unwanted Applications

ClamAV supports the detection of so called PUAs. At the moment the following categories are available:

Packed

This is a detection for files that use some kind of runtime packer. A runtime packer can be used to reduce the size of executable files without the need for an external unpacker. While this can‘t be considered malicious in general, runtime packers are widely used with malicious files since they can prevent a already known malware from detection by an Antivirus product.

I want to extend the possibilities at the command prompt of CAD programs (special request by a client). In order to place my extended version above the original one (so the end user might not even notice it's another application; and doesn't need to move eyes and mouse cursor ...) I have to find out where the command prompt is. So I use FindWindow(Ex) to determine the location (and size) and I use SendMessage at start to set the prompt text (which can differ!) and to retrieve the user input. I know virus scanners might detect this as suspected, but I think in that case the scanner shouldn't mark it as a «Packer» but as something like «interapplication communication, might be harmful». Then I know at least the right reason.

[CommonTater]

Ummmm... are you shure it's not reacting to the installer? 

That's the only reason I can see that it might dub it a packing error, most installers do use self-expanding code.

I ran into this with an older version of Inno-Setup... someone must have submitted it as a trojan and all of a sudden none of my installers worked... Updating to the newest version (at the time) fixed the problem.  But I also wrote to the AV company in question and chewed them out about not checking user sumbissions...

Given the "cheat" you're using I can see why a virus scanner might freak out on you... You are doing exactly what many viruses do; reading text from the screen.  Although, not for nefarious reasons.

Maybe you should consider opening your own command prompt as a replacement for the standard one in the CAD program.... and "going legit" on how you gather input?
 
Sometimes we're too clever for our own good...
 

[Vortex]

Hi  Joris,

Try to configure your AV to define the executable in the exceptions list.

[Stefan Pendl]

Try to configure your AV to define the executable in the exceptions list.

This only solves the problem for him, but not for the clients.

If you send the file to the clients use 7-zip to create a password protected archive, where the file names are encrypted too.
This has always worked for me to prevent the executable causing the whole message being dropped.

[CommonTater]

Try to configure your AV to define the executable in the exceptions list.

This only solves the problem for him, but not for the clients.

If you send the file to the clients use 7-zip to create a password protected archive, where the file names are encrypted too.
This has always worked for me to prevent the executable causing the whole message being dropped.

OR rename the .ZIP as .TXT and include instructions to rename it before unpacking it.... That's worked for me a few times.

[Stefan Pendl]

OR rename the .ZIP as .TXT and include instructions to rename it before unpacking it.... That's worked for me a few times.

This does only work with virus scanners that do not scan the contents of the file, which are getting less and lesser.

Sure the encrypted 7-zip archive is sometimes rejected too, but that is only if the user selects to do so.

[Joris Claassen]

Ummmm... are you shure it's not reacting to the installer? 

...

I don't use an installer at all. Whenever possible I only send a zip file. I think a big advantage of Pelles C results is that they usually don't depend on third party dll's/ocx's. Unless you code to. So there's no need to use installers to check the registry for existence of those and install them when absent. When the first clients start using MS Window 7, I also removed any use of/dependency on the registry for settings in favour of the ancient INI files to avoid UAC issues (and the risk of false positives).

...
Given the "cheat" you're using I can see why a virus scanner might freak out on you... You are doing exactly what many viruses do; reading text from the screen.  Although, not for nefarious reasons.
...

I understand that a scanner might freak by the API calls, but it shouldn't mark it as PUA.Win32.Packer. (But something like PUA.Win32.I-dont-trust-apps-using-API-calls. )
I only determine the location of the command prompt to place my custom made command prompt¹ above it to mimic the CAD one. It has it's own application window². I don't change any properties of the CAD one (or any other CAD owned control/window). The user input is saved in a file which is read by a lisp routine. The build in lisp functions to retrieve user input are too restricted in functionality (=user experience).

Years ago I dropped LCC because a virus scanner marked all my compile results (even "Hello world"!) as threats. The "same code" in Pelles C didn't raise any suspicion. I don't know any of them (!) but I think that when a virus creator can write a virus using LCC as compiler, he can use any C(++) compiler.


¹: Including a combobox "loaded" with previous entries for the specific function in progress.
²: Without caption/control bar/borders so the end user doesn't need to bother and might think it's the original CAD command prompt, but it's actually an external program. The window is not put in the window hierarchy of the CAD program.

[CommonTater]

I don't use an installer at all. Whenever possible I only send a zip file. I think a big advantage of Pelles C results is that they usually don't depend on third party dll's/ocx's. Unless you code to. So there's no need to use installers to check the registry for existence of those and install them when absent. When the first clients start using MS Window 7, I also removed any use of/dependency on the registry for settings in favour of the ancient INI files to avoid UAC issues (and the risk of false positives).

Using INI files will not get you around the UAC... UAC works by examining the resources of the EXE or DLL files looking for an imbedded manifest.  If that fails it looks for a free standing manifest in the same folder as the executable.  When there is no manifest it usually decides the program is risky and asks the user to confirm they want to proceed.  Many virus scanners also check manifests...
 

¹: Including a combobox "loaded" with previous entries for the specific function in progress.
²: Without caption/control bar/borders so the end user doesn't need to bother and might think it's the original CAD command prompt, but it's actually an external program. The window is not put in the window hierarchy of the CAD program.

It might be #2 that's tripping you up. 
 
A virus scanner cannot legitimately freak out about individual windows API calls, directly, since they are by definition legitimate subroutines made available to the user.  They work mostly by pattern recognition so it would take a complex of several calls to trip a legitimate positive. (For example a keyboard hook in a tight loop with disk writes might signal a keylogger.) Also keep in mind that C library functions are not magic, at some point many of them call Windows API functions to do their thing.
 
Given your descriptions so far, I would say your best bets are to 1) Add a manifest into your program's resources, 2) Use a properly formed window, 3) return to using registry settings.  Each of these is at least worth a try... but I'd suggest you do all of them.
 
Since manifests are poorly explained on MSDN here's an example you can modify to your own uses...

Code: [Select]


 <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity type="win32"
                    name="AutoLogon"
                    version="1.0.0.0"
                    processorArchitecture="X86" />
  <description>
    Auto logon tool
  </description>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32"
                        name="Microsoft.Windows.Common-Controls"
                        version="6.0.0.0"
                        processorArchitecture="X86"
                        publicKeyToken="6595b64144ccf1df"
                        language="*" />
    </dependentAssembly>
  </dependency>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel  level="asInvoker"
                                  uiAccess="false" />
      </requestedPrivileges>
    </security>
  </trustInfo>
</assembly>
To personalize it for your programs you will need to change the name= to the name of your program (without extension), the description block to describe your program in 10 words or less, and if it's a 64bit program you would change the processorarchitecture to amd64.  DO NOT change anything else. You would then import this file into your program's resources (create them if they don't already exist).
 
About the only other possibility I can think of is that some #$%#$%^ has reported a virus written in Pelles C (yes, it can happen) and now the scanner is freaking out about every Pelles C program.  In that case I'd be getting hold of these AV guys right quick...
 

[Joris Claassen]

Given your descriptions so far, I would say your best bets are to
 1) Add a manifest into your program's resources,  ...

I do use manifest files in order to be able to communicate with CAD (and UAC not disabled!). That's not the issue here.

2) Use a properly formed window,

I made a VB6 exe version with the same API calls and window without caption/control bar/border : accepted by the mail virus scanner!

3) return to using registry settings.  Each of these is at least worth a try... but I'd suggest you do all of them.

I mentioned the INI files, because I know a lot of registry sections are restricted by now. An ini file in the application (private) folder is still accepted (when compiled without PellesC) Actually the program which triggered this issue doesn't use INI files at all.


The program isn't run at all at the client side. The mail virus scanner blocks the mail before the recipient can look at it.

About the only other possibility I can think of is that some #$%#$%^ has reported a virus written in Pelles C (yes, it can happen) and now the scanner is freaking out about every Pelles C program.  In that case I'd be getting hold of these AV guys right quick...

I think that's the case. (As usual the good suffer from the bad.)

I made a DLL version with exacly the same API calls: accepted by the virus scanner.
I made the hello world program with the Windows exe wizard (unmodified): blocked!

Unfortunately using the DLL inside VBA makes CAD crash, otherwise I would use that. The VB6 version interpreted the coordinates as negative values (because VB doesn't know unsigned variable types). So now I decided to make a VB6 version using a DLL for repositioning. So except for the calls to «GetWindowRect» and «MoveWindow», all API calls are inside the VB6 exe.

I think it's pity that I need to use VB6 to workaround this.

[CommonTater]

I think it's pity that I need to use VB6 to workaround this.

It is... there's obviously something very wrong here. 
 
That it blocked "hello world" is troubling, since it could indicate there's a problem in the PE file structure itself.

Try this...  (Assuming you're on Pelles C ver7) Uninstall Pelles C, completely.  Even go to the registry and remove the Pelle Orinius branch from the software section... Install Pelles C 6.5 ...
In your project folders open the .prj files in notepad and change the POC_PROJECT_VERSION macro to 6.0... This will cause a couple of errors you'll have to fix in the compiler flags, but that's not hard... recompile your project and let me know what happens when you email it...
 
(I'm operating on the theory there's something about the new version... )

 

[TimoVJL]

HelloC.c with versions 6.0, 6.5 and 7.0 for testing.

Code: [Select]

#include <stdio.h>

int main(int argc, char **argv)
{
printf("Hello C\n");
return 0;
}

[Joris Claassen]

Actually I'm still using version 6.00.4, my ppj files contain:

Code: [Select]

POC_PROJECT_VERSION = 6.00#
Until last week this version worked for me, so I had no reason to change.

I have sent 3 e-mails each containing one of the files posted by timovjl:  all resulting in

Remote host said: 550 5.7.1 Message contains a virus (13:CLAMAV:PUA.Win32.Packer.PellesC400450Ex-1 ()) [BODY]

So I think some #$%#$%^ made a virus with Pelles C and now we are all ... up, because Clamav has marked the Pelles C exe PE structure to be suspected.

[CommonTater]

So I think some #$%#$%^ made a virus with Pelles C and now we are all ... up, because Clamav has marked the Pelles C exe PE structure to be suspected.

Then you need to take those samples and send them to the AV company and get this straightened out.  I'd send the whole project so they can see there's nothing wrong.

@Timo ... thanks for that.  Very helpful!

 
Update: I just sent timo's samples to a friend of mine.  He confirms over the phone they went through his scanners just fine (AVG)...