Registry Monitor comparison

I've seeZA ask me if I want program A to use program B. If I say "YES", and check the remember box, it places it in a higher "Trust" level. That's about it.

MJRW monitoring the registry. Not sure what you mean by .ini file monitoring.

 

ini file monitoring means periodically checking ini files for changes. MJRW does that on desktop.ini files in the startup and tasks directories, and in %windir% it checks win.ini, wininit.ini, and system.ini (although you could add others if you so desired). ini entries in the registry itself are also checked by these keys :-

hkey_lmus\software\microsoft\windows nt\currentversion\inifilemapping
hkey_lmus\software\microsoft\windows nt\currentversion\inifilemapping\system.ini
hkey_lmus\software\microsoft\windows nt\currentversion\inifilemapping\system.ini\boot
hkey_lmus\software\microsoft\windows nt\currentversion\inifilemapping\system.ini\boot\shell
hkey_lmus\software\microsoft\windows nt\currentversion\inifilemapping\win.ini
hkey_lmus\software\microsoft\windows nt\currentversion\inifilemapping\win.ini\load
hkey_lmus\software\microsoft\windows nt\currentversion\inifilemapping\win.ini\run

 

Thanks, Graphic.

I guess that means I have .ini file monitoring covered also.

 

Is there a program that protects the registry and doesn't give popups when I try to do something. I guess I am looking for a program smart enough to know the difference between a safe change or bad change.

 

I'm pretty sure that's a huge no

the definition of "bad" varies from one person to another, you'll never be able to write a program that knows exactly what's "bad" for you.. you can only come close by answering popus

lets say you install a program that tries to change the registry... might be a legit program or it might be spyware, but there's no way for a reg monitor to know something like that for sure so it has to ask you

 

I believe that this is impossible. The same change can be safe or unsafe, depending on
1) whether the file doing the change is malware, and
2) whether the file at the autostarting location is malware

As an example for 1):
You can deliberately disable the windows firewall or enable directory shares from any administration software, or a malware can do the same. The first case should be allowed the second should be blocked.

As an example for 2):
During installation of a non-malware application autostart entry can be inserted, during (unwanted, hidden) installation of malware new autostart entries should be blocked.

It is clear that an automated software can not differentiate between these seemingly identical safe and unsafe changes. To do this it would need 100% success in identifying malware files. Malware file identification is already done quite well by AV/AT. Registry monitor is exactly for those cases where these tools fail to identify the malware. It would not be fair to expect registry monitor to identify a malware which even the AV/AT can not. There is only one entity that could do better in identifying malware: the user. That is why the popups (malware identification queries) are presented to her - the first and last line of defense.

Expect an update to the reg key list in a few days - a few more keys were found to be exploited.
best regards,
-hojtsy-

 

... Hojtsy,

Have you considered adding the Pgm "Online Armor" to the Registry Monitor comparsion chart

....This pgm sounds like another worthy one, based on recent threads at wilders, as well as the descripition on the "Online Armor "web site describing its features.

 

Do all of these just scan the registry periodically and announce changes? Are there any that can actually put the change "on hold" before it is made, rather than give you the option afterwards to reverse the change?

 

Yes, RD:-

http://www.ghostsecurity.com/index.php?page=regdefend

 

MJRegistryWatcher (RW) holds back a registry change from being made until AFTER you say the change is okay. RW *polls* for changes at intervals that you specify. If you have it set to poll at very short intervals -- say, ½ second -- then it's extremely unlikely (but not impossible) for a registry change to happen before RW stops it.

RegDefender (the one linked by TopperID in preceding comment) sets *hooks* so that it is arguably "impossible" for a registry change to occur without it being blocked, pending your say-so.

RW is free HERE.

RegDefender is NOT free. That is (as I recall) RD has a trial period. When the trial period ends, you must pay to license the full version, but a curtailed version remains operable. Perhaps TopperID will elaborate on this, or correct me if I mis-spoke.

 

Thanks, bellgamin. I'm currently using MJ RW (which looks to be by far the most complete on the list), but RegDefend sounds like what I'm looking for.

Yes, I would also be interested in hearing more about what functionality remains after the trial period on RegDefend.

Also, I wonder if it's feasible to simply lock access for writing to the registry, and then unlock it when you know you're doing something that needs to make changes to the registry? Or would this cause so many errors that it wouldn't be practical?

 

Basically it will either automatically block, or automatically allow, it will never prompt.

I suppose it would depend hugely on what keys you are trying to protect.

 

Thanks. Do you know if it will still protect user configurable keys after the trial period, or if it will revert to some sort of default list at that point?

I was thinking along the lines of maybe a simple application not listed here or even just some sort of setting/tweak that would categorically deny write access to all of the registry. Sorry, I guess I wasn't too clear; it was a separate line of thought. Protecting specific keys would be great too, but I assume anything like that would have been on the list already.

 

NoHolyGrail,
The "Limited Free Version" of Regdefend is actually quite functional
RegDefend will still prompt (see pic), you just cannot click on "Block" in the limited free version
You can however click on "Kill Process" and that blocks the change and kills the process
In the free version you can use "Allow" and "always perform the action" to remember the allow for that application so that aspect is fully functional

