MJ Registry Watcher

Graphic,

It is much better. The light setting only registers between 5% and 8%, which is OK with me. However, the Max setting is still to rich for my tastes. See pic.

 

Actually the HKCU name is just a convenience feature, it do not have its own storage location. This is the same concept as applied by the "My Documents" folder, where the icon and shortcut always points to the "My Documents" folder of the current user, but each user have it's own storage location.

It is all about balancing security and performance. You can replace every HKCU with HKU/? ? ? to monitor those keys in the subtree of every user. But that needs processing power. Usually it is enough to monitor the subtree of the current user, because it is very rare to have a trojan attack other users' settings.

My short advice is: do not monitor the same key in HKU/? ? ? and HKCU, because that is redundant. What would be convinient for the user? Maybe a GUI simmilar to this:
HKLM HKCU HKU
[* ] [* ] [* ] \Software\Microsoft\Windows\CurrentVersion\Run
[* ] [* ] [* ] \Software\Microsoft\Windows\CurrentVersion\RunOnce
[* ] [. ] [. ] \Software\Microsoft\Windows\CurrentVersion\RunEx
[. ] [* ] [. ] \Software\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects
[. ] [. ] [. ] HKEY_CLASSES_ROOT\Protocols\Filter

HKU would mean All Users, so HKU/? ? ?
There would be three rows of checkboxes where you can enable monitoring of that key for certain subtree. Hmm but this would make copy-pasting of key list into other applications quite problematic. I have to think more about this.
In the meantime I will work on finding duplicates in your files.
-hojtsy-

 

Daisey,
How did you get a "Task Manager" view of just RegWatcher on its own? The utilisation figure I was quoting is from Windows Task Manager, under the Processes Tab, on the RegWatcher.exe line (currently 2% on the default set). Also, what are your figures for different configs? I would be interested since the Celeron is the usual entry-level CPU, and I can better gauge utilisation issues. TIA.

