MJ Registry Watcher

GE: One thing I have thought about is that it might be nice if there was a user selectable scan delay at boot. IOW, if there were some PCs that ran "fussy" items at boot that don't initially play well with other apps, one could delay RegWatcher's first scan for a user selectable period of time. Have it set as it is now for the default and adjustable for up to 2, 3 (or more) minutes after boot.

A minor thing I know but my PC at work is one of those PCs that has quite a load at boot. All for things that do need to start at boot. I guess this would allow users like me to have a more managed startup

 

WSFuser: To expand a bit more on shek's replay, if you upzip the MJ RegistryWatcher file, the Watch Keys can be viewed in Notepad (or any text editor.) So you can scope out the differences by printing off the lists for review.

Also, as shek notes, Registry Watcher does indeed use polling to read changes to the registry. But it polls much more than just the registry. If you look at the listings in the Watch Keys, you'll see it covers several important file locations too. As good as older versions were, the newest version (at this point 1.2.4.6) added even more (see thread reply #391.)

One key thing I really like about Registry Watcher, is that what it polls and how it does it is all up to you. It can highly customized for your own needs...

 

GE----

I would prefer you could change the way to organize the monitored registries values/subkeys. Currently they are in the alphabetical order. But I think it's better to put them into several groups, such as system startup entries, driver/services installation, browser hjack, etc, just like the Regdefender does for its global protection. It would be much easier for user to read and modify its own list.

On the other hand, when an alert pops up, it's also a good idea to show user which group the alert belongs to. Because sometimes, users don't know what the alert means or they don't have patience to read it, especially when the path of the value is very long. Pointing out the category of the alert will give users a intuitive idea, which i think is very helpful.

 

HAN
I like the idea of a delayed first scan, so that's a goer.
SHEK
The keys are already organised into groups by putting them in alphabetical order, because the registry organises things that way. The subkeys and values of a key spec group the related items, and the ordering ensures that like-purposed branches are grouped together. Instead, I could put comments in to delineate each section. The alert could find the last commented line before the alerting key spec, and display that as a header. I'll see what I can come up with.

While we're at it, is anyone up for an HTML help file which launches in your default browser, instead of the text one in the current version?

 

Either way is fine for me, but the current text file has worked quite well for me. It lends itself nicely for minor editing in MS Word when the mood has struck here and there.

 

That's exactly what I want.

 

I have now finished version 1.2.4.7 - it has the following changes :-

Changes 1.2.4.6 to 1.2.4.7
1) Corrected bug on "View File" which would get the row number wrong (and hence the file you wanted to view), when the character position in the list of files exceeded 64K. Only occurs on the &%system%.dll filespec key.
2) Increased maximum keys and filespecs (after expansion) to 50,000.
3) Corrected bug with it sometimes not viewing a file, even with the cursor on it.
4) Loading large files for viewing is now much faster.
5) Made alert annotation possible through the use of '##'-prefixed comments. See "Prefixes" above. Added annotations throughout all key sets. Tailor these to your heart's content.
6) Added option to delay the first sweep by a configurable number of seconds.
7) Enhanced display to show countdown to next sweep.
Settings menu now displays current settings on the relevant options.
9) Window co-ordinates are now stored in the configuration file with the MJRW window in normal state, even when the window had been maximised. This causes a brief flash of MJRW on the screen before it exits. Before, the maximised coords would have been stored, and restored the next time
MJRW loaded.
10) Moved the "Enable Keys List Editing" option to the main Options menu, making it easier to go into edit mode.

As usual, it's available at http://www.jacobsm.com/mjsoft.htm#rgwtchr

 

GE: Thanks for the update! Reg Watcher just keeps getting better! I have the new version installed here at home and it's running great.

 

Cheers for the Update

 

GE: Congrats on being included on one of the CD's with PC Utilities issue #76!

 

Just tested it. Well done.

 

Suggestion:
Is it possible that this amazing soft could hook into the registry like DiamondCS Registry Prot.

This would make this program faster in registry change notifications and nearly perfect.

 

