RegDefend Wishlist / New Features / Suggestions

Yes! And show the old and new values too for modifying values.
-hojtsy-

 

+1 for this one

 

No one has requested the ability to add comments to registry groups, which are shown in the ask user dialog, so I'll do so here, as a reminder

 

As cited before, it is currently cumbersome to drill down into the hierarchy when adding keys to a group. A few possible helpers might be:
..1) Reopen the registry tree control already expanded to and focused on the last point at which it was used.
..2) Integrate a bookmarking feature.
..3) Add a button to the tree control screen: [Jump to key in cllipboard]
..4) Add a right-click, "Jump To" under "Registry Items and Rules" (helps when you want another key in close proximity).

 

I'd like to suggest a new popup screen to simplify specifying a range of possibilities for protection under one key. It would allow a user to specify default behavior under that key as: "Allow", "Block" or "Prompt". Behavior for individual values or subkeys could accept the "Default" or could override it. A very rough sketch might look like this:

Code:

---Add new values           [Block]  [Allow]  [Prompt]
---Add new subkeys          [Block]  [Allow]  [Prompt]

---Modify Values (default)  [Block]  [Allow]  [Prompt]
Existing_value_1            [Block]  [Allow]  [Prompt] [Default]
Existing_value_2            [Block]  [Allow]  [Prompt] [Default]

---Modify Subkeys (default) [Block]  [Allow]  [Prompt] 
Existing_subkey_1           [Block]  [Allow]  [Prompt] [Default]
Existing_subkey_2           [Block]  [Allow]  [Prompt] [Default]

This dialog could popup when the user presses [ADD] after drilling down the registry for a new key. It could also be used to modify those same items when accessed from "Registry Items and Rules". This popup might also be useful if it can be made available from the "Allow/Block Alert popup" when RD has detected a change.

Although I think this dialog would save time and would better organize what are now multiple entries, it does create some new questions. For starters, how would the current detail summary for each key (at the bottom of the "Registry Items and Rules" pane) be displayed. With everyone's input I'm sure something would be found, but I think the dialog itself is the first chunk to consider.

EDIT: I just realized I didn't address specification of "read-protect". Perhaps adding buttons labeled "[Hide All Values]" and "[Hide All Subkeys]" which would grey-out (de-activate) the corresponding half of the controls that follow, then adding a "[Hide]" button to individual values and subkeys as well. I'm assuming that read-protected must also imply write-protected (can't update what you can't see).

 

I would like to echo the opinion that import/export would be a great configuration tool. I'd recommend the format be ascii and that it should be easy to read/edit/merge manually. I think import/export operations should be granular with respect to Registry Groups. Multiple groups in one ascii file sounds fine, so long as unnamed groups remain unaffected. One group per file sounds equally fine. As a convenience when importing a group with existing entries, perhaps RD could ask whether to clear all existing entries before adding the new list.

I suspect there will be an ongoing process of redefining the various forms that protection under one key might take. For that reason, Jason, you may want to design import/export with an eye toward flexibility and/or you may want to wait a while before designing something.

 

Agreed! These two requests go hand-in-hand.

 

Import/Export is the other critical feature for me. I would recommend using Unicode since I believe the Registry already uses this format.

 

Multiple selection of registry keys to protect, all in one go.

 

Agreed, I should have asked for Unicode.

 

RegDefend already stores it in UNICODE, so that aspect is covered.

In regards to import/export, could you please refine this a little bit? The way I designed it, was so that people could create new "registry groups" then share them with other people. Basically an "import/export" just by coping and moving a file in your groups directory.

 

By import and export I was thinking of a file that I could open in a text editor rather than being forced to use your GUI interface, the format would have to be able to represent NULL values (seeing as they can appear in key names) and still be editable with a run of the mill editor

A file like this (or parts of it) could easily be pasted into a forum post because it has a text basis, it is also something that could be kept under version control etc

It would be good to have a command line version of the export and import functionality, it would need to either prompt for a password or have a password passed in on the command line, that way a shortcut or a batch job could allow settings to be easily changed for different uses

It would be nice to be able to specify a different bunch of settings "per user" on the machine as well, this is something that could be done in your interface or by a startup job that runs during login..

I'll have a think about it a bit more, but that was the basic purpose of export and import, the ability to share with others in a readable way and being able to swap and change settings easily

By making the export format able to be easily parsed it means that other things can be done with it that have not yet been anticipated

Thanks

 

Thanks to gottadoit, the virtues of text-based import/export have been well named. I had not been aware, however, that the current implementation of RD allows groups to be added, removed and backed up as individual files. It may not be perfect, but it's very helpful. Exchanging groups would still be pretty limited, though, unless RD provides a way to move items from one group to another group. Otherwise, any reorganization requires doing the mouse dance through the registry maze.

You may, actually, be close to what I was hoping for if you can add just enough formatting and structure to make a .ghst file editable. For instance, insert a newline between items (plus one blank line if an item spans multiple lines). And while there may be programs that recognize the contents of .ghst files as text, everything I tried displays a .ghst as half-null-text (Notepad, EditPad Lite, Wordpad, Vim). Perhaps some self-identifying characteristic of unicode (or of its ISO?) is missing.

 

Likewise, thanks to gottadoit for the explanation of text based import/export.

A Byte Order Marker (BOM) is required to crrectly identify a file as being Unicode/UTF.

 

that is what I meant regarding importing values.

sorry for not making it more clearly.

Inf.

 

A vote for group and key description.
Jason has already written himself about being able to add a description per group, and I would go further by being able to add description per key in one group, it would be a lot more user friendly to read :