Hojtsy,
1) Performance is not an issue any more. I am quite willing to convert all HKEY_CURRENT_USER keys to HKEY_USERS\ keys. However, I am now getting thoroughly confused, since there are keys that are on these two branches *AND* HKEY_LOCAL_MACHINE. I read somewhere that the registry HKLM keys are usually launched before and in addition to the corresponding user key. So, HKLM keys must be monitored, and either HKEY_USERS\ or HKEY_LOCAL_MACHINE must be monitored.
2) Amidst all the duplication in the current key lists, I tried hkey_users\\control panel\desktop and eliminated the current user counterpart. The number of values and subkeys increased slightly, but monitoring is still smooth. What HKEY_CURRENT_USER keys still need to remain in place (aside from the hkey_lmcu keys, which are staying as they are, if we substitute HKEY_USERS\ instead? In fact, should we replace hkey_lmcu with hklm+hku, and completely eliminate hkey_current_user from all lists? This seems the sensible thing to do, since we don't have to worry about performance anymore? Is this feasible?

 

Some keys are loaded only from HKCU, some only from HKLM, some from both. It is a case-by-case information, and you need thorough research and testing to find out. I suggest to rely on my list until you find a better source for this information.

For Highest security level, I suggest the following changes.
hklm --> leave as hklm
hkcu --> hku
hkcu+hku --> hku
hk_lmcu --> hklm + hku (call this hk_lmu?)
As you see no hkcu remains. But for Low, and Default security levels I suggest leaving hkcu, and removing hku. For High security level, only the most important and frequented entries could be converted to hku, and hk_lmu.

I do worry about performance. 1.2.2.4 produces 8% utilization pulses with default configuration on my system, eating more than any registry monitor before. I am aware that this is mostly caused by better coverage, but I think we should continue to be looking for performance improvement options.

Since I prefer to continue running TeaTimer, because of it's SpyWare killing features, it would be usefull to construct a TeaTimer-complementing key list, which would list only the keys not already covered by TeaTimer. What do you think?

-hojtsy-

 

Sounds good to me if it can be done

 

Hojtsy,
I have put this together - it covers all of your key list (hkey_lmus is the same as hkey_local_machine plus hkey_users\)

%bootdrv%autoexec.bat
%bootdrv%config.sys
%bootdrv%explorer.exe
%bootdrv%ntdetect.com
%bootdrv%ntldr
%programfiles%internet explorer\iexplore.exe
%system%autoexec.nt
%system%config.nt
%system%hal.dll
%system%lsass.exe
%system%ntoskrnl.exe
%system%winlogon.exe
%system%ntdll.dll
%windir%explorer.exe
%windir%dosstart.bat
%windir%system.ini
%windir%win.ini
%windir%wininit.ini
%windir%winstart.bat
hkey_lmus\software\microsoft\windows\currentversion\run
hkey_classes_root\*\shellex\contextmenuhandlers
hkey_classes_root\\shell\open\command
hkey_classes_root\protocols\filter
hkey_classes_root\protocols\filter\class install handler
hkey_lmus\software\microsoft\command processor
hkey_lmus\software\microsoft\internet explorer
hkey_lmus\software\microsoft\internet explorer\extensions
hkey_lmus\software\microsoft\internet explorer\extensions\cmdmapping
hkey_lmus\software\microsoft\internet explorer\abouturls
hkey_lmus\software\microsoft\internet explorer\explorer bars
hkey_lmus\software\microsoft\internet explorer\main
hkey_lmus\software\microsoft\internet explorer\menuext
hkey_lmus\software\microsoft\internet explorer\search
hkey_lmus\software\microsoft\internet explorer\searchurl
hkey_lmus\software\microsoft\internet explorer\styles
hkey_lmus\software\microsoft\internet explorer\toolbar
hkey_lmus\software\microsoft\internet explorer\toolbar\shellbrowser
hkey_lmus\software\microsoft\internet explorer\toolbar\webbrowser
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
hkey_lmus\software\microsoft\windows nt\currentversion\windows
hkey_lmus\software\microsoft\windows nt\currentversion\winlogon
hkey_lmus\software\microsoft\windows nt\currentversion\winlogon\\\dllname
hkey_lmus\software\microsoft\windows nt\currentversion\winlogon\gpextensions
hkey_lmus\software\microsoft\windows nt\currentversion\winlogon\notify
hkey_lmus\software\microsoft\windows nt\currentversion\winlogon\taskman
hkey_lmus\software\microsoft\windows
hkey_lmus\software\microsoft\windows\currentversion\explorer
hkey_lmus\software\microsoft\windows\currentversion\explorer\shell folders
hkey_lmus\software\microsoft\windows\currentversion\explorer\user shell folders
hkey_lmus\software\microsoft\windows\currentversion\policies
hkey_lmus\software\microsoft\windows\currentversion\policies\explorer\run
hkey_lmus\software\microsoft\windows\currentversion\policies\system
hkey_lmus\software\microsoft\windows\currentversion\policies\system\shell
hkey_lmus\software\microsoft\windows\currentversion\runonce
hkey_lmus\software\microsoft\windows\currentversion\runonce\setup
hkey_lmus\software\microsoft\windows\currentversion\runonceex
hkey_lmus\software\microsoft\windows\currentversion\runservices
hkey_lmus\software\microsoft\windows\currentversion\runservicesonce
hkey_lmus\software\microsoft\windows\currentversion\runservicesonceex
hkey_lmus\software\policies\microsoft\windows\system\scripts
hkey_lmus\software\policies\microsoft\windows\system\scripts\logoff
hkey_lmus\software\policies\microsoft\windows\system\scripts\logon
hkey_lmus\software\policies\microsoft\windows\system\scripts\startup
hkey_lmus\software\policies\microsoft\windows\system\scripts\shutdown
hkey_local_machine\software\classes\batfile\shell\open\command
hkey_local_machine\software\classes\comfile\shell\open\command
hkey_local_machine\software\classes\exefile\shell\open\command
hkey_local_machine\software\classes\htafile\shell\open\command
hkey_local_machine\software\classes\piffile\shell\open\command
hkey_local_machine\software\classes\protocols\filter
hkey_local_machine\software\microsoft\active setup\installed components
hkey_local_machine\software\microsoft\active setup\installed components\\stubpath
hkey_local_machine\software\microsoft\code store database\distribution units
hkey_local_machine\software\microsoft\windows nt\currentversion\accessibility\utility manager\\application path
hkey_local_machine\software\microsoft\windows nt\currentversion\explorer\advanced
hkey_local_machine\software\microsoft\windows nt\currentversion\svchost
hkey_local_machine\software\microsoft\windows nt\currentversion\windows\appinit_dlls
hkey_local_machine\software\microsoft\windows nt\currentversion\wow\boot
hkey_local_machine\software\microsoft\windows\currentversion\app management\arpcache
hkey_local_machine\software\microsoft\windows\currentversion\explorer\advanced
hkey_local_machine\software\microsoft\windows\currentversion\explorer\advanced\folder
hkey_local_machine\software\microsoft\windows\currentversion\explorer\browser helper objects
hkey_local_machine\software\microsoft\windows\currentversion\explorer\sharedtaskscheduler
hkey_local_machine\software\microsoft\windows\currentversion\explorer\ShellExecuteHooks
hkey_local_machine\software\microsoft\windows\currentversion\internet settings\safesites
hkey_local_machine\software\microsoft\windows\currentversion\runex
hkey_local_machine\software\microsoft\windows\currentversion\shellserviceobjectdelayload
hkey_local_machine\software\microsoft\windows\currentversion\url\defaultprefix
hkey_local_machine\software\microsoft\windows\currentversion\url\prefixes
hkey_local_machine\software\policies\microsoft\windows\safer\codeidentifiers
hkey_local_machine\system\currentcontrolset\control
hkey_local_machine\system\currentcontrolset\control\mprservices
hkey_local_machine\system\currentcontrolset\control\session manager
hkey_local_machine\system\currentcontrolset\control\session manager\filerenameoperations
hkey_local_machine\system\currentcontrolset\control\session manager\knowndlls
hkey_local_machine\system\currentcontrolset\control\wow
hkey_local_machine\system\currentcontrolset\services
hkey_local_machine\system\currentcontrolset\services\\imagepath
hkey_local_machine\system\currentcontrolset\services\vxd
hkey_local_machine\system\currentcontrolset\services\vxd\javasup
hkey_local_machine\system\currentcontrolset\services\winsock2\parameters\namespace_catalog5\catalog_entries
hkey_local_machine\system\currentcontrolset\services\winsock2\parameters\protocol_catalog9\catalog_entries
hkey_local_machine\system\currentcontrolset\services\winsock2\parameters\\\\librarypath
hkey_local_machine\system\currentcontrolset\services\winsock2\parameters\\\\packedcatalogitem
hkey_users\\control panel\desktop
hkey_users\\control panel\desktop\scrnsave.exe
hkey_users\\software\microsoft\windows\currentversion\explorer\fileexts
hkey_users\\software\microsoft\windows\currentversion\explorer\fileexts\\application

and this comes out at
Loaded 1,515 Values (133K) and 1,067 Subkeys (13K) and 19 File Stats
but utilisation is still at 2%, whatever I load now.

What do you think? Did I omit anything? Are you all ready for version 1.2.2.5?

 

Hojtsy,
Could you please let me know what the utilisation spikes are for each configuration with version 1.2.2.4, and what your PC CPU spec is?

To measure this, I have been using Windows Task Manager, Processes Tab, RegWatcher.exe line, and looking at the utilisation percentage on that line alone. With unreleased (as yet) version 1.2.2.5 and every machine I have tried, I am getting less than 5% utilisation, whatever set of keys I load. Similar results should come from version 1.2.2.4, although not quite as good.

TIA,

 

The list seems OK to me.
My CPU is Pentium 2200 Mhz, 7 user subtrees under HKU, Win2k, utilization spikes are:
Highest Security: 1 451 Values (94K) and 825 Subkeys (13K), 22-20% spikes
High Security: 1 119 Values (87K) and 825 Subkeys (13K), 20-19% spikes
Medium Security: 695 Values (61K) and 825 Subkeys (13K), 10-6% spikes
Default Security: 539 Values (54K) and 1 074 Subkeys (15K), 7-6% spikes
Light Security: 456 Values (51K) and 964 Subkeys (13K) , 6-5% spikes

Note that Light security loaded more subkeys then Medium!! Also compare numbers for Medium and Default. Suprising enough! After the lists are tidyed up maybe you could rename the Default to Low?

-hojtsy-

 

Version 1.2.2.5 is now available from http://www.jacobsm.com/index.htm#sft

Changes 1.2.2.4 to 1.2.2.5
1) Made monitoring loop even lighter on resources, and made sure that you can't do things while it is in the monitoring loop, unless they are allowable (browse help file...).
2) Changed program close operation to allow clean closing during a monitoring loop.
3) Added mnemonic hkey_lmus to mean both keys hkey_local_machine and hkey_users\.
4) Got rid of duplicates between current user and all users in the keys lists and tidied them up.

