Hmm. I found that Windows can not load the DLL put in the AppInit_DLLs key if there are spaces in the path. Maybe I need to put the monitor dll into system32 folder.


Yes, now ClamMon will not scan files opened in some program. If you will rename file with that signature to .exe and launch it, ClamMon will detect it.


I think that I can detect most script viruses if I will check not only the program being launched, but it's parameters too. This will get about VBScript, Windows Batch because every time the virus is launched the new interpreter is launched too, but will fail on exploits (Word, JPEG) if the file is opened from launched app.
This will detect your signatures too if opened in Notepad.
The thing about category for scripts is nice - but do I need to update libclamav or not to make them work?

I think I will soon release next version of ClamMon.

I would leave the monitor dll where it is now in c:\clammon--all your files are easy to find--unlike with some AVs.

Yes--it seems that ClamMon didn't find my signatures in text files because they are not executables--it only kicks in when an API is invoked.

If ClamMon is not already using the other Clam signature categories for something, I don't think you need to bother with the new signature category for scripts. Anyway, it will not be used until version .93, which is in release candidate stage now. In version .93, they redesigned the scanning logic. Probably the normal Clam scanning code will handle it, and the users will not notice anything.

I wouldn't change ClamMon very often--keep it stable and give it a good test. Your program works, and that puts you ahead of the ClamWin developers' real-time version. If they continue to have development problems with their real-time scanner, ClamMon would make a good substitute--especially if it provides some function(s) that Clam doesn't do. You might want to tie ClamMon development to ClamWin development--just come out with a new ClamMon version after each new ClamWin version comes out.

As for your API hooks being too easy to "knock out," I believe that some anti-rootkits and AVs use random service names to prevent that. I think you could do that also.

My suggestions so far:
1. You don't need the popup notices if a file is clean--don't scare the users.
2. After ClamMon finds EICAR/malware, and you select Delete, it seems to delete the file and then gives a message "can't access the device, path, or file or you do not have appropriate permission to access the item." What is that--and do you need it? Maybe it is in a temp directory somewhere?
3. ClamWin has some filters that the user can set to exclude certain files. ClamWin doesn't use them for single file scans, and I see that ClamMon does not use them either. Sherpya has said that he intends to include code in ClamWin to use the filters in memory scans in the future, but that's not available yet.
4. You should consider ClamMon for Vista also. Many people will probably start using it soon. ClamWin version .92 is for Vista, and I don't think they registered anything. Maybe they can give you some advice.

Regards,

So I will restrict installer to paths without spaces only. It's good enough.


Where I can see the changes in API?


The window is displayed by Explorer - I return the status "cannot access file" to it. I think I need to return "file not found" in case virus is deleted.


I don't think I need to integrate any ClamWin filters unless I want to check each opened file.


The 'root of evil' is Vista's paranoidal politic. It will not inject my DLL unless it's signed with some certificate it trust. Maybe I can sign it with self-signed certificate and add certificate to trusted in certificate store.

Hello WhiteQuark:

ClamMon works okay with the Version .93 Release Candidate of ClamWin. I think you need to contact alch@users.sourceforge.net. He can tell you how to get source code, how to join the ClamWin beta forum, and what they did to get ClamWin ready for Vista. The ClamWin developers are interested in your ClamMon.

Lately when booting up I have been getting that DOS style screen I told you about. It stays there maybe 20 seconds or so, and I get a balloon tip that says "cannot initiate. Second version of ClamMon is launched." Then they go away and the normal gray ClamMon icon goes in the system tray. ClamMon seems to work fine.

Finally, don't work too hard! It's easy to get "burned out" with Open Source software.

Regards,

Hello WhiteQuark:

More comments:
ClamMon can't detect EICAR when zipped - you have to unzip it and then run the file to detect it, but it is unable to delete the file after it detects it. You will probably need to develop code to delete the entire zip file if infected--deleting from within the zip file might be hard to code, and there are several types of compressed/zipped files. You should also "hide" the remark about "not being able to access the file" when it appears after deletion.

ClamMon can't detect EICAR in an EICAR.txt file, but it can if you rename the file to .com or .exe and then your API monitor kicks in. If a file is "suspicious," you could rename some the extension .com or .exe when operating to see if that hits your API monitor. A "suspicious" file might have a double extensions or be a .txt or .dat file in a Windows or System directory.

