MJ Registry Watcher

What do you mean by "going between Firefox and IE"? Do you mean Alt-Tabbing between the running apps, or launching them? What are the exact steps needed to recreate your problem? What security set are you running?

I have just tried running MJRW with the highest security set, and then launching and re-launching IE and Firefox, but I get no alerts at all!

If MJRW detects that the value of key has been changed, it tries to restore the original before it shows the popup alert. It is this "restore" that is causing the other reg watchers to alert. But we need to find out what is making MJRW think that they key has been changed. Any more info would be useful, for example, an MJRW screenshot too, and the steps needed to recreate the problem. TIA,

 

I use Firefox, when at the same time I launch IE, suddenly I get registry changes that Prevx warns is caused by MJRW as per screenshot. I also get an error message that Spyware Guard is trying to alter the registry, so really not sure what is causing the issue. I can not replicate it, though it is consistently intermittent.

Loads, here we go:

1. Acronis True Image
http://www.acronis.com/

2. Nod32
http://www.nod32.com.au

3. Spyware Blaster
http://www.javacoolsoftware.com

4. Spyware Guard
http://www.javacoolsoftware.com

5. Spybot Search and Destroy
http://beam.to/spybotsd

6. AdAware
http://www.lavasoftusa.com

7. Security Patches
BugOff.exe
http://www.softpedia.com/public/cat/10/17/10-17-218.shtml

dsostop2.exe
http://www.nsclean.com/freebies.html

htastop.exe
http://www.nsclean.com/freebies.html

TweakUp.exe
http://www.softpedia.com/public/cat/12/1/12-1-30.shtml

8. Zone Alarm
http://www.zonelabs.com

9. Proxomitron
http://www.sankey.ws/proxomitron.html

10. Kye-U's filters
http://www.kye-u.com/proxo/forums/i...topic=131&st=0#

11. Ewido
http://www.ewido.net/en/

12. IE Spyad
http://www.spywarewarrior.com/uiuc/resource.htm

13. Mozilla Firefox
http://www.mozilla.org

14. Mozilla Thunderbird
http://www.mozilla.org

15. Prevx
https://www.prevx.com/

16. Hosts File
http://accs-net.com/hosts/get_hosts.html

17. MJ Registry Watcher
http://www.jacobsm.com/index.htm#sft

18. Crap Cleaner
http://www.ccleaner.com/

19. Process Guard 3
http://www.diamondcs.com.au/

20. Netgear FR328S ProSafe Firewall
http://www.netgear.com.au

Told you there were lots

That’s what I do, run and use FF and then occasionally launch IE using the highest security set.

MJRW doesn’t launch Spware Guard and Prevx go berserk.

This is the only entry from today’s log that I can see, unless they are stored elsewhere:

** Tuesday 7/12/2004 12:51:47 PM **
Loaded 1,423 Values (123K) and 885 Subkeys (12K) and 19 File Stats
=======================================================
** Tuesday 7/12/2004 12:56:27 PM **
Registry Key hkey_users\S-1-5-21-1715567821-1220945662-1801674531-1003\software\microsoft\internet explorer\main
Value Window_Placement (B) wants to change from
2C 00 00 00 02 00 00 00 03 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 93 01 00 00 91 00 00 00 93 04 00 00 A3 02 00 00
to
2C 00 00 00 02 00 00 00 03 00 00 00 00 83 FF FF 00 83 FF FF FF FF FF FF FF FF FF FF 93 01 00 00 91 00 00 00 93 04 00 00 A3 02 00 00
=======================================================
** Tuesday 7/12/2004 12:56:48 PM **
Could not write value Search Page to key hkey_users\S-1-5-21-1715567821-1220945662-1801674531-1003\software\microsoft\internet explorer\main
Failed to set data for 'Search Page'


Hope this helps…

Cheers

 