There is now no such thing as "current user" - it's either all users or local machine!

Hojtsy and Daisey,
I would like some feedback on the resource utilisation issue please. I have tried this version 1.2.2.5 on a Celeron 1.8GHz PC on the full set, and MJRW never peaked higher than 5% usage. Please let me know if this version helps you run higher security sets more easily. TIA,

 

I'm using Process Explorer.

I'll do that and get back to you...

 

Using ver 1.2.2.4, and switched to Windows Task Manager.

Highest Security: 1,356 Values (123K) and 965 Subkeys (13K), 19%-25%
High Security: 1,202 Values (120K) and 965 Subkeys (13K), 13%-25%
Medium Security: 890 Values (100K) and 965 Subkeys (13K), 11%
Default Security: 648 Values (88K) and 1,288 Subkeys (16K), 11%
Light Security: 535 Values (85K) and 1,157 Subkeys (15K), 8%

Hope this helps!

 

Using ver 1.2.2.5

Highest Security: 1,521 Values (133K) and 1,013 Subkeys (13K), 14%
High Security: 1,209 Values (113K) and 1,013 Subkeys (13K), 14%
Medium Security: 894 Values (99K) and 1,139 Subkeys (15K), 8%
Default Security: 628 Values (33K) and 1,045 Subkeys (13K), 11%
Light Security: 535 Values (85K) and 1,157 Subkeys (15K), 2%

