masm32 virus found - not false positive?

[abitlater]

Hello,

I get virus alerts for some of the executables in the examples directory of masm32.

I thought this was false positive, so I assembled and linked one of the examples (dragdrop) without touching any source-code in the example, but I looked at it carefully to see if anything looked suspicious - nothing appeared suspicious.  My AVG scanner reported that the new .exe had the same viruses as it did on the original exe provided in the example.

So again, I thought, it must be a false positive... but...

when I change the source in the example (includelib...) to point to the libraries provided by Microsoft in their SDK, and link with those libraries, my resulting exe does *NOT* report a virus.  The exe works fine.

This is a great concern to me, as I have recently had fraudulent activity on a credit card used for online purchases.

The example exe's were not flagged by my previous anti-virus scanner.

Thank you in advance for shedding any light on why the masm32 libraries would or would not be the culprit.

These are the libraries used by the dragdrop example:

Code Select Expand

           
      includelib \MASM32\LIB\gdi32.lib
      includelib \MASM32\LIB\user32.lib
      includelib \MASM32\LIB\kernel32.lib
      includelib \MASM32\LIB\Comctl32.lib
      includelib \MASM32\LIB\comdlg32.lib
      includelib \MASM32\LIB\shell32.lib

[abitlater]

Interesting here...

I made this template, included the lib kernel32.lib from masm32\lib, assembled and linked inside WinAsm, and I get the same virus alert.

If I change 'includelib' to the Microsoft kernel32.lib file, I get no alerts - as before, but now at least I have narrowed it down to be the kernel32.lib file (and potentially others as well).

Here, I'm only using the ExitProcess function

Code Select Expand


include \masm32\include\windows.inc
include \masm32\include\kernel32.inc
includelib \masm32\lib\kernel32.lib

.data

.code
main PROC

    push 0
    call ExitProcess
main EndP
END main

[grofaz]

I noticed that too. I just zapped those files for now but it should certainly be looked into.

[MichaelW]

These days virtually everyone is using virus scanners, and the MASM32 packages have been scanned many, many times. I think it's suspicious that of the entire package only one EXE scans positive. AFAIK kernel32.lib is an import library with no executable code. If your scanner is using heuristics you could try disabling them, or you could submit the suspect file to a service like this one:

http://virusscan.jotti.org/

[abitlater]

These days virtually everyone is using virus scanners, and the MASM32 packages have been scanned many, many times. I think it's suspicious that of the entire package only one EXE scans positive. AFAIK kernel32.lib is an import library with no executable code. If your scanner is using heuristics you could try disabling them, or you could submit the suspect file to a service like this one:

http://virusscan.jotti.org/

Thanks Michael,

I'll look into jotti.org.

Actually, about 4 exe packages scanned positive; I don't remember their names now - I just cleaned them with AVG. 

I'm a noob, but I thought libraries are made of executable versions of the functions they export. 

As I'm playing around with this, it seems the problem may be related more to WinAsm than masm32.....

If I am linking correctly, this could be interesting.  I only get the problem when I assemble and link in WinAsm. (www.winasm.net), which is set up to use the masm32 libraries and include files, as well as masm32's version of the MS link.exe (version 5.something).  WinAsm assembles to /coff format from a menu command, and links from a menu command also.

If I assemble and link from command line using the version 5 link.exe (masm32) or the latest version from MS (version 9 - SDK), all is good - my only question there is...

*Am I really linking with the masm32 kernel32.lib, when I specifiy "C:\masm32\lib\kernel32.lib" on the link command*
- or since the environment variables point a way to MS's SDK version of kernel32.lib, does the linker perhaps use the MS version by default?  If so, then my tests and assumptions are null.  If the masm32 version is used when specified in the link command, then I may have narrowed this down to an "anamoly" or suspicious activity produced when using WinAsm to build.

[abitlater]

disregard last post.

using masm32's version of ML and LINK, outside of WinASM (from the command line) produces the suspicious exe.

uploading to jotti now.

[abitlater]

here is jotti.org report

Code Select Expand


File: test1.exe
Status: INFECTED/MALWARE
MD5: b7c641c038efcce13634e0a137b98f1f
Packers detected: -
Bit9 reports: File not found

Code Select Expand


