MchInjDrv

Hi Pilli.....so you found that it needs that driver for sure......did you test and all that ....... still have not heard a word from them and i think that stinks ( hoping 'stinks' is ok with everyone )....

 

Hi Rainwalker, I shall uninstall SpySweeper and reinstall under Process Guard 3 to see if I can reproduce what I saw earlier but it will not be until tomorrow.

Shame about their support, I can imagine the stuff you think they smell of

Please report back if they condescend to convey anything useful to you.

Cheers. Pilli

 

Hi Rainwalker and Pilli

I installed PG 3 yesterday and Spy Sweeper wants to install MchInjDrv just as in PG 2, i have allowed this, however Spy Sweeper also wants "allow terminating" on C:\windows\system32\smss.exe, should i allow this or not

Stinks is ok with me, because you're so right about webroot's support, i like some of their products though (Spy Sweeper and Window Washer), hopefully they will start improving in this area.

Regards

 

Hi again Rainwalker .

Just tested again under Process Guard 3 and yes, it would seem that it needs the driver. It also tries to Modify any process that is running at the time. Please see screenshot of Alert Log.
It only tried to do install the mchInjDrv after being installed and run for the first time...haven't seen it again after that. Also, after the initial attempt at Modify on any running processes, if any new processes are then run thereafter it will try to Modify them also.

Hope that helps,
Jade.

 

Hi Pilli......just got home a bit ago and turned on the puter....yours' was the first post i read....after another day in the pits i sure needed the laugh you gave me...thanks

You KNOW i'll report anything i hear from Webwhatever.
@ Don....... thanks for getting back.... sorry i can't recommend anything .....i ain't using it till i learn more for sure stuff
@ Jade.......Hmmmmmmmmmmm

 

This is part of usermode hooking, it will need the injection driver to put a DLL inside all processes..

 

If you look in the registry (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Service\mchInjDrv) would you be able to post all the contents of that reg folder.

 

Just for info, the same thing also happens on a².

On installing PG3 it informed me that a²guard.exe was trying to install a driver/service, mchInjDrv. I allowed it and am reasonably happy about it, having followed this thread.

It also wanted the right to terminate smss.exe. If I remove the termination right it just asks again. As I accept that a² is one of my trusted apps (or it wouldn't be on my PC) I'll leave it at that. It has obviously been like that since I installed a² and no harm has been done.

 

Can anyone speak to why this driver is suddenly showing up ......it is also now used with Trojan Hunter in their latest version.

 

RainWalker, My guess is that the as the Madshi stuff is already made, that it saves developers work and it may be a case that the developers do not necessarily have the skills to create kernel level drivers or hooks for themselves - Which I find kinda worrying though I do like SpySweeper.

HTH Pilli

 

MchInjDrv = Mad code hook injection driver.

It is the temporary driver used (disappears shortly after) in this case by spysweeper.exe to inject a .dll into all running processes therefore creating a case of usermode hooking. It is most probably used for SpySweepers various shields (protection of running processes etc?).

As Gavin said earlier in the thread, if you trust the software that is using it....Allow it


Hope my explanation makes sense ,
Jade.

 

Hi!

I don't know a whole lot about PG yet, but, my isp was downloading SS with their program. It wanted access to everything all the time, it drove me and McAfee (the security suite) mad, trying to change everything. (By then I wished the isp would just stick to connecting and e-mail.)

It was also a pain to get off my computer, little files attached to it would pop up in strange places??

I had some other problems, so just put in a new hard drive and started over without letting it get its' "hooks" in my computer again.

Hope you all get this mystery solved?!? It always seemed overly aggressive to the "home" it was in, instead of looking out the door, so to speak!

Marja

 

Yes Jade, but i'm i wrong in wondering about a serious back door potential

 

Its unlikely but not impossible. Rather doubtful is where I would put it, but you have to trust the writer of the library (Madshi) these programs are using. He does sell the libraries for use in programs, so he would have a lot to lose if caught putting backdoors in the code.

Using products which use this library imply this trust. There really isn't much you can do, unless you expect those programmers to go through EVERY line of code in the library, understand it, and be sure theres no backdoor. Thats not going to happen - if they could do that, they would write their own drivers in C instead..

 

Yes, it does beg the question - why DONT they develop their own job-specific drivers? Lets not beat around the bush, we are afterall talking about security here. So why use 3rd-party 'generic' drivers which they have absolutely no control over? If for example a bug or exploit was ever found (very possible due to the complexity of driver code) they'd be in a lot of trouble and have no capability to fix the problem - a serious problem when we're talking security, so clearly it's convenience and not security that's the main priority of programmers who make use of libraries like this, which is disappointing considering many programmers are using it to create security-related software.

 

Thanks Wayne and Gavin . Certainly is food for thought regarding the trust factor involved in situations such as this.

Best regards,
Jade.

 

Simple. Time to market + headcount.

I, too, work in the Software industry and, over the course of the last 3 years, my company has, for industry-wide financial reasons, reduced its overall head-count by 40%, R&D included. By doing this, the company has survived, but lots haven't.

However, the required time to market for new products has, if anything, shortened and the rate of new product requirements has increased. As a result, there is a staggering amount of pressure to use third-party code/libraries where they are available (so long as they're stable and reliable). Our company is not going to make money (and that's what it's all about) by reinventing the wheel, but by producing products that nobody else has.

Not ideal, I readily admit, but it is a fact of life in the real world.

 

Jade,
Yeap. Trusting a program is only one part of the programs security, its developers should be trustworthy too. Like I said, we're talking security here afterall.

 

ctjc,
3rd-party components are great and we use them ourselves for the reasons you mentioned - but only when security isn't an issue.

Because the driver for Process Guard is security-related it's paramount for you as a customer and us as the developer that we have 100% control over the source code, including the R&D behind it. Anything less would be unacceptable for the customer due to possible compromises in security and inability for a fix to be produced.

Regards,
Wayne

 

Agreed, 100%

If your business is security (ours isn't), then yes, you have to be secure at all levels in the software stack.

BTW, great work in PG3. Working like a charm here. A few problems, but a great Beta (so far )

 

Thanks all for your input.
@ Wayne.....you have hit the nail on the head........all that you said is what has been bothering me all along......wanted to wait for someone else to go there
At the end of the day in many ways it's like a dart game

 

UPDATE:
Well, for what it's worth, here it is:

'I apologize for the confusion. We are using a driver as part of the Windows Installation Shield. If you were to turn off the shield. The driver should stop running.'

I feel sooo much better now

 

Glad you eventually got an answer Rainwalker.
You can sleep nights now

Cheers. Pilli

 

Righto

 

That kind of makes me laugh. "Woah we just checked and lo and behold there is a driver, thanks for telling us Rainwalker" .