Blackspear shows MJRW's log as :-
(1)
** Tuesday 7/12/2004 12:56:27 PM **
Registry Key hkey_users\S-1-5-21-1715567821-1220945662-1801674531-1003\software\microsoft\internet explorer\main
Value Window_Placement (B) wants to change from
2C 00 00 00 02 00 00 00 03 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 93 01 00 00 91 00 00 00 93 04 00 00 A3 02 00 00
to
2C 00 00 00 02 00 00 00 03 00 00 00 00 83 FF FF 00 83 FF FF FF FF FF FF FF FF FF FF 93 01 00 00 91 00 00 00 93 04 00 00 A3 02 00 00
=======================================================
This is a "bad egg" at the moment, since you cannot exempt wildcarded values, without exempting each one individually (I'm thinking of ways to improve this, perhaps allowing wild value and subkey exemptions). You could try adding hkey_users\S-1-5-21-1715567821-1220945662-1801674531-1003\software\microsoft\internet explorer\main\Window_Placement to the exempt values list (first item on Options menu), and that will stop this alert.

(2)
** Tuesday 7/12/2004 12:56:48 PM **
Could not write value Search Page to key hkey_users\S-1-5-21-1715567821-1220945662-1801674531-1003\software\microsoft\internet explorer\main
Failed to set data for 'Search Page'
=======================================================
MJRW is complaining that something else has changed this value, and it is trying to restore the original, but since this is the key that is used to hijack browsers, your other protector apps may have "locked" the key, so MJRW complains it cannot restore it. But, please let me assure you, MJRW would not even try to restore the original if it hadn't detected a change on it in the first place - it does not willy nilly write to the registry unless an alteration has occurred. You need to look at what else could be trying to change this key. You could try putting MJRW into auto-accept mode, and try it again to see what happens. The MJRW log should still record what has changed and where, even in auto-accept mode. Good luck,

 

I understand.

No worries.

I'll do as you say and see what the logs show up.

Many thanks for your quick reply, will post back when I have something...

Cheers

 

Wow, I'm impressed that you made the switch to multi-threaded so quickly (and that it works). And the key exemptions seem to work perfectly now, too. Yes, of course it would be concise, portable and generally cool if someday wildcards work for exemptions too, but this is very functional and greatly appreciated.

I was only accidentally bitten by the modal window conflict one time. I can easily avoid it by stopping the scans while I edit a list. Since adding my three problem-child subkeys I've had only one popup. Very nice.

So far, I think this version looks really good. Thanks a bunch!

 

Ok, it just happened. I had Firefox running with 2 tabs logged into Wilders. I then clicked on Start> IE (recently used directly above Start). Up popped IE and I changed the page from Google to dropping in a further link to the same Wilders page into the address bar of IE. Then at the same time the change of Home Page warning in Prevx and SW Guard appeared, next up came MJRW and then a “Can not Focus” warning from MJRW.

This is the error log and a few screen shots:


** Wednesday 8/12/2004 4:45:04 AM **
Loaded 1,423 Values (123K) and 885 Subkeys (12K) and 19 File Stats
=======================================================
** Wednesday 8/12/2004 6:07:57 AM **
Registry Key hkey_users\S-1-5-21-1715567821-1220945662-1801674531-1003\software\microsoft\internet explorer\main
Value Window_Placement (B) wants to change from
2C 00 00 00 02 00 00 00 03 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 16 00 00 00 1D 00 00 00 D6 03 00 00 EC 02 00 00
to
2C 00 00 00 02 00 00 00 03 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 33 00 00 00 3A 00 00 00 F3 03 00 00 09 03 00 00
=======================================================
** Wednesday 8/12/2004 6:11:47 AM **
Could not write value Search Page to key hkey_users\S-1-5-21-1715567821-1220945662-1801674531-1003\software\microsoft\internet explorer\main
Failed to set data for 'Search Page'


Clear as mud

Cheers

 

Next set. I did click to "accept" last night as suggested, however as you can see it did not keep its settings upon boot this morning...

Cheers

 

Blackspear wrote :-
"Then at the same time the change of Home Page warning in Prevx and SW Guard appeared"...

What is weird about this problem is that the immediate warnings from the 2 applications mentioned, probably means that at least one of these apps has "hooked" the registry key to report for any change to it. This prevents MJRW from writing to it in order to preserve it, if it changes. It is reporting that in as much as the error message Failed to set data for 'Search Page' comes from the Windows operating system. Unless these keys are unhooked, MJRW should be set to Auto-Accept, so that it becomes a reporting tool for changes to the registry, while not trying to write to these protected keys. Or you could exempt these values from checking, as I described in my previous post. Then, you wouldn't see these alerts, and the other programs that protect these same keys can continue to protect them as they should.

Oh, and by the way, you are not running the current version, which is 1.2.2.8
Try refreshing the webpage or clearing the cache if it still shows the 1.2.2.7 picture on my website.

 

That should be Javacools: Spyware Guard, this is it’s function.

Auto accept for just these keys I gather you are meaning?

Done, will see how that works out.

Don’t know what happened there, it’s now installed.

Many thanks for you assistance with this.

Cheers

 

Well so far so good, no more problems after adding thoses 2 keys into the ignore list.

Thanks Graphic Equaliser

Cheers

 

I have just updated MJRW with a couple of bug fixes. Version 1.2.2.9 is available at http://www.jacobsm.com/index.htm#sft

Changes 1.2.2.8 to 1.2.2.9
1) Fixed bug with Backup Current Key. When there were multiple keys on the current line, a pick-list is presented to the user. This would show the matching keys for the line, and allow you to multi-select them for backing up. However, this list would be blanked out when a checking loop started. Now, it doesn't blank it out.
2) Fixed bug with value exemptions being case sensitive when matched against an expanded wildcard value, and sometimes failing to match an exemption as a result. Similar hkey_user subkey bug above.

 

