Couple of times I am now being alerted by SystemSafety Monitor that my Comodo Firewall is trying to load the driver “mchlnjDrv.sys”. I have searched this forum and there is nothing mentioned about this.
I have been using Comodo for little over a week and all necessary popups from Comodo had previously been enabled in System Safety Monitor software. However since yesterday I started getting the message that cmdagent wants to lead the driver “mchlnjDrv.sys”. I wonder why it is asking me now. My question is that is there something wrong with Comodo and should this driver have been loaded from Day 1 or is it a bad file that I have gotten while surfing the internet.
On searching Google, the file in question is being referred to a Trojan, but my TH scan does not confirm this. I refer to the post:
Can anyone throw some light on this… I have also posted this in Wilders security. To view the screenshot please see my post:
I did a Google search on this as well & like you, got hits on this being a Trojan (based HijackThis logs in German forums… poorly translated by Google).
CPF could be trying to examine it or block it rather than load it. Anything in CPFs log relating to the SSM alert time?
BTW Please excuse the silly question. I assumed you’ve searched your system for mchlnjDrv.sys?
I checked CPF’s log and there is no entry relating to this driver or about SSM intercepting the load of this driver. CPF is still functioning even with this driver blocked from loading.
In answer to your question about the file existing on my system. Thats the weird part. Just like others posted in Google, I too cannot find the actual file (yes I enabled view hidden folders option).
So I really don’t know where this is springing up from.
Some quotes from other forums talking about this driver:
What is mchlnjDrv? | Wilders Security Forums
“Unhackme informing me of a rootkit service named mchlnjDrv”
Check the Tab “Advanced” on the webpage. It says "Troj/Feutel-AS also registers <Windows temp folder>\mc22.tmp file as a new system driver service named “mchlnjDrv”, with a display name of “mchlnjDrv” and a startup type of automatic, so that it is started automatically during system startup. Registry entries are created under:
- Many forums talking about it, see mchlnjDrv - Google Search
I did read that others too couldn’t locate this file. I don’t know how it then magically appears. I guess if it is a malware then this wouldn’t surprise me because its meant to be undetected. But from a reputed and trusted firewall that is trying to load it?
To be fair, you don’t know what CPF intents were towards mchlnjDrv.sys… since you blocked it with SSM. The only guy that can really say for sure is Egemen (the coder). But, I still suspect that CPF was trying to examine at the driver or something… And I really doubt that cmdagent would allow any old driver to be forced upon it.
Doesn’t SSM generate a more detailed log of the event that you could post?
Edit: SysInternals root kit revealer?
Unfortunately I disabled SSM logging, so there won’t be anything there that I can provide. I will run RootKit revealer and let you know of the logs.
I understand that I am still learning about the way that Comodo brings up messages. So i don’t know at this stage what exactly Comodo was trying to do with the driver file.
But to a newbie when I get a message that “cmdagent.exe is trying to load the driver…”, I cannot understand why Comodo needs to load that driver file if it doesn’t belong to it in the first place! Why hit a snake and see if its poisonous? I am not saying Comodo is the culprit here, just trying to find answers. I have begun to like Comodo and hence trying to find a solution rather than just uninstall Comodo based on some suspicion that I gathered.
It could quite possibly be a trojan/malware, that tried to get into the memory space of CPF and connect to the internet.
mchlnjDrv.sys is the part of the api hooking SDK CPF uses to inject its DLL appguard.dll to other applications.
It is loaded and extracted on demand by cmdagent.exe. So it is a safe driver.
It is used by many other security software which perform user space api hooking too. So you may also see it reported with other programs.
It is not quite easy to infect CFW processes. CFW is fault tolerant. So blocking it will cause CFW to find another way. But you should not block it.
If you update your post in wilders according to my previous reply, guys there could also understand the situation.
Thanks for the info Egemen. Is this driver just on XP?
Thank you Egemen! Now I feel assured that it wasn’t some file I picked up while surfing. Have enabled it now.
Also updated my posting at Wilders so that others who come across such a screenshot are aware of what to do.
I just wanted to re-enforce a point Egemen made. It is very important that you tell SSM to implicitly trust CFW & programs like CFW. IDS systems & AntiVirus programs. And also get those programs to implicitly trust each other (including telling CFW to implicitly trust SSM). Otherwise, you are seriously increasing the risk of a conflict between one or more of these applications. Of course, there’s also the risk that your security applications might drive you insane and/or paranoid with impressive amounts of security alerts.
Kail, I agree with you. Actually I thought I had configured SSM to trust CFW. I got a lot of prompts from SSM on the first day I installed Comodo to which I obviously replied YES and also to “remember my YES” in furture. But since over a week has passed, and this was the first time (actually yesterday was the first time) I got the message regarding mchlnjDrv.sys, I was surprised. I haven’t received any other prompt so far (since installation) in relation to Comodo and I had also earlier tested the effectiveness of the firewall with few leak tests. All was working fine. Anyway its good to see that the combo protection is working (SSM and CPF) (:CLP)
Thanks for your help Kail. Got to go now…heading to the beach …
Nope. It is both for Windows 2000 and XP.