59

I've seen it happen reasonably often: I write an application in Delphi and when I compile it, the virus-scanner tells me that I've created a virus and then immediately deletes the executable again. It's annoying but reasonable easy to fix by doing a full rebuild, deleting the *.dcu files first and sometimes by simply waiting.

It happens with Delphi 6, 7, 2005 and 2007, as far as I know. And Symantec, Kaspersky, McAfee and NOD32 have all been guilty of reporting these false positives. I know it's because Delphi adds timestamps to its DCU files and these timestamps end up in the final executable and apparently appear to be part of some random virus signature.

I don't want to disable the virus-scanner, not even for a single folder or file. And I'm not really for a solution, but am wondering about the following:

  • Do these false positives also occur with other compilers?
  • Does it also happen with .NET executables?
  • Do others also notice similar problems with Delphi?
Wim ten Brink
  • 24,763
  • 19
  • 72
  • 138
  • 1
    Just want to add that this error is quite rare, but it still happens about once every three months with me or one of my collegues. – Wim ten Brink Jun 14 '09 at 20:39
  • Karpesky flagged as virus one program I did. I emailed them and they fixed it for the following updates. – Averroes Mar 15 '10 at 13:52
  • 3
    @Tom, Delphi's prevalence might have more to do with pascal like languages being popular in East Europe. – deft_code Aug 20 '10 at 21:48
  • 1
    It's not a false positive: Win32/Injector.CKX trojan – Johan Oct 04 '13 at 03:44
  • 2
    If it is the Win32/Injector.CKX trojan then McAfee and other virusscanners should report this for every project that's compiled with Delphi. However, recompiling the project on another system with the same files, or recompiling everything a few hours or even a day later had no more warnings. As Tom suggests, Delphi used to be great for writing malware, thus some malware signatures might match those of innocent Delphi applications. (Simply because the signature is too generic.) – Wim ten Brink Oct 05 '13 at 11:13

17 Answers17

103

Do these false positives also occur with other compilers?

Yes, this is has been a common problem in the past for AutoIt as addressed in this forum post "Are my AutoIt EXEs really infected?". In most cases including AutoIt it stems from poor heuristic practices. Since AutoIt uses the free and open UPX compressor, it is often mistaken for malicious code that also uses UPX.

The best (and possibly only) thing you can do is report these mistakes, so they can refine their heuristics or at least white list your app.

Below is a list of contact information for some popular anti-virus companies. They all claim to appreciate submissions as it helps them make their product better.

Turns out there is a great list of AV software on wikipedia, called 'List of antivirus software'. It is more complete than my list above.

A member of the Autoit Forums made a great script to e-mail a false positive to a huge list of AV vendors to automate this process a bit.