hi to all.
i just wanted to tell you: thanks very much for this program. i searched for something like this for long time, and now i have it. thanks again.

ps: for me, the usage is 0% ...for now...i use the highest level.

 

I have just put up version 1.2.3.1 of MJ Registry Watcher at http://www.jacobsm.com/index.htm#sft

It has the following improvements :-

Changes 1.2.2.9 to 1.2.3.1
1) Fixed a couple of minor irritations.
2) Now, an alert trying to pop up when you are editing one of the exemptions lists will not cause an error.
3) If a change is accepted, the middle panel now auto-refreshes to display the new values, and the top panel will reflect the key that changed more accurately.
4) Added some new exemptions for Windows 9x.
5) Implemented ability to wildcard exemptions using "". The exemptions files have been updated accordingly.
6) Added 4 more crucial system files to the monitoring lists.

The most important one is probably the ability to exempt keys or values for *ANY* user, by using the wildcard facility. I hope you like it!

 

Hi,

1.2.3.1 runs on both of my systems at 0% (zero) utilization with the Highest key set. Thanks for fixing this!

I have noticed that you added some new keys:
hkey_lmus\software\classes\mailto\defaulticon
hkey_lmus\software\classes\mailto\shell\open\command link
hkey_local_machine\system\currentcontrolset\control\session manager\subsystems link
While I recognize the relevance of the last two keys, can you tell something about the first key? Why do you need to protect that?

Edit: I have spoken too early. Utilization spikes jumped back to repeating 16% suddendly after fooling around with IE, and excempting a single value "hkey_users\s-CENSORED-59\software\microsoft\internet explorer\toolbar\webbrowser\{0e-CENSORED-83}". After an exit and restart of RegWatcher, utilization spikes are at 3%. I am afraid this is some kind of bug. Monitoring same key set and subkey/value quantity did only used 0% on the same system a few minutes ago. I am not running other registry monitors on this system.

-hojtsy-

 

Firstly, the utilisation should be the same as for version 1.2.2.9, unless an alert occurs on an exempted subkey or value. Then it can get higher, until you restart MJRW. It is a design flaw in that it spots a difference and investigates further, and sees it is an exemption, and continues to the next in the loop. This makes for more work each time round the loop until the program is restarted, when it will re-initialise the values it has stored. I will change this in the next version, so that restarting is unnecessary.

Secondly, the utilisation reported by Task Manager is not always accurate, even on the "fast" setting. When apps are loaded and unloaded, it can sometimes affect the utilisation reported for a running app under Task Manager, even though nothing has changed with that app. Bear in mind that the monitoring loop runs at the lowest possible thread priority (except for only process when idle, which is the very lowest, but no good for our purposes), so, if anything else wants to run, then it will get almost full CPU attention, while the loop slows to a crawl or stop. In this instance, I feel that utilisation figures are pretty much irrelevant now.

I need some feedback on the length of time the loop takes to run - is it too long? Can I make it even longer (1.5 times longer to be precise) so that really ancient PCs can run MJRW (1/18th sec. granularity)? I am considering changing the throttle delay from 40ms to 60ms.

 

Hi all,
just wanted to give some feedback without actually having any issue with it.
I have it installed on my parents' comp. and do really think that MJRW is a keeper. (Maybe I will replace RegRun with it some day - i just don't have enough time to look after the (dis-)advantages of doing so these days.)
I am baffled by the speed of development and by the way Graphic is keeping in touch with the users. (too good for me to keep up-to-date with it.)

I think you are doing a great favor to the "community" and want express my appreciation for it. Keep it up - all of you.

Andreas

 

CPU Utilization by RegWatcher with Highest security:

After installing RegWatcher: 0%
After a few hours of running IE, and excempting three values: 16% spikes.
After exit and restart of RegWatcher: 16% spikes.
After reboot: 0%

I am quite sure that something is not OK!! Number/size of monitored keys was almost constant during this, so it could not be the reason.

-hojtsy-

 

Hojtsy,
this is why I monitor both the icon and app path for mailto :-