I've recently been rediscovering this very cool program, but I've some queries, necessitating this post in hopes of finding someone that's a little smarter than I.
What are the functional differences between the security sets?
I can grasp the light - highest rulesets, but is there an advantage of running with the 'default' over the 'custom' ruleset?
I can see that the mjregwatchkeys.def file is quite a bit larger than the mjregwatchkeys.txt file, so I assume that there are more registry entries within the 'default' ruleset.
Question being: What is the optimal ruleset for "Joe User" without making any significant security compromises?
(Memory rises only very slightly in relation to security set file size selected).
My memory here (private bytes) is about 9.5 Mb. Not very light, but not outrageous either.
Documentation: Although MJ's help file is a succinct primer, is there any additional documentation available, to help users more fully understand / utilize this proggie? (Or is this thread as good as it gets?)

 

Bob D: Hello!

First off, my persceptive on MJ Registry Watcher. I'm just a regular user of Registry Watcher, but I must admit I'm a big fan! Of all the freeware process monitors I've test drove, Registry Watcher has been by far the best for me. (And there are some very good competitors out there!) Anyway, that said, I'll try to help you as best I can.

I'm not sure one could say what "the" optimal ruleset should be. Thus the reason GE gave us some options. The lightest set gives good coverage. But if you are willing to let the program scan longer, it digs deeper and therefore, gives more protection. But longer scans do use more CPU time. In my case, I have chosen the Medium set. On this PC, a scan takes from 5 to 6 seconds and I have an 8 second pause between scans. So I get approx 4 scans per minute. And I have my deeper scans (the .dll listing being one example) set at once every 40 sweeps... which work out to about one every 10 minutes. My experience matches yours in that the larger definition sets really don't use much more RAM memory. They just run the CPU longer during scans.

Documentation-wise, to my knowledge, this thread (now approaching 2 years old) and the help file are it. In my case, I found what I needed by combing through both items. (I assume you do know that the help text can be printed from the help window itself?) That, combined with a decent understanding of how the registry works. I know that in my case, I found Registry Watcher to be MUCH easier to work with than I did RegDefend (which I never could get to work right for me.) Oh, almost forgot... I also printed the security sets off via Notepad so that I could better look at and understand what each one covered.

If you have specific questions about Registry Watcher, I'll try to help you if I can. GE still stops by once in a while too. Nothing like the creator to give the best advice right

 

Thanx, HAN
I'll play around with the diff filesets and monitor subsequent frequency of the "HAI!" (karate chops).

cheers

 

Oh, one fairly important thing I forgot to mention. For many users, running in Accept mode may be the way to go until one is used to how the program works. Especially for things like new software installations (from trusted sources of course) and Windows Updates. A few pages back, GE discusses his "adventure" on this subject.

What I do at home is run 2 different Registry Watcher setups for my 2 user accounts. The Admin account is seldom used on the web (normally only for updates) and I leave that Reg Watcher setup as Accept. Then for my Limited account, I run Reg Watcher in Prompt mode.

After running Reg Watcher for a while, I found that I could accomplish this fairly easily because one can locate separate sets of program files for Reg Watcher in each user's folders in XP. Which in turn allowed me to run 2 (or more if I needed to) completely different setups (rules, timings, everything...)

 

MJ Registry Watcher TrayIcon1 error

Not every time but occasionally, MJRW opens a popup "Error reading TrayIcon1->Visible: Cannot Create System Shell Notification Icon." and appears to hang. Fix?

 

Confirmed. I just restarted the mjrw and the problem was gone.

 

WinPoch to my knowledge also does not pol. So DiamondCS Registry Prot. is not unique.

WinPooch is a open source project, could not the developer of MJ Registry Watcher (offers the most functionality) pick up how to implement this in MJRW?

Then the greates Registry Monitor would also be the fastest!

(please, please, please Mr Jacobs)

 

I add my vote to Kees' suggestion!

 

(My opinion follows... Not speaking for GE in any way. )

I too like the idea of a "non-poller" but wouldn't the program have to go in a completely new direction? Completely new code? IOW, starting over

I've been running Registry Watcher for many months and find little to criticize. It's stable, catches all changes that it should and for me, never shows signs of memory leaks (my PC at work today ran it for over 11 hours with no appreciable growth in RAM usage.) I even ran it for a while on my ancient Win 98SE clunker and it didn't seem to effect it much at all. If GE's original intent was to pay a form of homage to Mike Lin's Startup Monitor, IMO, he has achieved the goal quite handily!

(I do have a couple of questions though. I thought RegistryProt was a poller And how is WinPooch's stability? I thought it has been an issue since it's inception.)

 

