Few questions from noob

Hello. Interested in few technical details.

1) Message handling. I've been searching through this board and I read in some place something to the effect that Process Guard protects itself by verifying the windows messages are generated by user interface device. Is it fully secure and adequate protection without some kind of "turing code" challenge, does it mean that PG itself is protected from unauthorized changing of critical parameters like "Learning mode" enabled disabled etc?

2) I read that PG itself is not exactly the tool to protect from on-disk modifications, but some degree of protection is present nonetheless. Can it be clarified? As I read it, database of hashes is kept, what happens if registred executable with already set permissions fails to match on loading? This is pretty uncommon condition that .exe-s change like that, unless deliberately patched by user, will there be some kind of noticeable critical alert?

3) Secure messages for other apps and that "INSERT" key thing. In an older thread I found it was asked but wasn't clearly answered. This "INSERT" thing does not seem to work. Is it "not implemented" yet? What about that user interface device thing, does the "secure message handling" option enables the same thing for aps? Say, what I'm concerned about, I'm using Agnitum Outpost firewall and its protection can be disabled with a few clicks - changing its policy to "disabled" or something else. It's even more dangerous than just exiting from its user interface I think, because then (I guess) the kernel module continues its job. In the paranoid mode of thinking, can somebody exploit this by I don't know, sending some kind of WM_COMMAND message or something like that to the agnitum process? "INSERT" key thing seems to address this, but I can't get it to work - I hold it and change the policy to disabled and nothing happens.

If somebody can answer this - big thanks. You can be as technical as you want - if there will be some unfamiliar concepts I can read some stuff on msdn or in DDK docs.

 

1. The secure message handling is for closing or exiting programs. If you re-read the thread about using the insert key you will note it does say other methods of CLOSING the programs. The secure handling adds the additon of human intervention required. If the the window close is triggered then an additional layer comes into play just like when you registered for the forum.

2. If an executable changes, you get a prompt informing you of the fact. "This program has changed since the last time you used it!" You are given a choice to allow it, always allow it and with the lastest versions you can also ignore the changes.

3. Changing the firewall policy to disabled does not generate windows close messages so that will not work. You can use the secure message handler for exiting the firewall. If you desire to prevent changes to the firewall settings, then it is best to use the built in password protection.

 

Maybe I missed something, unfortunatelly I already forgot which particular thread it was. As far as I can remember, it discussed window close/destroy messages but did not address the help file information about ANY messages and INSERT key usage, and what is the status of that feature.

I mean this:

-From help file.

It sure does create an impression any menu item can be protected (why not btw, if PG can intercept one message then it probably can also do the same for another). But looks like it's a "to do" or, on the contrary, dropped feature or something?

Btw what about PG's own user interface - is it true that it's protected from "user imitation" attacks by verifying that the user input-related message sent originates from some human interface device / interactive input device, not an "imitating" malicious code?

 

This feature is experimental, and adds minimal support in terms of real world security. SERVICES do not have windows, nor do drivers. You can't stop AV protection with an attack like this, you can't stop PG protection, firewall.. anything useful. Just close a window, some unprotected code running in user space.

You can use the insert key to as it stands to secure any message yes, these are stored when you activate the feature. Close Message Handling as a whole does however by design have flaws in that some types of programs generate a lot of junk windows and close them at strange times. This is unavoidable, just don't use the feature on those programs..

The interface in 3.300 Beta 2 is now also be secured against changes to other settings, you are prompted when you try to change them. This is a minimal improvement in real terms again, but again it's there there "just because"

 

I'm probably oversimplifying this, but I'd just like to mention that I believe that it's possible to differentiate between the top-level window of an application and its child windows.

For example, here's a BASIC function that I use in an unrelated project:

Code:

Public Declare Function GetAncestor Lib "user32.dll" (ByVal hwnd As Long, ByVal gaFlags As Long) As Long

Private parentHandle


Function isChildWindow(ByVal currentHandleArg)

     Const GA_PARENT As Long = 1
     Const GA_ROOT As Long = 2
     Const GA_ROOTOWNER As Long = 3

     parentHandle = GetAncestor(currentHandleArg, GA_ROOT)
     isChildWindow = currentHandleArg <> parentHandle

End Function

 

Although that is true, children windows should be protected aswell ... you can potentially make the app useless by closing all child windows . A better way may be to have PG use the windows class / title within the context of the protected process, but this will require a LOT of fine tuning assuming it were implemented . Not sure how that would even work for those that randomize both

