MJ Registry Watcher

Graphic, When I remove RW from my startup folder and run it manually, the problem is the same. Contrary to my earlier description, I now see no difference between v1.2.1.8 and the modified version in rwtest.zip.

Here's the interesting part. Earlier, I described seeing the rwtest version flag every value under the Run key as being new, then continuing to flag it every 5 seconds until I exited. I now know it was happening because I pressed the "Reject" button on the first popup warning. So long as I keep pressing "Reject", (either version) the next popup reappears 5 seconds later with the same message. Pressing "Accept" breaks the cycle.

When the popup first appears, the messages in the center pane of the main window list the links in the Common and User Startup folders, followed by:
============================================
** Cannot Find Key hkey_local_machine\software\microsoft\windows\currentversion\run **

The contents of the center pane stay the same so long as I keep pressing "Reject". When I press "Accept", it stays the same for 5 more seconds, then the error message is replaced by:
=============================================
5 Values for hkey_local_machine\software\microsoft\windows\currentversion\run: -
Adaptec Direct CD (S) C:\PROGRA~1\ ...
corresponding to the 5 entries in my Run key.

It appears there is some difference in the progrram logic as it is entering the main loop or the first time through the main loop. There may be a better way of handling this error condition, but in the end, I think, it must remain an error. Since RW doesn't have write permission on that key, protection is not possible. Perhaps you could popup an error window listing read-only keys that cannot be protected. Probably the worst choice would be to fix this so that there appears to be no error. RW would be unable to protect any read-only keys, but a user might not understand that until it was too late.

HTH, Mike

 

It occurred to me as I re-read your last post, that I might tun up some more information by using runas to start regmon. I'll try it later tonight when I get some more time.

Mike

 

Graphic,

I've been very busy tonight learning how to use Regmon and trying to track down how RW interacts with BoClean. That information turned out to be unimportant, so let's just skip to the humble apology.

Attempting to understand what was happening with RW has opened a few stuck doors inside my head.. I told you that StartupMonitor was working for me under similar conditions. I felt confident of that because I'd used it for quite some time, and whenever I knew it should be popping up it did. It always did exactly what I thought I wanted it to do. Had I known then how to properly test this from my User account, it would have failed (in total silence) for the same reasons that RW encountered problems. It protected me from myself, but it wouldn't have alerted me if a system process (or a privileged hacker) made a change while I was in my User account.. Thank goodness MJRW made some noise and opened my eyes.

I'm truly sorry for misinterpreting what was happening.. I hope it will be easier for you to continue with your good works if I quietly find my seat for a while.

My sincere thanks for your help and your patience,
Mike

PS: My only (timid) suggestion is that when RW opens each registry key on the list during its initialization phase, anything that results in an error status of "ACCESS DENIED", might be an opportunity to popup more specific error messages related to security/permissions. Good luck!

 

Hi,

The excemption feature don't seem to work on any of my Win2000 systems. I still keep getting alerts for Window_Placement.

Even if it would work, I am afraid there is a conceptual error. The Window_Placement value should only be ignored in a specific key, and not in every key. This way the trojan can create auto-start entries elsewhere with the name Window_Placement and be ignored by RegWatcher. So the excemptions should contain the full registry path.
-hojtsy-

 

MJRW fixes in file http://www.jacobsm.com/rwtest.zip

1) I have fixed the exemption feature (too many carriage returns in a string).
2) I have allowed better recovery from protected key or value problems.

rwtest.zip is the current beta of MJRW and contains the latest .exe file on its own. It allows me to release fixes for immediate bugs that affect only some people, where the majority would not benefit from a formal release. In this instance, although the exemption mechanism is an important fix, Hojtsy and I are still hammering out the best policy for treating this feature.

Mike, this beta version should allay the repeated alert problem when keys are write-protected. Please let me know if it doesn't. TIA,

 

Thanks Graphic, although the popup does recur every 5 seconds after pressing "OK", that's fine by me. No sense leaving it running if it's unable to do the job. The error message "Some values are Write-Protected - Change cannot be fully undone" is now unmistakeable. Kudos.

 