"HKLM\sdfsdf\sdfdsf\df5z4er51ez41r\qdzae | *ALL_VALUES* | protect network config"

do you see my point ?

 

Make the column headers clickable/sortable on the "Add registry item" window.

BTW, why don't you use the standard Windows controls for the UI ? (eg. buttons, lists etc.)

 

Make a French version of Regdefend...

Atomas31

 

I think the scope of RegDefend should be expanded to include generic support for protection of file and folders. Surely this wouldn't be too hard to implement since it could use the same/similar hook-based technology used for the registry protection. I'm not totally sure how this hook-based thingy works, but if it's possible to access the path of the file to be modified/read, then generic support would be easy to add since it could just check the path against a list of protected files/folders.

This would make RegDefend (maybe a new name would be in order too ) much more desirable as a product IMHO.

Don't get me wrong, RegDefend is a great product which is currently unique in the marketplace, but people who already own a product like Ad-Watch/TeaTimer will probably be reluctant to purchase a new product unless it had something like generic file/folder support as well.

 

I don't think Ad-Watch has any protection options incorporated for changes to files and folders. AdAware scanner tests/checks these for spyware, etc., when a user scans with AdAware, but the resident Ad-Watch module only "stops suspicious processes" when it scans memory. I may be wrong, but that's my interpretation of Ad-Watch.

 

You're right siliconman01, it doesn't protect files/folders. My point was that Ad-Watch has several features, including registry protection (although it's after the fact, and specific), whereas RegDefend only offers protection against the registry. While the registry protection offered by RegDefend is greater than that offered from any other piece of software, people who have Ad-Watch might be reluctant to pay for the extra protection offered by RD when it only does a single job, albeit well.

I don't have the sales figures for RD at hand, but I would hazard a guess that adding generic support for file/folder protection (both read and modification) to RD would make it a much more attractive proposition in the marketplace. While RD is the best at what it does, I think RD is too limited in it's scope to attract widespread appeal.

I don't agree with software becoming bloated and supporting every feature under the sun, like some companies seem to offer. However, I think generic file/folder protection would be a great addition to RD and would not be considered bloat.

 

Some sort of application verification needs to be included so that someone doesn't replace a "trusted" application with a trojan and neatly sidestep the registry security that we think is in place. As Jason pointed out (a little while ago when I discussed this with him), threats will come from DLL's as much as the main executable, so this suggestion has already had a little bit of feedback

It would be very useful to have an extra button on the alert window to optionally collect and display information about the executable and what piece of code generated the alert. This could show if the code is in the main executable or in a DLL, show the module name and a stack trace. This is nice in that there is no runtime cost and the information can be easily gathered for forensic purposes. If this is done it would be good to also be good to optionally be able to log it to the RD logfile.

On the protection side of things, make this an option to allow verification for applications so if something else is doing this already it can be left off in RegDefend (and avoid any overheads)

If the end-user wants application verification to be on, then allow several levels of verification (with increasing overheads as the checking becomes more comprehensive)

Level #1 - simple executable verification
- executable image checking would be performed once for each PID (ie: running instance of a program) and would be performed on the disk image at the time of the first registry interaction

Level #2 - simple executable and static dll verification
- same as #1 for executable - once per running instance of a program
- statically linked dll's would be checked once for each PID

Level #3 - dynamic executable/dll verification
- potential to create a lot of overhead for little reason
- has potential to be useful at times, especially when dealing with unknown executables
- same as #1 for executable - once per running instance of a program
- same as #2 for static dll's
- on every registry access, check which module the access is coming from and if that dll has not been verified and accepted for this PID then raise an alert

By implementing the level 1 check it would be "better than nothing", the level 2 check is much the same and would help by alerting when programs are updated. The level 3 checking might be useful when ppl are feeling paranoid and/or wondering if something funny is happening

And as I mentioned earlier if you use a hashing scheme that is different to the other tools in common use, then your hash could well provide additional value (and peace of mind) for the overall security on a particular PC

 

I agree 100%. On my test machine (virtual PC) I have an example where a certain Peer to Peer installation application attempts to install a bunch of malware into the start group run keys in the registry. Regdefend does a wonderful job stopping all of these attempts because it intercepts the attempt before it happens, unlike other so-called "real time" applications that don't catch them until it's too late.

The problem is, this installation file also installs a couple of items into the Start Menu "Startup" folder - and this is NOT protected by Regdefend. Now here's the trick: when you reboot the machine, during the start-up one of these Startup menu items is able to add an entry to "HKLM\Software\Microsoft\Windows\CurrentVersion\Run"
BEFORE Regdefend has had a chance to initialize and catch it! This surprised me but make sense I guess.

So I agree, it would be very nice if Regdefend could protect at least the Startup folders. And generic file/folder protection would be a fantastic addition to Regdefend....

 

New feature request: Block/alert any attempts to add hidden registry keys to the registry. I understand that Regdefend already will block hidden registry keys, but only if they are being added to registry locations that Regdefend is protecting.
What I'm asking for, is to generically block/alert for all hidden registry key attempts anywhere.

 

jimmytop,
This request should already be covered by what Jason has (kind of pre-) announced
Jason has already said that he is implementing regular expressions in one of the up and coming point releases
So as long as a NULL vallue can be represented in a pattern (and there is no reason to believe that Jason would turn a blind eye to this) it will be able to be monitored

A pattern like .*\000.* would catch a key with a NULL in it (where .* is zero or more of any character and \000 is a NULL)

NB: I'm sure that some apps also embed newlines or cr's into names as well...