Copas
  • 5,750
  • 5
  • 27
  • 43
  • 3
    But they are only interested if you are the author. For years McAfee declared an .OBJ file on my system a potentially unwanted program--yet it had no problem with an .EXE incorporating it. I wasn't the author, though, and since it was an old, no-longer-supported version the author wasn't going to do anything. – Loren Pechtel Jun 15 '09 at 17:50
  • 2
    @Loren: Interesting, I wasn't aware they made such distinctions. Thanks for the heads up! – Copas Jun 15 '09 at 18:22
  • 1
    Another for your list (I don't have the rep to edit), VIPRE from Sunbelt Software, www.sunbeltsoftware.com – Argalatyr Jun 19 '09 at 03:48
  • @Copas: that's "Vipre", not "Viper" - since you're trying to set up a reference list – Argalatyr Jun 20 '09 at 02:14
  • 1
    Note that UPX is not all that useful. It makes your programs take significantly more memory to run and has far fewer benefits on modern systems than it had earlier. – R.. GitHub STOP HELPING ICE May 24 '11 at 02:04
  • There is a any successful law suit again an antivirus company? – Z80 Mar 05 '14 at 17:54
  • More than that, AutoIt scripts are Turing complete and can contain embedded binaries so Trojan droppers use it a lot. Unfortunately the antivirus detects viruses on the AutoIt shell rather than reading the embedded script. Boo. An AutoIt script that doesn't drop an executable probably isn't infected. – Joshua Jan 22 '19 at 04:45
11

Sounds more like a heuristic screw-up to me. Do you have heuristics turned on (some scanners may refer to it as "virus-like code")? The chances that time stamps would equate to "a portion of some virus signature" seems too small to be happening all the time.

When I used to run a virus scanner, I never saw this problem with D6 or D7.

JimG
  • 1,754
  • 8
  • 9
  • 1
    Yes, heuristics are on. Not that I mind, since the computer should be kept secure so I rather deal with the occasional false positive than to be the source of infection. I'm often working on software for the financial market and thus much of it is sensitive information. – Wim ten Brink Jun 14 '09 at 20:38
9

There is indeed Delphi virus in the wild, see http://www.sophos.com/blogs/sophoslabs/?p=6117

Dmitry Osinovskiy
  • 9,629
  • 1
  • 45
  • 36
8

Yes, my team has experienced this maybe half a dozen times in 2-3 years with Sophos in a corporate environment. So, very rarely, but it does happen.

Our IT cretin started off demanding I review all the 1.5M lines of code in our app to "make it go away", but he didn't get too far pursuing that line...

To be fair, he was initially concerned that our clients might also receive such a warning, but we've only ever seen it triggered when building an exe from the IDE on a developer's PC, never on a release build exe on a test box or elsewhere.

Personally, it happens so rarely we don't worry about it.

Conor Boyd
  • 1,004
  • 7
  • 15
  • 2
    I'm not worried about this too. It's just annoying since it means some additional delay when building a new executable. It's a bit worse on our automatic build server, though. The compilation goes okay but since the executable is deleted immediately, it just chokes to death on such occasions. But again, it's extremely rare. (And on the build server, a new build run just fixes it again.) – Wim ten Brink Jun 15 '09 at 11:03
5

I've had it happen to me with deployed code. The next update to the scanner solved the problem. Some cretin wrote a virus using the same compiler and the signature was part of the runtime library, not actually in the hostile code.

Loren Pechtel
  • 8,549
  • 3
  • 27
  • 45
  • This is similar to the problem AutoIt often has. I feel your pain, with deployed code it is very difficult to (fully) convince the customer that it is a false positive. – Copas Jun 15 '09 at 00:50
  • It's in-house for me, I'm known to the people running it. – Loren Pechtel Jun 15 '09 at 04:07
4

This is not that uncommon when using non-standard compilers or when doing fancy low-level stuff: I remember creating false positives when I dabbled in OS-development: AntiVir didn't like some of my flat binaries.

Recently, there's been a post about such a problem at the tinyCC mailing list regading AVG.

Christoph
  • 149,808
  • 36
  • 172
  • 230
  • 1
    Actually, I know that I only have to call a single windows API function in a DLL project to trigger alarm bells on almost every virusscanner. (The keyhook API is considered suspicious.) But to get around the false positives, I don't have to change the sourcecode. All I need to do is throw away the DCU files (Delphi Compiled Units) so it will rebuild these again, with different timestamps, thus apparently generating a different signature. – Wim ten Brink Jun 14 '09 at 20:44
3

If you have problems with false positives, there is VirusTotal online service that can help you check your file against number of antivirus engines.
It's free service and currently it can run antivirus check with almost 40 antivirus engines.

zendar
  • 12,766
  • 13
  • 55
  • 75
  • That wouldn't be practical when my AV software reports a virus in some executable that I just compiled. I know it's not a virus, unless I wrote one myself. The problem is that the AV is blocking my compilation process when a false positive is detected. It's annoying. – Wim ten Brink Jul 28 '10 at 06:29
  • I know. VirusTotal is just a place that can tell you which Antivirus engines falsely see your software as virus and you can then contact them and ask them to fix the problem. – zendar Jul 28 '10 at 08:57
  • If you have accurate positives I imagine it's similarly useful, unfortunately. – Casey May 14 '15 at 17:46
3

I've never seen this, having done lots of C++ and .NET development with Visual Studio (from version 1.5 to 2010).

RichieHindle
  • 244,085
  • 44
  • 340
  • 385
  • 12
    The first infection by a C# virus is still in progress, so please give it some time. It needs a 250MB framework and administrator rights to install you know. :-) – Wouter van Nifterick Jun 16 '09 at 02:34
3

I've only seen this happen with assemblers. For example, MASM32 actually warns people that it might trigger virus scanners since the EXEs are so small (and/or some viruses are written in assembly). My McAfee scanner flagged some of the example programs as viruses.

This should only happen for virus scanners that have a "looks suspicious" analysis mode.

Jeff Moser
  • 18,820
  • 6
  • 58
  • 83
3

In some apps, if I use RtlVclOptimize.pas, the Avira antivirus tell that I have created a virus.

Junior-RO
  • 162
  • 1
  • 3
3

plus to what others'v said, modern anti-virus programs rise virus-alert if your programs uses some "suspicious" APIs too ( like URLdownloadFile or other API hooking related ones). if you google "delphi RAT FUD API undetectable" you'll find many interesting topics .

avar
  • 1,170
  • 2
  • 13
  • 28
3

Some antivirus programs even flag a batch file as a virus and can't be convinced that it isn't. Quite annoying, if that file is part of a third party library and the virus warning is triggered every time TortoiseSVN checks it out. I ended up disabling the virus scanner, deleting the file and doing a commit. (Without disabling the scanner, I could not even do that :-( )

dummzeuch
  • 10,406
  • 2
  • 47
  • 146
2

I remember another weird one:

A file was being flagged as suspect. The only thing is the file was an .OBJ! An .EXE that contained the code the .OBJ contained wasn't considered a problem.

Loren Pechtel
  • 8,549
  • 3
  • 27
  • 45
2

A couple of years back, everytime we updated the GNU Linker from mingw sources and started distributing it with our compiler, we got some reports that virusscanners classified ld.exe as virus. (.exes writing .exes ...)

Marco van de Voort
  • 24,435
  • 5
  • 52
  • 86
2

I would not call it a "false positive", because, strictly speaking, it is not false and the antivirus software is not "guilty" of anything in any way.

I am 99% sure, that this is the heuristic analysis acting up (I bet it detects your executable as something along the lines of win32.virus.generic - note the generic, this is a sign, that this is not in its signature db, but rather was detected by the heuristics) and, with being heuristic and all, it does not give you any kind of guarantee, that whatever it finds is malicious, it just kind of makes it known to you, that the executable is suspicious from its point of view.

The easiest solution to this would be just adding an exception for your file by name (it is always the same name, correct?). If you are uncomfortable with this, you should, probably, make your antivirus software prompt you before taking action so you can make it skip your file manually.

In general, I've found coding in windows with antivirus software somewhat irritating (don't do it much nowadays, but still), especially if the said software is in "paranoid mode". Irritating as it is, though, it is unavoidable (IMO).

shylent
  • 9,800
  • 6
  • 34
  • 54
  • Actually, the problem can occur with ANY source that gets compiled in Delphi so the filename varies. Making an exception for the executable would increase the risk in a very small amount, but I'd need to do that to get around a very rare problem. Especially since there's a simple work-around, it's not a real problem. Just annoying when it happens. And as I said, our systems work on financial applications so we're paranoid all the time. ;-) Annoying, but required. – Wim ten Brink Jun 15 '09 at 11:11
  • 8
    How can it not be a false positive? The AV software falsely identifies it as malware. The meaning of "false positive" depends on the result, not whether the process is reasonable or not. Lots of reasonable processes yield false positives. – David Thornley Jun 19 '09 at 14:39
1

It happened to me too. Hooking keyboard will trigger almost any heuristic scanning AV software to report a key logger. There are probably many other system calls which will trigger it too. Solution - try to redesign your code or contact the AV manufacturer to include your software into exception list.

  • Had that problem too. Had a Delphi unit that was used in an executable, and it implemented a keyhook. Then the unit was used in a DLL to run under Outlook and it appeared to be working. But it set off quite a few virusscanners except the Kaspersky scanner that I used back then! Then again, it was even worse, since the DLL installed the keyhook in every process. That's not possible when the API is called from an executable. – Wim ten Brink Jun 16 '09 at 21:19
1

VS Platform toolset 2010 renders my simple program to be detected as virus. Changing the toolset to VS 2013 solves it.

It just creates a HttpWebRequest and writes the result to a file.

Pilso
  • 21
  • 3