Which other values called Window_Placement would you need alerting about? Even if a trojan created such a value, it couldn't do any harm with it, at least, not without being in conjunction with some other change(s) involving an executable auto-starting, which would be detected by MJRW.

Currently, I see the HKEY_USER tree as the most useful for wildcard targeting, although I will implement it in a general manner. My current dilemma is whether to recurse subtree scan, expanding wildcard specifications every 5 seconds, or just at startup. I will experiment with both designs to see the impact on resource utilisation.

 

If neither option seems satisfactory, you could perform an expanded scan at a frequency of "every Nth regular scan". In C/C++:
. . . if (++scan_count == expand_at_count) { scan_count = 0; do_expanded_scan() }
It uses the existing timer and expand_at_count could be hard-coded or an entry in the CFG file. I hope thinking out loud was meant to be a group activity.

 

There is a serious problem wih the way a recursive scan works. If it throws up more or less keys and/or values than it did before, there are no items to compare these new entries with. The complications new key and value discoveries would produce, mean that an initial scan at startup, forming an invisible expanded top window in memory, and use that to scan each time, is the best initial approach. When the cursor is on a line in the top window with \*\ in it, then this is a recursive key or value, and any matching discoveries made at startup will be listed in the middle window. I think making the top window allow specific values, rather than whole keys, may be useful too. The wildcard syntax can specify either, and then coverage would be complete, and up to the user's ingenuity and insight. Filenames should allow wildcards too, so directories could be specified by c:\blah\subblah\*.* for example. That's quite a lot of work, so it may be some time before it arrives. Also, it may well be too resource-hungry in its initial incarnations, but we'll have to see what happens. Thanks again for your suggestions.

 

Hello, Graphic.


Please excuse my question, because I'm sure the answer is simple and I'm just missing this because of my lack of knowledge about the registry.

I am still getting a very similar warning when I use Windows Washer. When I run it, it apparently deletes a subkey called "RecentDocs". But now I am not even getting an "Accept" or "Reject" button by MJRW as I was before (see post above) - now I just getting an "OK" button (see attached pic). Why is this?

What I would really like MJRW to do is stop monitoring this subkey. I was wanting a button that would allow me automatically to tell MJRW this. But to be honest, now I'm not even sure how to manually remove a specific subkey from being monitored. Do I have to remove the entire key from the top window?

 

RegWatcher was never able to undo or reject a subkey creation, or deletion. Old versions had a bug that they displayed the fake "Accept" and "Reject" buttons, both of which did nothing. Only changes to values could be rejected.

Currently not possible. That could be an improvement of the current excemption feature.

That is something I wanted to suggest also: put an button into alerts with the label "Ignore this value from now", or something like this.

Go on and comment out the line containing "hkey_current_user\software\microsoft\windows\currentversion\explorer" in the top window, by inserting a # into the first column of that line. Then press "Save". This key is not on the Big List! I am not aware of any hijacks or autostarts concerning this key. (Graphic, can you tell why is it monitored by default?)
-hojtsy-

 

Well there you go. I am sure that subkey additions and deletions have never given an Accept/Reject prompt, because they are nigh impossible to undo, without large resource consumption (storing and restoring entire hives of keys, subkeys and values). I suppose the addition of a subkey could be negated, but this is rather dangerous if done quickly without thinking about it. So, I have put a Regedit button in to enable you to visit the alerting key and remove if it necessary from there.

Daisey and Hojtsy, your suggestion for an "Add to Exemptions" button, and a revamp to the exemptions feature to allow addition of subkeys and values to this list, is a great idea, and definitely one for the next release. I'll still keep the "Comment Out Key" feature, in addition to the new exemption feature. So, we will have 4 buttons - Accept / Reject / Comment Out / Exempt.

One complication though, is that several subkey additions and deletions to one monitored key, or several changes to values, are reported in one go, so how do you know which ones to exempt when you hit the Exempt button? I suppose I could put up a check listbox listing the subkeys or values affected, and ask the user to check all those that need exempting. Is this design OK - you hit the exemptions button on an alert, and a list of the alerted subkeys or values is presented. You'd then have to check the items you want exempting.