Here is the log entry I received from RegDefend when I clicked on kill process for that alert (because I wouldn't actually want anything changing my update site from microsoft.com to anywhere else)

Code:

04:23:41 05 Jan 2006 | RegDefend | Blocked set value by regedit.exe | HKLM\Software\Microsoft\Windows\Currentversion\Windowsupdate\Auto update | odffileurl |

You can still configure the rules to cover any registry keys that you like, although you would be suprised at how many writes happen as part of normal windows operations that you wouldn't actually want to block. So in order to achieve something like what you are suggesting it wouldn't quite be a blanket write denial as there are some areas that it is not unreasonable (and actually quite important) to allow write access for key system processes

If you want to go down this path you need to be quite careful and know how to recover if Windows gets itself into a state that it cannot recover from by itself. This sort of experimentation is best not done on a machine you care about too much unless you have backups

 

Yes you can protect against configured Keys with the free version of RD; but you must set them to 'Block' and you will not get a prompt, which means looking in the logs to see if any events occur. The free RD is very functional but not as convenient to use.

Yes, you can do that with RD, but it is not really practical to block all Reg activity. Just try it and see what happens!

 

I was pipped to the post there!

But to clarify - with RD free you can set to Allow or Block. If you set to allow you will get a prompt which is informational and will not allow you to block. For that reason, to protect Keys you should set them to Block, in which case you will not be able to create exceptions through a prompt and must therefore rely on the logs to manually do it.

 

Topper,
That is why I included a picture to 'clarify' exactly that, because I have seen a few people with that same misunderstanding

You *can* block by killing the process (or just the thread in some cases), I included the log entry (above) to illustrate exactly that

 

NoHolyGrail,
Protecting the entire registry from being changed at all, unless you "open the door", is an unfeasible idea. If you watch what XP SP2 does (using RegMon or similar utility), you'll see that Registry writes occur all the time. There are watchdog packet counters, timers, performance stats, and a whole raft of other activities that routinely write to the registry. At boot up alone, a PC will write several things to the registry, and an LSAPID value about 30 seconds to a minute *after* boot up (when all autostarts are already running). HTH,

 

I am using Registry Watcher but I am considering changing to RegDefend and I'm trying to evaluate the advantages/disadvantages of doing so. The way I understand it, RW scans the registry for changes at a configurable interval whereas RegDefend blocks registry access immediately. That is certainly an advantage for RegDefend. Also, I find the configuration and GUI of RegDefend more intuitive and less confusing. On the other hand, it seems that I will have to add several keys if I switch to RegDefend and desire better protection. Finally, I like the fact that RW log files can be viewed with any text editor. So, here is my question: How important is RegDefend's ability to block changes immediately? Even if a malicious program changes the registry, RW will report the change and I will be able to either deny it or even edit the registry manually and fix the problem. Are there any situations in which RW would miss a change because it only scans the registry at varios intervals? Also, is there a difference between the two programs as far as slowing down the system? Any thoughts would be appreciated...

 

Consider the case where the malicious program uses the registry to disable access to regedit There are more malicious examples, but I think this one demonstrates it quite nicely.


Mike

 

That wouldnt be a huge problem for me...I have daily backups of the registry and as long as I become aware of the change relatively soon I could restore a good version. I was thinking more along the lines of hidden registry keys that RW might not detect but would be stopped if blocked immediately by RegDefend... I think as long as I am notified by RW that there was a malicious change, I would be able to deal with it...

 

My understanding is this - because RD sits "between" the app, and windows it can catch anything the app tries to do. So , it would not be vulnerable to things slipping by (nor, I imagine, consume as much CPU) as a polling registry protection app.

The reason is this - even if the app somehow manages to hide itself, or its registry keys by some mechanism, windows still needs to "ask" regdefend if the change should be permitted. If regdefend says "No" then the change was never made.

So, to answer your original question, I believe that in principle the "prevent harm" approach of regdefend is superior to the "repair harm" alternative offered by polling apps.

Sure, I can have a heart and lung transplant. But, why smoke ?

Mike

[Disclaimer: Runs for a smoke now ]

 

Thank you for your reply Mike...it certainly made sense. I'm going for a smoke too...

Manuel

 

But more often than not RW will be enough. True RD is superior is some ways, but how often will you actually run into a situation where you would need it? I find RW to be good enough, and RW being free is what makes me choose it over RD.

 

Although I'm fairly certain that everyone knows this, perhaps it bears repeating. Namely, upon detecting a real or potential change to the registry, the very first thing that RW does is to record & KILL that change. After that, RW then asks you if you want to allow the change. If you say "Yes," RW then re-instates the change.

AFAIK, all other polling protectors of the registry will first allow the change. After that, they will then ask you if you want to allow the change. If you say, "No," they then delete the change & re-instate the prior value.

Since you can set RW to poll as often as once/second, it is *unlikely* (but not impossible) for a bad thing to happen to a protected area of your registry. (Actually, RW can be set to poll constantly, but I have never tried that option so I shall not comment.)

Thus, while RW does not give equal protection to that provided by RD, I conclude that RW is about as good as a poller can get. As to system impact: on my granddaughter's ancient computer (233Mhz cpu) RW is set to poll at 30 second intervals. With that setting, RW used 3.5 minutes of cpu time in 5 hours 27 minutes of computer on-time (gauged by Wintop).