A-Squared Found nothing
AntiVir Found nothing
ArcaVir Found nothing
Avast    Found nothing
AVG Antivirus Found BackDoor.PoisonIvy.N
BitDefender Found nothing
ClamAV     Found Trojan.Small-4253
CPsecure Found nothing
Dr.Web  Found nothing
F-Prot Antivirus Found nothing
F-Secure Anti-Virus Found nothing
Fortinet Found nothing
Ikarus  Found nothing
Kaspersky Anti-Virus Found nothing
NOD32    Found nothing
Norman Virus Control Found nothing
Panda Antivirus Found nothing
Rising Antivirus Found nothing
Sophos Antivirus Found nothing
VirusBuster Found nothing
VBA32 Found nothing


[abitlater]

Ok, I've ruled out the masm32 version of ML and LINK causing the "anomaly".

It's definitely \masm32\lib\kernel32.lib

Code Select Expand


TITLE test1         (main.asm)
.686P
.MODEL small, stdcall
.stack 200h
option casemap:none

include \masm32\include\windows.inc
include \masm32\include\kernel32.inc
includelib \masm32\lib\kernel32.lib

.data

.code
main PROC

    push 0
    call ExitProcess
main EndP
END main

replace the "Microsoft SDKs\Windows\v6.0A\Lib\Kernel32.Lib" with \masm32\lib\kernel32.lib and it produces an exe with a virus, according to AVG and ClamAV

Code Select Expand


c:\masm32\bin\ml.exe /c  /coff /nologo /Fo"c:\winasm\projects\dos\test1\main.obj" /W3 /Zi "c:\winasm\projects\dos\test1\main.asm"

c:\masm32\bin\link.exe /OUT:"c:\winasm\projects\dos\test1\test1.exe" /INCREMENTAL:NO /SUBSYSTEM:CONSOLE /MACHINE:X86 "C:\Program Files\Microsoft SDKs\Windows\v6.0A\Lib\Kernel32.Lib" "c:\winasm\projects\dos\test1\main.obj"


[hutch--]

abitlater,

The problem with this is twofold, kernel32.lib is purely an import library, it has no runtime code and with the masm32 project it is build from a text file when you install masm32.

The false positive with a couple of the lower end AV scanners is that they assume that a short exe like the above examples have something wrong with them where in fact it is valid win32 code.

[GregL]

I'm using the latest version of AVG Free with the latest virus definitions and MASM32 version 10 Beta. AVG finds nothing if I scan the \masm32 directory.

[abitlater]

abitlater,

The problem with this is twofold, kernel32.lib is purely an import library, it has no runtime code and with the masm32 project it is build from a text file when you install masm32.

The false positive with a couple of the lower end AV scanners is that they assume that a short exe like the above examples have something wrong with them where in fact it is valid win32 code.

That's very interesting, because when I assemble and link with the latest ML and LINK from MS, the exe is about 33% larger and AVG Free doesn't detect anything in that case. 

[Mark Jones]

So... since this "false positive" thing has popped up so many times in the past, and continues to appear today -- even though there has never been a virus in any legitimate distribution of the MASM32 project -- perhaps a "bloatware" library should be included to increase the size of the executables and thus eliminate the "false positives?" Lol! :U

Here's what I do when presented with a "suspicious" file:

1. Install OllyDbg from http://www.ollydbg.de/
2. Save this text to a .reg file and run it (allows right-clicking the executable to debug it, make a similar one for .dlls also)

Code Select Expand

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\exefile\shell\Debug with OllyDbg]

[HKEY_CLASSES_ROOT\exefile\shell\Debug with OllyDbg\command]
@="c:\\path to your ollydbg folder\\ollydbg.exe \"%1\" %*"
3. Right-click the "suspicious" program, choose "Debug with OllyDbg" and see what's in it. Look at the data - any code in there? Look at the code -- any data in there? Is it encrypted? Compressed? Does it read some other file? Download something? Does it otherwise seem legimate?

For a messagebox program, it should call a messagebox. But a messagebox program that downloads a file and uncompresses it from an undocumented ordinal in ntdll.dll... well that's bad news.

Yes, heuristic scanners DO make mistakes -- and while hueristics might improve detections theoretically, they seem to cause far more false positives than anything else. For that reason, I leave heuristic scanning off.

[raymond]