P.S. I got this alert the other day :-
=======================================================
** Wednesday 17/11/2004 11:47:57 pm **
Registry Key hkey_local_machine\system\currentcontrolset\control\session manager\
Value PendingFileRenameOperations (M) will be a new value with data
\??\C:\DOCUME~1\User\LOCALS~1\Temp\~f51e43.tmp
=======================================================
** Wednesday 17/11/2004 11:47:57 pm **
Change Auto-Rejected
=======================================================
Any ideas what it may have been - it was completely out of the blue, and I was not connected to the Internet at the time.

 

The excemption feature seems to be working in the beta. But see below:

A trojan could create a new value in "hkey_current_user\software\microsoft\windows\currentversion\run" key with the name "window_placement" and string value "c:\trojan.exe". It will be ignored by RegWatcher, and this value alone is enough for the trojan to autostart. So excemptions should be stored with full path.
-hojtsy-

 

Fine! I wanted to suggest that one too.

It would be perfect!

I suppose it is a temporary file of any of your running applications, and it is scheduled to be moved to Recycler uppon reboot. I do not yet have any idea how to avoid irrelevant alerts of this kind.
-hojtsy-

 

Any *SUBKEY*under hkey_local_machine\software\microsoft\windows\currentversion\run which specifies executables in any of its values, will *NOT* run that executable. Let me just test that now. Right, I tested it and it does *NOT* run anything in subkeys *UNDER* hkey_local_machine\software\microsoft\windows\currentversion\run. However, if a *VALUE* called Window_Placement is made under hkey_local_machine\software\microsoft\windows\currentversion\run, then it will run whatever executable is in its data string. YIKES! Exemptions will definitely have to specify entire key paths to the values or keys that are exempt. Thanks for that one Hojtsy! Mind you, there can't be many trojans out at the moment that exploit this weakness in MJRW!!!

Here's a bit more info on \??\C:\DOCUME~1\User\LOCALS~1\Temp\~f51e43.tmp

It is an executable file, which I have now got quarantined. It looks suspicious in that, despite the hex dump revealing it is made with Visual C++, it is encrypted (I am not seeing the usual assembler constructs in the dump) and only about 40-50K in size, which is trojan-sized. I think I'll try submitting it to that site for checking files (it had great fun with my PDSched.exe and PopupBlockerd.exe files - the latter was unknown on 4 of the scans!). Hojtsy, can you remind me again of the web address for this site. TIA,

 

Submit suspect files to http://www.virustotal.com/xhtml/index_en.html
-hojtsy-

 

A new version of MJ Registry Watcher 1.2.1.9 is now available for download from http://www.jacobsm.com/index.htm#sft

Changes 1.2.1.8 to 1.2.1.9
1) The top panel can now handle individual values (instead of entire keys)
2) The top panel can specify hkey_lmcu and \\ key mnemonics for easier PC coverage.
3) When there is an alert, you can selectively exempt values from future alerts.
4) Default key list rewritten to use the new mnemonics.
5) Exempt values now have to specify the entire path of the key to the value you want to exempt.
6) More improvements to the interface and underlying code.

Please save any special keylists and exceptions files, before overwriting them with those in the zip file. The new lists demonstrate a lot of the new features, but, since it now monitors more than twice the keys, it takes more than twice the resource to run it. However, it can be put back to normal resource usage by commenting out the key hkey_local_machine\system\currentcontrolset\services\\imagepath which adds over 200 existent keys on my system! Simply put a # sign in front of it and save the list to go back to a less secure configuration, but with minimal resource usage.

Hojtsy, I could not use the * notation because there is a subkey called * in my classes root key! I had to call it , to avoid infinite recursion!

 

@Graphic- RW just gets better & better & better.

By the way, I suggest you turn smilies off on your posts. Otherwise, if you enter a group of 3 question marks, you will get this

 

Bellgamin, there was a bug on the subkeys functionality. Redownload to correct this. The zip file should be dated today at 10:12pm. Thanks for your support.

 

Done. Thanx!

 

Hi,
I am testing 1.2.1.9. Everything seems OK.
The excemption list editor window have a bogus "Except certain values" button on it. BTW would it be possible to add a regedit button to the excemption list editor?

