Avira antiVirus

[Emil_halim]

Hi All,

my Avira anti virus detects two virus in those files [ Oxide.exe ,  co2.exe ].

does any one have this problem.

[Peter]

my Avira anti virus detects two virus in those files [ Oxide.exe ,  co2.exe ].

No, I got never a virus!
my virus scanner is self made. 

[Charles Pegge]

Unfortunately,  Avira persistently throws false positives.

[Arnold]

I gave up Avira long ago because the scanner reported too many false positives. For my personal use the scanner of MS Essentials is sufficient.

Sending co2.exe and oxide.exe to www.virustotal.com will show 5 (false) positives of 56 results:
Oxide.exe: AegisLab, Avira, Ikarus, Qihoo-360, Rising
co2.exe: AegisLab, Avast, Avira, Ikarus, Rising

51 messages indicate that the files are ok. If some scanners like Kaspersky, McAfee, Microsoft or Symantec would complain I had a real problem. Not because of Oxygen, but because of something else which went totally wrong with my system.

[Emil_halim]

Hi charles,

still my avast antivirus refuse to run co2.exe , also it removes it from my computer.

only it accepts  gxo2 , so can you help me?

[JRS]

Avast anti-virus is the worst software you can use. You're better off with Microsoft's Essentials. (free)

[Mike Lobanovsky]

Charles,

Low quality free anti-virus software like Avira and Avast and a lot of other "brand" names is unfortunately spread very widely among inexperienced computer user base due to being bundled liberally to the installation packages of other, more useful general-purpose software.

A number of easily accessible "anti-malware" sites like VirusTotal.com and similar are also full of such low-quality AV specimens and offer an ill service of false flagging decent software as malware.

An extremely poor implementation of heuristics engines in such low quality AV software cannot tell well-behaved programs like OxygenBasic components from genuine malware other than by checking if OxygenBasic binaries meet certain criteria that MS Windows sets for modern executable files.

Thus, a legit Windows executable should have valid file time and checksum stamps and should carry an embedded icon and version info resources. It should also be supplied with either standalone or embedded manifest resource, preferably with multiple definitions of OSes the executable is supposed to be compatible with.

The Oxygen binaries have neither version info nor manifest resources, standalone or embedded. This is sufficient for the low quality Avira and Avast to falsely flag them as potential malware.

Perhaps you would find it not so burdensome to add both the version info and manifest resources to your compilations of O2 binaries for inclusion into the future regular distributions of OxygenBasic? It might also be reasonable to make the O2 compiler link at least minimal precompiled icon, version and manifest resources transparently into every user compiled executable written in O2.

[Charles Pegge]

Hi Emil,

Avast, which I also use,  has got more paranoid over time. I always work with the File Shield turned off.

The 'Ask' option does not allow execution

I found the false-positive reporting option in the current update, so I hope co2 and other o2 executables will not be blocked in later updates.

[Arnold]

If the measures which Mike suggested can help to get rid of these nasty messages this would be really brilliant.

I always wondered why using tcc results in warnings by these scanners whereas gcc will get no warnings.

[Charles Pegge]

Hi Mike,

Yes, I will look into embedding these ornaments, but I doubt that icons and manifests are involved in malware detection, since the most insidious code will be well disguised inside a legit-looking piece of software.

Furthermore, the Anti-Virus attacks, when the newly compiled program is being stored to a PE file, prior to embedding of icons and other resources.

[Mike Lobanovsky]

Roland,

Using windres.exe from the GCC distribution to precompile the icon, version info, and manifest resources into an .o file and then linking it with your TCC .o files effectively eliminates false alarms issued by low-end AV software.

Apparently GCC is also on the exclusion list of most AV software -- something that's a paid service that the volunteer TCC dev team cannot afford.

OTOH intelligent AV packages like Kasperski, Ez Nod, Microsoft Essentials and a few others would not throw false alarms at either TCC or O2 executables; apparently their heuristics is strong enough to analyse the executables for their real, rather than face, value.

[Mike Lobanovsky]

Hi Charles,

Thanks for your prompt response to my suggestion.

... the Anti-Virus attacks, when the newly compiled program is being stored to a PE file, prior to embedding of icons and other resources.

I am not talking about embedding the resources post-factum into the already compiled but still resourceless executable the way ResHacker does it. I'm talking about linking the precompiled resource object files at the stage when GAS (or GCC) back end links the O2 object files written in, and pre-translated by, FreeBASIC into assembly or C, respectively, into the resultant O2 binaries.

If the O2 compiler, in its turn, does not make use of intermediary object files when compiling user executables written in Oxygen, then it should have appropriate procedures hardcoded into it by hand to patch the executable header section table and other relevant header entries with the info about the precompiled .rsrc section you're adding to the executable manually while the executable's image is still in the compiler memory and before it is finally dumped to the disk.