I know your not going to believe this, but I'm finding the Medium security setting takes less than the Default setting. I went back and forth three times. Strange...

 

Hi,
One more redundant pair:

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

The "shell" is a value in the "boot" key, so it is already covered by the first line. One of these lines should be removed.

Another redundant pair:
hkey_lmus\software\microsoft\windows nt\currentversion\windows\appinit_dlls
hkey_local_machine\software\microsoft\windows nt\currentversion\windows\appinit_dlls

Note that it do not seem necessary to monitor appinit_dlls in the HKU branches, as it is not loaded from there.
-hojtsy-

 

Hi, just chiming in with a performance note. Version 1.2.2.5 is noticeably quicker on my main internet machine, but the situation is more "interesting" on the P3-800 laptop I use as a testbed. I wondered if some of the confusion about CPU usage may come from reading taskmgr.exe at different values of View->Update_Speed. For this test, I calculated RW's "overall CPU usage" by setting Update Speed to Low, and keeping a running average of its usage. I calculated RW's "CPU spikes" by setting Update Speed to High, then summing values that were obviously part of the same five-second sweep. Theoretically, this should yield the CPU percent required to do the entire sweep in a single, uninterrupted, half-second timeslice. All tests were done with RW 1.2.2.5's default key list monitoring 442 Values (70K) and 610 Subkeys (8K).

I'm currently trying different AV products on the laptop Last night I was trying to reduce system contention between BOClean and F-Prot. On top of this contention, I added RW 1.2.2.5 to the mix. At idle, CPU usage for the entire system was about 24%. In that environment, the RW process registered CPU spikes that were never less than 64%. Some spikes went much higher (when BOClean was doing a simultaneous sweep) and stretched across several half-second intervals. RW's "overall CPU usage" at this time was almost 7%.

After I had managed to reduce the contention between BOClean and F-Prot, the numbers looked much different. The system's overall CPU usage was just over 3%, and RW's overall CPU usage was less than 2%. RW's CPU spikes were consistently 12%. The system was now relatively smooth and responsive.

In general, I'm guessing that some types of contention can cause a huge difference in the CPU requirements of RW (or at least what taskmgr reports). For instance, if hojtsy is running tea timer concurrently, of if Daisey is running some combination from her portfolio as realtime monitors, the interaction between RW and other "monitor" programs may have a suprising impact on the CPU usage being attributed to RW alone.

Big kudos on v1.2.2.5, I think it's measurably better. Also, I think the effort to resolve key duplication and to prioritize keys at different levels of security is exactly what is most needed. Thanks, everyone, for all that you're doing.

 

Some newbie questions:

1. Can MJRW be started automatically, or does the RW.exe file need to be dropped into Startup?

2. Can the settings be remembered, ie. I have chosen Highest, will it remember this after the next bootup.

3. Is it possible to stop it exiting when hitting the close button instead of minimize button, so that it returns to the system tray?

4. It is not installed into Program Files, is this correct?

No doubt more questions to come...

Cheers

 

In answer to Blackspear's questions,

1) You have to make a shortcut to RegWatcher.exe on your desktop. Then drag that into the Startup menu under the programs menu. You have to drag it to the Start button, and then let that popup, and keep draggin it to the start up folder on the programs menu.

2) To overwrite your custom set with the highest set, simply go to the installation directory, and copy MJRegWatchKeys.1 over the file MJRegWatchKeys.txt (overwriting it). Since it always starts up with the custom set, it will use the copy of the highest security set you have made as your custom set.