I suggest adding "hkey_local_machine\software\microsoft\windows nt\currentversion\winlogon\dcacheupdate" to the default excemption list. On Win2k I am getting irrelevant alerts for it.

About CPU usage. I have 16% utilization pulses with the full list, and 5% utilization pulses when all of the ? ? ? entries are commented out. I am a c++ developper myself. Is the implementation done in a way so that the subkey enumeration for hkey_users\? ? ? is done only once per scan cycle or is it repeated for each such entry? Maybe that can improve performance.

-hojtsy-

 

HOJTSY WROTE :-
The excemption list editor window have a bogus "Except certain values" button on it. BTW would it be possible to add a regedit button to the excemption list editor?

This extra button is a bug. I am going to correct these nuisances, and release a 1.2.2.1 version with these corrections, and a couple of others besides. I am also going to comment out some of the wildcarded keys in the default list, so that resource usage is not too high. My 1.4Ghz AMD Athlon is currently monitoring 420 keys and files, and it's OK to use. If I play an intense game like Quake 3 Arena, gameplay occasionally stutters slightly for a very short blip, so I think it should only use the wildcard keys on power PCs. The 2.8GHz P4 HT doesn't fare any better than my Athlon PC.

Consider hkey_local_machine\software\microsoft\windows nt\currentversion\winlogon\dcacheupdate added to the exemptions next release (coming soon - no new features, just a "tidy up" release).

HOJTSY WROTE :-
About CPU usage. I have 16% utilization pulses with the full list, and 5% utilization pulses when all of the ? ? ? entries are commented out. I am a c++ developper myself. Is the implementation done in a way so that the subkey enumeration for hkey_users\? ? ? is done only once per scan cycle or is it repeated for each such entry? Maybe that can improve performance.

The subkey enumeration is done at startup, and every time the keys and files list is saved. It is *NOT* done every 5 seconds. Even so, the enumeration does not take too long - it is the comparison of each value in any order that takes the CPU time up. Even this I sidestep by initially comparing all the data for any key as a long string, against what is stored, and that is why it is so fast. If they are the same, the key and all of its values have not changed, and this is discovered in a single string comparison. The same comparison shortcut is used for the subkey lists, so if a key has 209 subkeys, only one string comparison is made, not 209. I don't believe it could be done any faster than it currently is, and this kind of barrier is one I meet very often in the C++ world - application performance - you can really push these CPUs to the limit with this language. If the comparison fails, then MJRW looks at each individual value and subkey to determine what has changed, and since this is a rare incident, the program is running optimally.

Anyway, I'll try to get a "tidied up" version 1.2.2.1 out before midnight tonight!

 

Not quite as promised (it's now gone midnight!), but there is now version 1.2.2.1 of MJRegWatcher available from http://www.jacobsm.com/index.htm#sft

Hopefully, I can let it rest awhile, and just add keys as we find them. No more bugs (please!) and no immediate need for more features.

Here are the help changes :-

Changes 1.2.1.9 to 1.2.2.1
1) Tuned up default key list to balance resource utilisation against security better.
2) Corrected bug where one of the buttons became visible when it shouldn't have been.
3) Added some better default exclusions.
4) Corrected bug where startup directory changes were not reported in the log if auto-accepted.
5) Regedit button will go to the nearest branch in the registry, if the key chosen does not exist.
6) Now shows exactly how many values and keys it is protecting, and when the definitions were loaded.

With the default keys, I get a 3% utilisation spike every 5 seconds in Windows Task Manager. Enjoy!

P.S. The purpose of MJRW is to make every PC in the world safer, without too much hassle in terms of maintenance.

 

Hi Graphic,

I started to send a thank you earlier today, and discovered yet another version is hot off the press. The effort you've given to this project and the result you've achieved are both quite exceptional. For the number of keys being monitored now, the performance seems very snappy. Please rest assured that all of my PC's feel much safer with MJRW protecting them.

Hope you have some time to rest now, enjoy yourself, take a holiday. You might even want want to try some turkey and cranberry sauce. Most everyone over here will be joining you soon!

Very best regards,
Mike

 

Ditto...