If you can enable script monitoring of the Windows Scripting Host, that would be a good enhancement, and I think that many ClamWin users would be interested in ClamMon then. ClamMon has the potential to give ClamWin some additional functionality that it will probably never have with Clam--unless Clam quitis thinking that Clam AV is only for use by email gateways.

Regards,

@whitequark

Have you had any updates since the end of March?

ClamAV seems to have changed their signature database location and type. There are only two databases--main and daily. They are now called main.cld and daily.cld, and they are both located in C:\Documents and Settings\All Users\.clamwin\db. There is no separate folder for daily updates. I think this has affected ClamMon because I am now seeing the quick DOS-style message again when I click on an infected file, and nothing else happens. This is exactly what happened when I installed ClamMon in the Program directory instead of using the default C:\ClamMon directory. I'm still using ClamMon with the ClamWin version .93 release candidate, so I am not sure if this pertains just to version .93 or to other versions as well. I suspect it pertains to ALL versions.

WhiteQuark might need to change the ClamMon program because of this change.

Regards.

Will you please upload the file to a filehosting website which is in english?
I can't understand the language in ifolder.ru

Heads Up for Whitequark:

It looks like there is no need to change ClamMon for the ClamWin 0.93 release candidate signature database changes until ClamWin 0.93 is released (probably in a month or two at least). The new database configuration is only for version 0.93, and ClamMon still works fine with version .92 and prior. When version 0.93 is released, however, ClamMon will not work correctly as it now is because version 0.93 uses only two database files--main.cld and daily.cld, so ClamMon will need to be changed to use those signatures if ClamWin version 0.93 is installed.

Regards,

i have tested clammon and found this:
1. looks like clammon can not protect from *.pif viruses, which is also executable,
2. also there are problems when starting program over the smb, e.g.: "\\192.168.0.6\shared docs\games.exe"
3. there is also problems with reinstalling clammon, due to file system driver (or something) crash after restart (which is curable by removing c:\clammon, and removing all clammon keys from HKLM\System)
4. clammon have problems when checking large self extracting archives

so if clammon is really want to be cool on windows - there is no other way except creating on access (not on CreateProcess) monitor

ClamMon IS working with the new Clamwin version 0.93. As AGUtilities said, it uses ClamWin to scan a file only when you run/execute a program/file that uses the Windows CreatProcess API--NOT when the file is put on your computer. If a program/file doesn't use those processes ClamMon monitors, it doesn't work. It does offer limited "real-time" protection, but this is protection that ClamWin does not have by itself at present.

In my opinion, ClamMon can offer adequate protection for a computer when used with Threatfire or WinPatrol and if you schedule several automatic daily ClamWin scans of your computer. I also believe that it can be improved to protect in areas such as the browser stream that most AVs don't yet do.

Regards,

Final Verdict as of May 3, 2008:

ClamMon seems to have been working okay--no detections yet, but for a final test, I turned a particular nasty virus loose on my virtual machine yesterday. It was a trojan dropper which installed Srizbi-27 on the machine. Both pieces of malware are in Clam's signature database, however, ClamMon did not detect anything when I clicked the trojan dropper .exe file or when the Srizbi file was dropped. There were 12 pages of registry changes and several fies changed or installed--including a rootkit. ClamMon is not quite ready for dependable use.

Regards,

Yes, I know that it (for some reason) does not detect some trojans. Another example is Virus.Win32.Sality.*. I launched an infected .exe on my machine, and ClamMon has detected the intrusion only after many files was infected with that. An user-mode monitor is a bad choice for antivirus. I tried to write a kernel-mode monitor, but (at least now) it is too complicated for me.
The development of ClamMon is stopped now. There are many reasons; another is that I am using only Ubuntu on my computers. :)

Well, thanks for giving it a good try. You put in some good work, and it worked in some situations. I think it could still have some benefit if you used it to only look at a few things. If you'd like to continue helping ClamWin on Version 1.0, you could contact Alch.

I think Ubuntu has some good potential--I'd like to see it replace Windows, but it has a ways to go, and I frequently see that it has lots of exploits (per Secunia).

Regards,

Does it have problems with detections because the .EXE's are packed with UPX perhaps?