This sounds a lot like the BN_CLICKED 'sub-message' of WM_COMMAND ... anyone care to verify?

 

I don't see why it's necessary to protect child windows because, as I understand it, the purpose of "close message handling" is to prevent malware from closing an application completely, not to monitor every possible dialog box that an application shows.

Besides, it seems that the main complaints about PG in this regard are that people don't want CMH to react to child windows -- only to the top-level window itself.

If we have to also specify the window title/class, then that seems like unnecessary effort on our part. I'm wondering if there is a specific example from a real-life application where this would be necessary.

 

However, I do understand your point. Malware should not be able to simulate keyboard or mouse events in any windows of our applications.

Perhaps CMH should be changed to a broader scope and use low-level Windows APIs that verify that the user is actually using the physical keyboard/mouse to interact with the application instead of being simulated by software. This way the Insert-key stuff might become obsolete.

If implemented, I would want this protection to only apply to certain high-risk apps because I frequently use keyboard/mouse simulation software to control some of my other apps.

 

For Outpost, it is possible to configure SMH to block attempts to change policy via the System Tray menu (see here for details). However it doesn't cover changes via Options/Policy (and this would be an easier route for malware) so password protecting is the only sure method.

As for child windows, this is highly application-specific but since they (almost) invariably have consistent window titles, adding a check for these within SMH should be quite easy. Expanding PG's UI to allow users to configure such child windows would be the greater difficulty.

 

The problem with using SMH with child windows is that people will have to maintain a list of window titles for each app that you protect with SMH (and the PG GUI might have to accommodate this). This is because, in addition to the child window(s), the top-level window would likely also have to be protected from "File > Exit", the X, etc. So people would have to maintain these lists of window titles in the GUI.

I see potential problems with this. If SMH-protected apps change their window titles/classes after a software upgrade, either in a subtle way or in a big way but you don't notice the change, it seems very unlikely that anyone would notice this. Then PG would no longer use SMH with that app and you might not notice unless you manually close the app and realize that PG didn't prompt you.

And in a more general problem not related to window titles, if people use the Insert-key thing to protect checkboxes in the app's settings or wherever, the SMH protection could also stop functioning if the names of some checkboxes change between software upgrades and again it's not certain that people would notice this.

So I continue to believe that the best solution would be to simply disallow programmatically generated keyboard/mouse input to the specified SMH apps. This would make SMH transparent, automatic, remove the need for us users to do anything with the Insert key, we wouldn't need to continually verify and maintain window titles/classes/checkboxes/etc., and we wouldn't have to manually see or close any more SMH dialog boxes when we close our security apps or shutdown Windows.

The only question in my mind is whether or not that's possible (e.g. by using DirectX's DirectInput API to verify that the keystrokes and mouse events were actually generated by a human rather than by software).

 

Hence my suggestion that users specify child windows to exclude from SMH - in most cases, only a few frequently-used prompts would need to be added and if their titles change, they just need to be re-excluded.

Disabling any means of automatic input aside from the real mouse and keyboard would remove the need for SMH, but would also likely conflict with legitimate software (keyboard/mouse drivers that allow button/key programming, legitimate Windows scripts, etc) so this would require exception handling also, plus more user expertise (compared to just entering a window title with SMH).