3) That old chestnut. As it turns out, no, you just have to be careful. As a user of ZoneAlarm, I can see where you're coming from, but I find it awkward to close ZA, so I'm keeping MJRW as it is.

4) MJRW does not go into any folder except the installation direcory. It also makes no registry entries whatsoever. Everything is read and written either in the installation directory (or subdirectories), the registry, or the memory of the PC.

I hope that helps.

 

It does indeed, many thanks for your prompt reply, I'm just starting my journey of playing with it now, been watching this thread grow for a while

Cheers

 

In answer to Earth1's intriguing post,

The interaction of various programs that are also reading the registry, strikes me as a valid consideration when measuring performance.

<It gets technical here>
I found that the performance problems were caused by the speed that C++ can execute a loop in. I had to slow it down somehow, and I have used a Windows API function called Sleep(msecs). It turns out that the way this performs on different processors with different set-ups is unreliable when the time is small, say less than 100 milliseconds. I want to use Sleep(20) in my loop, which works on all the processors I've tried. But I don't think it works very well on older processors. I am currently using a special Win32 function in my delay routine that wraps the Sleep function :-

void mjdelay(unsigned int msecs)
{
unsigned int nw;
timeBeginPeriod(10); nw=timeGetTime();
do { Sleep(10); Application->ProcessMessages();}
while (timeGetTime()-nw<msecs);
timeEndPeriod(10);
}

The "Application->ProcessMessages()" bit allows the user interface to steal some processor time to get things done (like scrolling or showing a window), before the loop continues. I use this function in other programs, and the utilisation for them is very small, typically 3%.

My alternative lines of thought have come into focus on another possibility. If I can get the PC to use a multi-media timer, which can usually cope with delays as small as 5ms, it could activate the checking for each key in turn, so that a sort of low-level continuous check would be going on. I would need to experiment with this design idea, and add a command line switch so that the delay can be changed - something like

RegWatcher.exe -t50

which would launch RW with a 50ms delay between each key checked.
</It gets technical here>

 

Hi Blackspear,

If you're still experimenting with ProcessGuard, you can include regwatcher.exe in PG's Protection List, then select it in PG's Protection tab and enable "Secure Message Handling". After you've done that, accidentally clicking MJRW's close button will cause PG to verify that you really want to close MJRW. I've configured PG/MJRW this way on my system. Even if I didn't want "Secure Message Handling", I would still have MJRW protected.

 

Many thanks for this Earth1, onto the case now, I'm also learning the capabilities of PG3, of which you have added something to my very little knowledge of one impressive program

Cheers

 

Works beautifully

Many thanks...

Cheers

 

Glad to help, Blackspear. You're quite right about ProcessGuard, and I think we're onto another gem in MJ Registry Watcher. They both do one thing, and do it very well.

Cheers

 

Agreed, it looks really promising, rather impressed

Cheers

 

I have tried some experiments with the loop in MJRW, and have found that we are already using the best method. I have tweaked this to produce 0% utilisation with the highest set of keys, and Task Manager registers less than 1 second per hour of CPU time used up!!!

There does appear to be an issue with older PCs, although I have never experienced this myself. I am relying on Hojtsy and Daisey's reports. I am redoing the key lists to cut out duplicates, and will release a very slightly improved 1.2.2.6 soon (possible tonight if the tests work out on my home PC). This version and its key lists will rely on a PC timer granularity of 10 milliseconds or less - if your PC cannot handle that, then you'll have to use reduced key lists. What this means is that when I ask the PC to relax using MJRW for 10ms, some (older) PCs return immediately, rather than wait for 10ms, because they cannot time so small a fraction of a second. This means the PC does not relax, and utilisation is comparatively higher than newer PCs which have the finer granularity. Another surprising thing is that both Hojtsy and Daisey report strange figures for their key lists - I can only advise that they scrap what they've got and reinstall the current key lists to see if it still so.

 

I have just released version 1.2.2.6 of MJRW at http://www.jacobsm.com/index.htm#sft

Changes 1.2.2.5 to 1.2.2.6
1) Fine-tuned loop to use minimal CPU pressure.
2) Further refinement of the key lists.
3) Corrected bug with Stop button. If it was pressed during the loop, it would toggle the display incorrectly, and not stop. Now, it will do nothing unless pressed when the loop is not running.

I have tested it on my 1.4 GHz AMD Athlon PC and a 2.8GHz P4 HT, without any other registry checking programs running (like TT, PG ...), and I am getting a flat zero utilisation, whichever set I load!