Wow! Lots of suggestions here. OK, let's start with a non-polling version. I will look into this again, but there was some problem with resource usage using the "hooking" methods when you're monitoring hundreds or thousands of keys. But I promise to take another look at this issue. Certainly, a lot of code infrastructure would remain as it is, and the interface would not change much, but there could be some teething problems with any initial releases (but you know me, I'd clean those up ASAP).

As for different key sets - there is little difference between default and custom. The original reason for having these 2 as separate sets, was to allow experimentation with the custom set, while keeping a default set by which you could make comparisons with your tweaks. Anyway, it's better to have too many than too few! There will be little difference between memory usage for different sets, because the keys sets only use a small proportion of the memory footprint of MJRW. The higher sets are useful on PC's in a Cybercafe, for example, where no settings on the PC should be changed. Reject mode is just for such a purpose. However, as I have mentioned before, ALWAYS PUT MJRW INTO ACCEPT MODE WHEN DOING A WINDOWS UPDATE.

The "TrayIcon1->Visible" problem has happened to me only once in all the years I've been running MJRW. I cannot recreate it, but I will scan my code for any possible cause.

The documentation is a little, cough, cloudy for the complete novice. I'll see if I can improve the layout a bit, but no promises!

Thankyou, Han, for your helpful comments during my absence from this thread.

Regards,

 

Great to hear from you again Graphic Equaliser and Re-WELCOME!

In this new age of instant this and that, especially when it comes to registry detection, i for one as i know many others would certainly welcome your first NON-POLLING VERSION. The polling version as-is has been a great program IMO, and i also have had but little to complain about, in fact only the same desire to see some type of new "hooking" techniques that could instantly detect & ward off forced intrusion changes.

I know whatever you come up with in that manner will be another great effort and super advancement of this program. All The Best!!

We'll be here ready to help test it should you decide to take that "new direction" and report for you everything you'll need to "Clean Those Up ASAP"

 

OK. The situation as regards hooking is :-

1. Registry hooking does not detect registry key deletions
2. It does not detect changes brought about by calling the Windows RegRestoreKey function
3. Unless I am monitoring entire branches, I have to hold open every registry key I am monitoring. This would then preclude RegEdit of such keys.
4. I still have to do a sweep to determine exactly what has changed

Also, I still have to do sweeps to detect file and directory changes.

Putting all this together means that the best I can do is to hook the entire registry for any changes that hooking detects, and do an immediate sweep when one is detected, otherwise continue the normal sweeps. This gives us the best of both worlds. However, I am wondering just how much more quickly a registry change would be detected by hooking, if a sweep has to be done discover the change and optionally prompt for action. I think it would be best to do an "unthrottled" sweep (about a third of a second at most) after a hooked change is detected. Again, if lots of registry changes are occurring that do not affect any of the keys we are monitoring, we would be doing lots of unthrottled sweeps, which would jack CPU usage up a massive amount. Throttled sweeps take about 4 seconds on my PC, but that may be too long for you "instant detection" fan club members!

The best I can think of is that I do one unthrottled sweep after a hooked detection, and set a timer not to do any more unthrottled sweeps (just throttled ones) for the next 10 minutes. So if a batch of updates is hitting the registry, only the first sweep will "spike" the CPU.

Just some ideas. Any additions/refinements are welcome. Suggestions whilst I experiment. I'll report back later. Cheers everyone.

 

GE I understand your point.

Let's drop the idea of using registry hooking for both notification and analysis.

Just use hooking as an silent alarm and use regular polling for 'delayed' analysis/scanning (the guard who checks it).

Implementation idea
1. Registry hooking detected changes, triggers a silent alarm which is saved somewhere (e.g. make sure this trigger persists between logof and logon possibly forced by malware).

2. Regular polling mode also checks the silent alarm trigger, when the silent alarm is on, automatically:
a) for a period of 10 minutes the unthrotteld sweeps are skipped and
b) a delayed deep scan is triggered first (after those 10 minutes) to compare current values with the last saved ones, this could have the effect of a delayed batch check.
c) when no changes are detected or user intervention determines which changed to accept and which ones to decline the silent alarm is flagged off

With this safety 'hook' (the silent alarm set by hooking) the polling mode frequency could also be lowered to reduce system load.


Offcourse I do not know the programming logic of your great program, just
try to grey box the functionality of your program.

Keep up the good work

Kees