Are there valid technical reasons for using RootKits?

What I would like to understand is there ever a valid technical reason for using RootKits, hooks, and / or hidden processes?

I submitted a report from RKU to their forum and was told that all was well since the RKs and hooks were ALL related to my security software.

Please lets not start again on RKU, I'm not complaining about their findings!

Thing that puzzles me is one package I use BitDefender, uses them and others did not. Why is this? Do vendors try to protect their property with RK's?

I must be a worrier at heart but does anybody have an explanation to these questions?
__________________

 

Security software needs access to kernel to protect the system.

 

Thanks lucas.

Thing is some of my security software seemed NOT to get reported in the RKU reports. Have you actually done yours to see if they all do it? I'm going to redo mine and look again.

This is not a challenge question just a work in progress I'm just trying to figure this out.

 

Have played with several RK detectors. The results varied dramatically. Where several showed none, one showed many. All were related to my security apps. in general with ZA Pro being the leader of the pack by far. Do not know if the ones that showed none was by design or just missed them. Or if the one that showed many were in affect showing FPs or just showing everything so the User could decide. Sorry, do not remember which one showed and which ones did not.

 

employing deductive reasoning and dredging what Ive read from several sources
I come to 4 classifications\motivations of rootkits

1. Otherwise legitimate applications hiding from end users
(DRM particularly)

2. Security applications hiding from malware to prevent subversion

3. Applications hiding from the system to fool it
(Daemon Tools)

4. Malware

of course as demonstrated by the Sony BMG fiasco a poorly employed rootkit if found out
poses a security threat, what precautions\exclusions might be employed by security aps I dont know
reading through Kernel Malware: The Attack from Within I suspect that if the malware is at a low enough level whatever precautions are employed would not be sufficient.

 

Thanks guys. The issue then is to find and eliminate ICE's class 3 and 4. BTW what are Dameon Tools? Reminds me of a Gregory Peck movie some years back! I like that deductive reasoning Ice!

ThunderZ: I've got ZA Pro as you can see so it must fall into class 2 which is a good thing!

If say SS has 0 rk's that may mean it is open to tampering by the bad guys?

 

Virtual Optical Drive
http://en.wikipedia.org/wiki/DAEMON_Tools
http://en.wikipedia.org/wiki/Alcohol_120%

I use Daemon Tools to mount ISO's
Have several of the older adware free versions but you can also opt out of the adware currently as well

http://www.daemon-tools.cc/dtcc/showthread.php?t=9581

you can also get RK hits with trialware
http://forum.sysinternals.com/forum_posts.asp?TID=5903&KW=Defrag

those are my two legitimate returns in most RK detectors

 

That is what I am figuring\counting on.

With all the acronyms flying around the Forum I am drawing a blank on SS. However whether it is open to easier tampering by the bad guys would probably be dependent on several things. Also, SS(?) may not require rootkits, or have them written into the code in order to perform it`s functions.

 

SS= Spysweeper (webroot)

You are not alone on the short forms, we may need a forum dictionary!

 

Should have known that one. Have thought many times of making a Glossary of sorts with them all in it. Then perhaps it could be made into a sticky. I know it would be a huge help to myself at least.

 

I think(?) that at the kernel level we are talking about it may not be fair to describe what a security ap does as a rootkit, at least with the definition most would recognize, maybe a better description is a kernel level driver operating on ring0 (full access), what its doing may in fact be hidden from the end user and malware but then alot of system functions are as well. In that light a malware kernel mode rootkit could be described as a rogue driver that "hides" itself and or other nefarious code.

I guess Im saying not only do we need a lexicon of acronyms for the forum
but a glossary of system vs malware definitions.


again from Kernel Malware: The Attack from Within

thus the definition of a rootkit is largely its malicious intent as well as its hidden actions
since most security at least has one process the end user can observe
I gather the real danger of "legitimate" rootkits is that they can be subverted to malicious purposes

we may find that the word rootkit needs further refining to reflect what level of privilege its working from. RK2 RK1 RK0. Im still digesting that paper