In addition, there is one further use to which SMH can be put - to provide password protection on applications. This would be useful on shared computers where the administrator wishes to prevent other users from closing certain programs (web filtering/censoring software for the little 'uns being a very good example). This would be a simple addition (SMH would prompt for a password rather than a 5-letter code) and would be, as far as I know, a unique feature for security software.

 

Most security applications can be closed via their system tray icon menus and custom SMH can be used to intercept this. It is tricky for malware to access these options via keystrokes but certainly possible.

One downside here is if you choose to disable the prompts, there is no way to re-enable them (aside from setting the HKLM\SOFTWARE\Diamond Computer Systems\ProcessGuard v3.0\Registered key to 0 - BTW this can be altered by other software while PG is running....). Adding checkboxes to the PG main window for these alerts would be a useful addition.

 

I'm not convinced that this would "require" exception handling and more user expertise. I, for one, would give up using any of my automation software in my most important security apps in exchange for better security and not having to type five-letter codes or passwords to change important settings or to close the apps. I agree, though, that it might be inconvenient to lose certain mouse features, for example scrolling with the scrollwheel.

I'm also wondering why people should need to use Windows scripts to send keyboard/mouse events to their security apps. Is there a need to run a batch job against a firewall, AV, etc.?

I agree that this would be much more useful (and easier) than typing a random five-letter code each time. It would also be useful for low-quality security apps that don't have a feature to password-protect their settings.

However, I would like it to be optional since all of the security apps that I use already allow me to lock their settings with a password. It seems to me that it's much easier to use each security app's own password feature than to use PG's Insert-key thing.

I think that you'd agree, Gavin, that most security apps can be disabled by opening their GUIs and deselecting checkboxes. I think that a problem exists as long as PG continues to allow programs to programmatically send keystrokes and mouse events to our security apps. Since you have implemented something like SMH, why shouldn't it also protect us against this?

It seems that everything would be a lot easier and simpler if we didn't need to try to handle every possible keyboard shortcut and mouse click in every relevant settings window and systray icon of every security app. The Insert-key thing seems like an unmanageable or at least inconvenient solution, especially for the average user. Since it requires extra effort it's less likely to be done thoroughly and correctly, if done at all.

 

This would be rare but trying to isolate keyboard/mouse events that affect security software only is the challenge and custom SMH is the best way PG can address this.

This should certainly be optional and likely of no use to standalone systems. However as an option for those who share their PC with (partially) untrusted users, it could be valuable.

PG's main interface cannot be controlled by keystrokes (with the exception of F1 for Help) so could only be controlled by the mouse. This makes it much harder for malicious software to disable since it then has to account for screen size, window location (though the PG window could be moved via keyboard) and PG version to be able to disable PG. Of course, such malware would not only have to be given Execute access, it would need Global Hooks privilege also.

 

I have a program called Automate (from http://www.networkautomation.com) that allows me to programmatically send keystrokes and mouse events to other apps. I decided to test this against PG.

Here's what I could do:

1. With Automate I could open the PG GUI.
2. Using the "move mouse to object" action, it moved the mouse cursor to the phrase "Protection Enabled".
3. Using the "click mouse" action, it clicked it.
4. Using the "wait for window" action, it waited for the window with the title "Please Confirm".
5. Using the same methods, it clicked the Yes button.

At this point, Automate had disabled PG. I didn't need to know the screen size or window location. I didn't need to know the PG version because I could specify the window title as ProcessGuard*.

I did give Automate execute permission, but I did not have to let it use any global hooks to do this (I explicitly removed this permission in PG and restarted Automate before I ran the test).

One interesting thing that I discovered is that if the PG GUI is on one of the other three tabs (Alerts/Protection/Security) then Automate is not able to click on the "Main" tab because PG complains that Automate is trying to modify PG's process. I don't know if PG would complain about all software that tried to switch tabs or if it's specific to Automate.

It doesn't matter, though, because Automate can just as easily disable PG via its systray icon using the same techniques.

Of course it wouldn't be feasible for the malware to contain the 32 MB installation file for Automate (not to mention installing it). However, the APIs that Automate uses could probably be used by anyone else.

I didn't try to disable my other security apps with Automate but I wouldn't be surprised if I could disable those too.

The "Please Confirm" prompt does nothing to stop this attack and, in day-to-day use, I would prefer that PG not make me answer these prompts (maybe a balloon popup instead).

After enabling SMH for PG and restarting PG, I held down the Insert key when clicking the "Protection Enabled" checkbox in both the GUI and in the systray icon's menu, but when I tested this I received no prompt from SMH. SMH did prompt me when I tried to *close* the GUI. So either I'm not using it correctly or it's true that it only works with window-closing messages. Or maybe it's that SMH doesn't support checkboxes.

I've disabled SMH now in all of my apps because it's not worth the hassle if it's not going to fully protect my apps. I'm a little relieved because I didn't like the idea of needing to hold the Insert key and click on every important checkbox in all of my apps' settings, etc.

Since we might never agree on whether PG should block programmatically generated keyboard/mouse stuff, maybe it's possible that PG could offer it as an option (it would be fine with me if this was global to all apps). If PG ever adds such an option, I would like it to be separate from SMH because then I could continue to keep SMH disabled.

p.s. I bought PG yesterday because, other than this issue and the rundll issue, I'm very happy with PG.

 

Pete99,

Thanks for taking the time to test and post your results. Older versions of PG (3.00 IIRC) did require a Human Confirmation before disabling protection settings - while it is possible to use SMH to prevent changes via PG's system tray icon (right click to bring up the menu, then hold down Insert while selecting an option - SMH will then kick in when that option is selected in future), you are correct that this does not cover checkbox settings and can be time-consuming to set up (which is exacerbated by not being able to copy or backup these settings).

Hopefully DiamondCS will improve on SMH in future versions.