=======================================================
** Wednesday 15/12/2004 4:53:42 pm **
Registry Key hkey_local_machine\software\classes\mailto\defaulticon
Value (S) wants to change from
"C:\Borland\CBuilder5\Projects\dkfaxmail\DKFaxMail.exe"
to
"C:\PROGRA~1\MICROS~3\OFFICE11\OUTLOOK.EXE",7
Value OldVal (S) is going to be deleted - data is
"C:\PROGRA~1\MICROS~3\OFFICE11\OUTLOOK.EXE",7
=======================================================
** Wednesday 15/12/2004 4:53:42 pm **
Change Auto-Rejected
=======================================================
** Wednesday 15/12/2004 4:53:42 pm **
Registry Key hkey_local_machine\software\classes\mailto\shell\open\command
Value (S) wants to change from
"C:\Borland\CBuilder5\Projects\dkfaxmail\DKFaxMail.exe" "c:\dkfmmj\" "%1"
to
"C:\PROGRA~1\MICROS~3\OFFICE11\OUTLOOK.EXE" -c IPM.Note /m "%1"
Value OldVal (S) is going to be deleted - data is
"C:\PROGRA~1\MICROS~3\OFFICE11\OUTLOOK.EXE" -c IPM.Note /m "%1"
=======================================================
** Wednesday 15/12/2004 4:53:42 pm **
Change Auto-Rejected


As you can see, Outlook XP attacks both keys wantonly!

 

Hi Graphic,

Well, the sweet spot you've hit keeps getting sweeter for me. Wildcard exemptions are a big improvement. I love that the same exemption list covers all users on any computer. Also, it's good news that a new popup window won't conflict with an edit operation. Thanks again for the enhancements.

From observation (counting seconds) it appears that the integer value controlling MJRW's rate is actually the number of seconcds to wait between the end of one sweep and the beginning of the next sweep. My original mental image was of time from beginning to beginning. It was relatively indistinguishable before you introduced the "cooling period" between checking registry keys.

Overall, I think the choices you've made are good ones. Spacing things out has resulted in much smoother operation with less potential for thrashing. I suspect you can space it out further (60ms) with little or no downside. On a fast computer it will still have time to complete a cycle every 5 seconds, and on a slower computer, thrashing is probably a bigger issue than a few extra seconds between sweeps.

I'm assuming you'd prefer not to add another config option. A couple of other possibilities do spring to mind. The first one is simple, I think. If the adjustable time setting is as I've described (end of cycle to beginning of next) you could allow that value to be set as low as zero (no wait before starting the next sweep) which would retain a bit more flexibility on the "fast sweep" end.

And now for something completely different. Alternatively, you could use the time setting as a per-sweep allottment of time, and then calculate an optimal (maximum) delay that would finish in the allotted time. The main downside would be the risk of contributing to a positive feedback loop that keeps working harder as the computer gets busier. Perhaps recalibrating the delay at the end of each cycle, but rather than changing it aggressively, lean toward maintaining a conservative value and allowing the total-sweep-time to increase as the system gets busier. I guess on Win 9x it would need to remain 60ms, though.

Obviously, this idea is a bit under-developed, but if a simple and balanced algorithm can be found, it might improve both adaptability and performance. On a fast system with 10-second sweeps, for example, the calls could be spread out much further. I'm not sure, though, how hard to work at adding zeroes to the right of the decimal point when MJRW already seems to have pretty good efficiency. Anyway, I just wanted to throw it out in case it sounded like an interesting alternative.

Mike

 

Your wish is my command. I have just uploaded version 1.2.3.2 and these are the latest changes :-

Changes 1.2.3.1 to 1.2.3.2
1) You can now have the timer set to zero to indicate constant checking.
2) When exemption alerts are detected in the checking loop, and no other proper alerts occur, CPU usage was higher than when no alerts had been detected. This has now been cured. Exemptions will move the display to the alerting key, but not raise an alert.
3) Added menu options to fine-tune the checking loop parameters.
4) Discovered that changing a value in HKEY_CLASSES_ROOT\\shell\open\command automatically changes
the corresponding entry in HKEY_LOCAL_MACHINE and vice versa, and so I removed the local machine keys from all lists.
5) Fixed bug with wildcard expansion algorithm that got librarypath but missed packedcatalogitem!

 

Graphic,
How about making it so that clicking on close when the GUI window is open just minimises the app rather than exiting, and use a right click menu on the tray icon to allow the process to exit...

A minor thing but I sometimes exit without meaning to...

Great little app btw, one of my favourites

Thanks

 

Hi gottadoit,

This was suggested eaarlier and Graphic indicated a distinct preference for the current scheme. As a ProcessGuard user, you can protect MJRW, then select "Secure Message Handling". PG's HID confirmation works nicely to prevent accidental closing.