[HINT] If you're uncertain about how to calculate correct, Windows-compliant CRC-32 for the in-memory image of an executable file that the MapFileAndCheckSumA() API is only able to calc for the on-disk file images, you may use the following C code making sure to omit from the calculation the four bytes of the executable's header where the resultant CRC-32 value proper is going to be written to (just reset them to zero for the calculation purposes). If you are going to use some language other than C to re-implement this code, also make sure to use C-compatible data types and follow the C rules of operator precedence to ensure compatible results:

Code: C

1. unsigned long   crc32_table[256]; // CRC-32 LUT
2.  
3. unsigned long crc32(char* data, int dataLen) {
4.   if (0 == crc32_table[1]) init_crc32_table(); // init LUT once only
5.  
6.   // Be sure to use unsigned variables,
7.   // because negative values introduce high bits
8.   // where zero bits are required.
9.  
10.   unsigned long ulCRC = 0xffffffff;
11.   unsigned char* buffer = (unsigned char*)data;
12.  
13.   // Perform the algorithm on each byte in the
14.   // data stream using the lookup table values.
15.  
16.   while (dataLen--)
17.     ulCRC = (ulCRC >> 8) ^ crc32_table[(ulCRC & 0xff) ^ *buffer++];
18.  
19.   return ulCRC ^ 0xffffffff;
20. }
21.  
22. // Call this function only once to initialize the CRC table.
23. void init_crc32_table(void) {
24.   // This is the official polynomial used by CRC-32
25.   // in PKZip, WinZip, Ethernet, and Win PE headers.
26.  
27.   unsigned long ulPolynomial = 0x04c11db7;
28.  
29.   register int i;
30.   for (i = 0; i <= 0xff; i++) {
31.     crc32_table[i] = reflect(i, 8) << 24;
32.  
33.     register int j;
34.     for (j = 0; j < 8; j++)
35.       crc32_table[i] =
36.         (crc32_table[i] << 1) ^ (crc32_table[i] & (1 << 31) ? ulPolynomial : 0);
37.     crc32_table[i] = reflect(crc32_table[i], 32);
38.   }
39. }
40.  
41. // Reflection is a requirement for the official CRC-32 standard.
42. // You can create CRCs without it, but they won't conform to the standard.
43. unsigned long reflect(unsigned long ref, char ch) {
44.   unsigned long value = 0;
45.  
46.   register int i;
47.   for (i = 1; i < (ch + 1); i++) {
48.     if (ref & 1)
49.       value |= 1 << (ch - i);
50.     ref >>= 1;
51.   }
52.  
53.   return value;
54. }

[Emil_halim]

nice charles,

waiting for next release , hope it will be soon.

[jcfuller]

Roland,

Using windres.exe from the GCC distribution to precompile the icon, version info, and manifest resources into an .o file and then linking it with your TCC .o files effectively eliminates false alarms issued by low-end AV software.

Apparently GCC is also on the exclusion list of most AV software -- something that's a paid service that the volunteer TCC dev team cannot afford.

Mike,
  What are the windres options for 64bit?

James

[Mike Lobanovsky]

Hi James,

TCC cannot utilize either VC COFF-formatted .obj files or GCC .o files in either COFF or ELF format, but it can cope with windres.exe's COFF-formatted .o files that contain pure resources and nothing else but an #include "resource.h" directive at the most. If your input .RC file uses #defines instead of numeric literals as resource IDs, then the "resource.h" would contain a list of those #defines.

windres.exe uses the corresponding GCC it comes with to preprocess the .RC input file, so if the GCC switches are set for x64 compilation (I presume in your case they always are), then the windres.exe command line switches (assuming again all your files are in you current path and/or are accessible via environment variables) will be pretty simple:

windres -O coff -i inres.rc -o outres.o (avoid space delimited file paths using Linuxoid software!)

Once compiled, link the resultant resource object file outres.o with the other TCC source files of your current compilation, e.g.

tcc main.c outres.o -luser32 -o yourapp.exe (ditto!)

Please note that some x64 TDM-GCC builds of windres.exe fail to compile valid 32-bit resource object files even when GCC's own cross-compilation switches are set correctly. Prefer to use original x64 MinGW/GCC builds of windres.exe to cross compile 32-bit resources on 64-bit platforms, or use original 32-bit windres.exe for that purpose.

Note also that if you aren't using #defines in the source .RC file as your resource IDs at all but rather numeric literals only, then windres.exe can work independently of your GCC installation. That is, you can simply port (copy) it to a computer that doesn't have any other traces of GCC installation and use it to compile the resources as indicated above. In this case, a 64-bit windres.exe would yield 64-bit resource object files, and a 32-bit windres.exe, 32-bit resource object files, respectively.