As a complement to those false positives, here's another good one. I've written numerous short programs for solving math problems. I recently had my computer scanned by HouseCall from TrendMicro and several of those short programs were reported as being infected!!! :dazzled: When I investigated which ones were being targeted, ALL of them contained floating point code. Makes you wonder how those heuristics work. :boohoo:

[Mark Jones]

It's unfortunate that A/V products can be wrong, especially here, as this places great suspicion on the validity of "assembly programming" and MASM32 in particular. A/V designers are faced with an ever-growing pile of malicious code to weed-out, and I think that perhaps it is just easier for them to say "ok, any file that looks different than MSVC7+ is suspect," instead of adding even more entries to their already burgeoning virus lists.

I re-read this thread, and noticed that it never really seemed to have a solid conclusion. So, to anyone who may still end up here and think there is a chance the MASM32 distributable package contains viruses -- that is complete hogwash. MASM32 has not contained one malicious bit of code for as long as any of us have known it. Furthermore, the issue with Kernel32.lib producing a "virus infected file" is a false-positive, and must be, because Kernel32.lib only contains linker information used in linking the application to Kernel32.dll -- the two executables in question thus being identical in code -- and only differ in IMPORT structure. So AVG is falsing on the technical details of an IMPORT to Kernel32.dll, not on the actual code. While I haven't the patience to determine exactly why AVG thinks this is a problem, it is probably due to their design team building their scanner around the executables produced by more recent tools such as MSVC9 (which also explains why it doesn't produce a false-positive on the file with the extra "bloat.") If this logic is true, then AVG is not building their scanner to meet the exact PE (portable executable) file specification. (As Hutch said earlier, but not in so many words.) :wink

While it is a good policy to carefully scan any executable file entering your PC, please remember that A/V products are not perfect, and (increasingly) can report false positives. If ever in doubt concerning any of the MASM32 files, come here and ask.

That said, one last order of business. If you would like to run an executable but think it may contain questionable code, consider running it in a Sandboxie. This is a tiny "sandbox" environment (420k download) which will let an application run, however prevent it from modifying your hard disk. This is great for running all the little "test apps" which can be found here in the forums. If one of those did contain a virus, and it was ran in the sandbox, then the virus would be unable to infect the computer. Once a program has been deemed ok (i.e. it does what it says it does in the sandbox), then you can run it normally (i.e., outside of the sandbox, normally.) Full details at that website.

[lingo]

"Here's what I do when presented with a "suspicious" file:
1. Install OllyDbg from http://www.ollydbg.de/
2. Save this text to a .reg file and run it (allows right-clicking the executable to debug it, make a similar one for .dlls also)
....
...
3. Right-click the "suspicious" program, choose "Debug with OllyDbg" and see what's in it. Look at the data - any code in there? Look at the code -- any data in there? Is it encrypted? Compressed? Does it read some other file? Download something? Does it otherwise seem legimate?"

I agree, if you have enough time about it... :lol
I just have no time to do RE, hence for me is easier to delete the "suspicious" file and continue with next example...
To be honest I prefer the PBrennick's method "Because I do not like positives or false positives because it drives potential users away,.." (http://www.masm32.com/board/index.php?topic=9668.0)
Why? Because it works!  :wink
After 1 day the lame author of the "suspicious" example reported: "...the new Extractor version, the case is over. No any false positive." (http://www.masm32.com/board/index.php?topic=9668.0)

Code Select Expand


A-Squared Found nothing
AntiVir Found nothing
ArcaVir Found nothing
Avast    Found nothing
AVG Antivirus Found BackDoor.PoisonIvy.N
BitDefender Found nothing
ClamAV     Found Trojan.Small-4253
CPsecure Found nothing
Dr.Web  Found nothing
F-Prot Antivirus Found nothing
F-Secure Anti-Virus Found nothing
Fortinet Found nothing
Ikarus  Found nothing
Kaspersky Anti-Virus Found nothing
NOD32    Found nothing
Norman Virus Control Found nothing
Panda Antivirus Found nothing
Rising Antivirus Found nothing
Sophos Antivirus Found nothing
VirusBuster Found nothing
VBA32 Found nothing

It is great waste of time for the users to mount all those scanners, test and RE the same   
"suspicious" examples, again and again... It should be author's obligation! :wink