Graphic, another alternative for easy/foolproof minimization (for all us fools out here ) might be to let the escape key minimize the main window (assuming you're not already in edit mode [more later]). I always prefer avoiding the mouse when possible, and it might provide an alternative for folks whose instinct keeps seeking out the close button.

At the opposite end of that spectrum, at whatever point MJRW becomes popular enough for malware to target as an "enemy program", using the keyboard to accept or reject changes may have security implications. I'm always loathe to suggest actions be made "mouse click only", but that does seem to be a more secure form of input. Not sure if or when this could become important.

Thinking of edit mode brings up an oddity I noticed. I must have accidentally pressed a key while MJRW had focus which resulted in a blank line in the monitored key/file list. I'm sure I didn't explicitly save the change, but when you exit MJRW, it seems to save any changes without being asked to do so. When I next started MJRW, it presented an "OK" MessageBox with no message. When I press "OK", it disappears, but MJRW remains "Stopped". After pressing "Start", MJRW could only check the entries that appear before the blank line. After I edit again to remove the blank line and "Save", MJRW returns to normal.

A couple of times, I think MJRW "stopped" monitoring as soon as I pressed the first key that started an edit (ie: when MJRW enabled the "Save" button). I could not, however, reproduce that behavior with any regularity. After I gave up trying to reproduce it, I thought I saw it happen a second time. Also, when creating the "blank line" error condition, the Stop/Start button sometimes got out of sync, but an extra button press or two ("Stop") would always set things right.

For me, the issues above highlight a couple of themes. First, entering "edit mode" at the touch of a key makes it very easy to inadvertently make a change without realizing you've done so. These errors will tend to be significant and hard to find because MJRW usually has the name of a monitored key as "selected text" which means any keystroke will remove an entire key name. Second, the auto-save on exit makes it too easy to accept a change you did not intentionally make. In fact, I don't think there is any way to avoid saving a change once it's been made on screen. I tried both logging off and restarting the system (without exiting MJRW) and either way, the change is saved automatically.

One suggestion to resolve most of the ambiguities above would be to remove the "Save" button and the "auto-edit mode" in favor of an entry to "Options" entitled "View/Edit Monitored Keys/Files". By making an edit of the monitored list explicitly chosen, it should behave identically to the "edit exemptions" options. It would still be handy to have the main screen pane to browse or to jump inside of Regedit with, but the edit control would contain read-only text.

Sorry for being so long and windy on suggestions (again ). Version 1.2.3.2 is great. I love the configurable throttle times and the zero delay option.

Thanks,
Mike

 

Earth1,
I could make a checkable menu item called "Edit Keys Mode" on the Options pull-down. It is unchecked at start up, and you can check it if you want to change something. That's a great idea. Thanks for the suggestion.

There may be something wrong with the way MJRW handles blank lines, so I'll investigate this.

There is another bug I have to correct. Whilst mucking around with the loop delay, I set a 10 minute wait, and the loop just finished, so it started to wait. I changed it back to 5 seconds, and still nothing happened. Ten minutes later it started the next checking loop, and then adopted the new delay of 5 seconds. I have to chop the wait interval into responsive enough chunks, checking whether the thread has been suspended by the user changing the wait time - or, for that matter, whether the user or system wants to exit. That'll be in the next version.

You were right about it auto-saving any changes on exit. Perhaps it should raise a question at this point, having terminated the checking thread.

The idea of the escape key wasn't bad, but it clashes with other uses of this key. However, I have just tried Control+Down Arrow and that does nothing, so I could easily implement this UI enhancement. Definitely one for the next version.

 

Graphic,
Verify before save-on-exit would be great. Without verification, I'd be inclined toward abandoning unsaved changes, since they were never actually tested/used while MJRW was still monitoring. Now that you mention it, perhaps verification before program exit would also be a good thing. Unintentional closing looks like it may be fairly common concern, and verification could also add some security against malware closing MJRW. OTOH, maybe DCS will give you a commission for referring people to ProcessGuard.

I think the main advantage of the escape key is that a million new users can find it without being told and can remember it without memorizing anything. Of course, I have no idea how tricky it is to distinguish the differences in escape key usage from within your GUI's API. If it seems ill-advised to code/maintain that distinction, CTRL-DOWN would be most welcome from my point of view.

As always, I'm very glad to hear that there will be another version.
Mike

 

Graphic,
I hope this isn't a dumb question for this thread...

I was wondering why you don't monitor the system wide Path registry value with your set of default values
I know its fairly old-hat but executable interception by changing the path is still fairly effective...

I'm referring to the key
hkey_local_machine\system\currentcontrolset\control\session manager\environment\Path

Thanks