DiamondCS ProcessGuard

This page is part of a larger project focusing on securing MS Windows. Get to the other pages by here.

This is a detailed discussion of DiamondCS' ProcessGuard, a tool designed to generically protect your sensitive and critical processes from being tampered with by all sorts of malware. At the time of writing, it is a later beta version (in the twenty-somethings) for PG 3 that I am having in front of me.
I hope to be able to update the page when something changes, but can't promise to. An older version, discussing version 2 can still be found here.

    The text is divided into several parts:
  1. A short overview of (certain aspects) of the history of trojan horses (only the software ones).
  2. How PG fits in there.
  3. A short word on trialling and refunds.
  4. Details of how you set up PG and how it works.
  5. Walkthrough to creating a secure configuration.
  6. Final words and further information (links).

The screenshots you see on this page are all thumbnails that open a full-sized image in a new window (each time the same window, so you can keep it open and refresh it by clicking on another thumbnail picture).

Zum Seitenanfang

A bit of history from the malware front?

Actually I'm rather fond of this one: a few years ago, there surfaced trojans (like BioNet or Optix) that were capable of shutting down security software. There was much discussion about them in the anti-trojan software scene, in spite of the fact that, as far as detection was concerned, these new breed wasn't much different from the more traditional trojans. And, supposed the trojan wasn't detected, why should it bother to kill the trojan scanner that didn't detect it anyway? But killing other programs like personal firewalls was of course of great interest for the trojan authors, so they could have their malware bypass the generic blockage that these programs meant for them.
Many different developers thought of many different approaches, but in the end they all had to agree that there was no final solution possible because the trojans made use of a bug-feature of the windows NT architecture: There is a function that these OS's provide, called TerminateProcess(), and this function allows the calling process to terminate any process it wants, regardless of privileges etc. (There is a small exception to this rule: a couple of processes are protected even from this, unless the caller acquires a special privilege (SeDebug) from the OS, which he or she can only do if he or she is running as an admin in the first place. But very very frequently, users are logging on as admins all the time, even if there's nothing administrative that they're about to do (hint, hint). Also, this protection generally was used only for very few critical OS processes, not for your everyday security app.)
So, as long as MS wouldn't have the calling processes authenticate in one way or another (to the OS, to the target process or even to the user), there couldn't be anything done to prevent this function to be exploited by malware.

On a seemingly unrelated edge of the malware front have trojans a year or so ago started to use another technique to bypass personal firewalls: It's called "dll injection" and it means that the trojan injects (parts of) its code as a dynamically loaded library (dll) into running processes that are likely to be allowed to communicate through the firewall. While the firewall might alert or even block an "attempt by Iamatrojan.exe to send data to 123.456.789.123 (www.homeofthetrojans.com)", it will probably already be so configured as to let, say, InternetExplorer send data to any host's www port. So the trojans manage to have their code being executed by Internet Explorer and the firewall lets the communications pass.
Dlls are actually a good thing: If you're writing a routine, or a set of routines, associable with a specific task (say, image rendering), maybe you don't have to have these loaded into memory until your main application program (maybe a word processor) wants to do something which corresponds to that task. Then you put them - in about the executable form they would have if they were static parts of the main application program - into an extra file which the application can load on demand. This has the additional advantage that some other application that might want to perform similar tasks (say, a webbrowser) can also load that extra file with your routines and doesn't have to invent the wheel twice.
Now the trick is that, just like with TerminateProcess(), any program can call a function on another program that makes the other program load a dll of the caller's choice, and that makes the other program execute the instructions therein. It needs a bit of tweaking so that the "host" program doesn't just crash for executing this foreign code, but that's something the trojan authors now can handle.
Initially, the personal firewalls made sure that communications belonged to a certain application program in order to be permissible, but that wasn't sufficient anymore. Consequently, many firewalls have started to also control what dlls are being loaded by applications that are potentially allowed to send data out. Unfortunately, there are applications that are very common (like InternetExplorer or WindowsExplorer) that load really very many dlls even out-of-the-box (and even more with more software installed), and so that control is not only a venture into a territory which is not the proper ground of firewall software, but is also necessarily complex and means a significant resource strain.

A final, also seemingly unrelated, tendency has emerged in even more recent times: Strategically spoken, trojans are being used less to have fun with some unwitting victim "l00ser" computer user, but to more or less professionally sniff out bank account and password data. (Or, to have the infected machine act as a relay for spam mails where the trojan operator can send thousands of mails, and be paid by some crook for it, but never be traced back because the mails are originating on the poor infected user's machine.) Technically, that information retrieval is done a) by searching the hard disc for sensitive information, but more importantly b) by logging all the keystrokes of a user. To have this logging installed, and to have it hidden, trojans are beginning to meddle with the internals of the windows operating system. They hook onto the "keyboard handler", and they inject themselves into the OS's central processes.
Slowly but surely, they're also beginning to adapt a hiding technique known from unix malware by the name rootkits: They mess with central system functions in such a way that the user or even other programs can not even see that they're there. For example, they have the Task Manager behave normally and list all the running tasks - except one, the trojan task. They are using techniques discussed above (dll injection and process manipulation), but no longer on the programs that prevent them from working as intended, but on those core processes that even the scanners have to use to find them. It's going to be interesting to see how the anti-virus, anti-trojan developers counter that threat.

I hope it has become clear that all of these threats have a common root in Windows' architecture. While the architecture is so designed as to keep the memory space, data and command stack of all processes totally seperate from each other, the demands of possibilites of process interaction seemed to require a way to bridge that gap, and Microsoft decided to deal with it by providing functions which put everything about a process into the hands of the one that calls the function.
The most natural, most common-sensical reaction, is of course: Ah! Why didn't Microsoft design a proper way of inter-process transactions in the first place?! Or: Wouldn't Microsoft just come up with a patch that has these transactions happen in a more secure way?! (The answer to that latter question is of course, as anyone can easily guess: Nope.)

Zum Seitenanfang

Enter ProcessGuard

Venerable anti-trojan developers DiamondCS have presented a security program, ProcessGuard, that I like to refer to as "runtime OS patch" - because it installs a kernel mode driver that changes the operating system's behaviour described above. (For this very reason, just as the problems described above apply to Windows NT and above, so does the cure: ProcessGuard is available only for NT, 2000, XP and 2003.) With ProcessGuard every attempt of any process to access another process is filtered: processes can be either protected, in which case the admin can specify which access attempts (read/modify/terminate etc.) are prevented, or they can be explicitly allowed to perform these operations in case it's necessary and legitimate. Admittedly, this requires a bit of finetuning (although the default set of permissions leaves you at least with a system you can work on). But it is about the only program that I know of that prevents all of the three attacks described above.

Of course, ProcessGuard had and still has to take good care of itself not being ended or disabled by some malevolent program, and it does so in the most comprehensive way I've seen to date: It can prevent system drivers from being installed (thus also blocking rootkits), catches critical windows messages/events (and has the user confirm them in a clever way), blocks TaskManager's "EndTask" command (which is yet another way of killing things) and so on. Most of the things PG defends against have not been used by malware yet, not even in a proof-of-concept way. And those strategies that are already being used by malware "in the wild" are all covered.
(While PG was originally designed to protect against the TerminateProcess() function described above and against very similar attacks, the method it used to deal with this challenge was so generic that it would also prevent dll injection and some other bad things from happening, which of course was a good selling point. However, at the beginning there was a plenitude of other attack vectors left, and it was soon being discussed whether or not ProcessGuard was fundamentally flawed. Of course it wasn't, but it took some time to react to a situation where DCS would not only have to block attacks used by trojans, but also attacks that people would invent just to badmouth DCS and PG. Quite a lot of "proof-of-concept" tools have been made up just to show that there was another attack vector left that could "easily defeat ProcessGuard", whether or not such an attack vector would be of any practical use from a trojan author's perspective. Anyway, DCS have taken their time, done much research and for now have been able to develop ways of handling each of those attacks, often in very clever ways. Today, all those "exploits" are blocked, as well as a multitude of other vulnerabilities, not so widely discussed. Below I mention two issues that remain and that are conceptually hard to solve, but other than that, I know of none that could overcome ProcessGuard.)

Once in the kernel internals, DCS developers have also added many other tweaks like control of hooks (so ProcessGuard prevents keyloggers from working), preventing dll injection by means of exploiting some registry setting, controlling an undocumented method of termination that only TaskManager uses, and preventing Windows' own File Protection System from being disabled.

Almost as if to provide an example for what I've said above about PG being constantly improved, the following had happened: Consider what happens if the user configures PG so that a program is explicitly authorized to terminate any of the protected programs (like, e.g. a taskmanager with which the user wants to be able to kill any process if necessary, or a trojan scanner which is supposed to be able to get information about a system's process's loaded modules; all in all it's not so unlikely a scenario), but then some malicious program comes in and changes the privileged program. Well, you say, the malware will not be able to access or change that program's process, for it is protected by ProcessGuard - but ProcessGuard does not monitor what happens on your harddisk, so the malware could change or even replace the privileged program with a copy of itself named like the original program. When launched from that location, the malware would have all permissions the user had granted to some security tool. We have discussed this scenario a while in the beta group and now here is the solution that DCS came up with:
They have introduced a new feature into ProcessGuard that is an almost independent security appliance of its own! - PG now monitors every program launch and maintains a list of "signatures" of programs that it knows about. Now ProcessGuard will alert you if the security tool that you've endowed with so extensive privileges has changed on disk, and it will ask you if you want to re-allow it to launch or stop it right in its tracks. (When you let it launch, it will be granted the privileges defined before.)
I'm saying this is something independent, because actually it monitors every launch of an executable program and builds a list of allowed applications. Thus, you can have a list of all apps, define for each entry whether it should be allowed or blocked (maybe you want to block Microsoft's "machine debug manager" mdm.exe) and be alerted whenever a new program is launched or a known program has changed. You can even say that you don't want to be alerted but block launches of new and modified programs right away.
All this monitoring and checksumming is implemented very efficiently so it doesn't introduce any perceptible delay, which in itself is remarkable. (But along with this goes another discussion that has surfaced among the betatesters and program developers: To actually give this mechanism its full power, you'd have to monitor not only the file signatures of the executable programs themselves, but also of the libraries they dynamically load. It's DLL hell again. For to implement this monitoring, you'd not only have to hack into yet another area of the Operating System, but the amount of monitorable events, and the amount of items in your list would increase dramatically. It's very unlikely that this can be done without a more severe resource drain (CPU- and memory-wise). We will see how this story continues. And keep in mind that this is all "theoretical territory", no malware as of yet (to the best of my knowledge) replaces dlls on-disk. And remember, we're talking about a program that set out just to stop TerminateProcess. Still, this is one of the issues I alluded to above.

Zum Seitenanfang

A word of caution, before we go into configuration details

DiamondCS offer a free version that is able to guard one process (other than itself, that is) and a payware version for $30 which has no such restriction. I would very urgently recommend that you seriously consider testing PG with the freeware version before you decide to purchase it. For a reason: Fixing things so intricately (and undocumentedly by MS) knit into the windows core architecture produces an immensely high risk of incompatibilities. Besides a few things that could be used to shut PG down and that have been difficult to overcome (but that are overcome now - I am mainly referring to windows messages handling, a really sophisticated feature introduced with PG version 2.0), the most annoying problem in PG development was that there are so many different setups out there. Not only W2k and XP, but different levels of Service Packs, single patches applied or not, different languages, different other system drivers already installed on some systems etc. It had been simply impossible for DiamondCS to test PG on every possible setup, and with these things small differences can lead to total collapse and BlueScreens. I have been present at many of the discussions at the time and can but emphasize how much time and effort all people at DiamondCS have spent to fix those incompatibilities wherever they occured. I had been beta testing PG before as well, and while we had had a great number of different setups, and DCS fixed everything we came up with before releasing anything publicly, there were obviously serious compatibility problems remaining even after beta phase that didn't surface beforehand. All that in mind, I don't think it would be fair to blame DCS for using end-users as testers - there had been thorough betatesting, the issues at hand are more or less unavoidable given by the matter we're dealing with here, and DCS is not Microsoft after all with a betatester base of several thousand people and corresponding budget/personnel. So, to make a long story short, try before you buy. DCS are very generous when it comes to what they grant to their customers (like free lifetime upgrades, rebates on other DCS software (see below)), but when you run into a problem and they can maybe not even reproduce it with the computers they have, I think it's understandable when they say 'you should have tried beforehand' when you then decide you'd rather want your money back. Perhaps it's not extremely laudable, but IMHO it's understandable.
So DO TRY IT before you buy.
(And in case you want to buy it, consider going to DCS via this link, which tells them you come from my site ;).)

Zum Seitenanfang


The Program is organized into several Tabs: Main, Alerts, Protection, and Security. I will discuss them in turn, introducing feature descriptions, technical background and tips in passing, so just read ahead ;) (The systray icon context menu commands should be clear if you understand what the rest of the program does.)

Main Tab

preview of the main tab

At the top of the tab you have two status indicators: System Status and ProcessGuard Status. Since PG is working at a very low level, but what you're seeing is a rather high level, the architecture behind it is rather complicated: All the protection is done by a system driver which is working in kernel mode. Then there is a service to manage the driver and communicate with it (which is working in user mode) and then there is an application (procguard.exe) which you are using to see alerts, to configure protection etc. This application part is the only thing you're seeing from PG, but it's not even necessary for the protection to work. Anyway, "System Status" reflects the driver's status, as reported by the service ("Secure", "Vulnerable" etc.), and "ProcessGuard Status" reflects the status of your interface application procguard.exe ("running", "receiving settings" (i.e. it's being told by the service how the protection is configured, it doesn't know it by itself) etc.).


preview of an alert log entry showing a blocked program launch

Next, you have protection settings: You can dis-/enable all protection measures with a single click, selectively dis-/enable checksum validation of programs launched and you can dis-/enable learning mode. Once Checksum protection is enabled (it is what you manage on the "security" tab), you can select not to be prompted for acknowledgement when a program launches that isn't yet on the list, or that is on the list of allowed programs, but with a different "signature" (so you know it's been changed); insted PG will just silently block all launches of new or modified programs and produce a log entry telling you more as can be seen on the screenshot to the right.

Learning mode is a powerful tool to quickly get a good configuration with PG, but since it's not something you should be using in your daily computing, I will discuss it only below, under Good Configuration.


Then you have Global Protection Options: "Protect Physical Memory" is protection against an attack that exploits a rarely used mechanism provided by Windows to access areas of your memory in order to un-hook ProcessGuard. When I said that I regard PG as a runtime patch of the OS, this attack would make the OS forget about the patch and thus render PG useless. This is a very complicated attack, discussed only on a security research site and not used by any malware - but now PG defends against it. There are only very few applications that make legitimate use of "Access Physical Memory" and you can authorize them to do so in the Protection Tab (InternetExplorer, Mozilla Firefox, DCS's own PortExplorer and a couple of windows' internal programs which are configured correctly by ProcessGuard's installation routine).
"Block Global Hooks" prevents programs from creating a global hook - who would've thought this? What is a global hook? It's a mechanism whereby the program that installed the hook can react when certain events occur, no matter if that program actually has the focus or not and no matter of whether the events happened "in" this program or "in" another one. This is mostly used for creating mouse and keyboard hooks, for example to set a keyboard shortcut (that is supposed to make the program do something even when it doesn't have the focus, like: "skip to playing the next song" when your playback app is actually only sitting in the tray.), but malware uses this to install keyboard logging routines that record every character that is being typed on the keyboard, no matter which application is receiving the input (and no matter how careful this application hides the input behind asterisks ("*")).
Next, "Block Rootkit/Driver/Service Installation" prevents other programs from installing drivers, and thereby gaining access to really really really central parts of your Operating system. Parts where Process Guard is. And the only place where ProcessGuard can be defeated. There's nothing more powerful than the kernel and the drivers. And there's no way to ensure one driver (say, ProcessGuard) can "keep on top of" another driver (say, a rootkit). Only very few apps need this, but some legitimately do. (There is a small story to this, too: Normally an application or an installation routine would ask the OS to register some .sys file as a driver (and launch it either immediately or on the next reboot). But some don't do it this way, but they call a Microsoft Windows application - services.exe - to do it on their behalf. Now do you want to allow services.exe to install drivers or not? Well, of course not, because if you do, any application whatsoever can ask services.exe to install a driver of its choice - malware included. But then, what can be done about those apps that legitimately use it to install a driver? Well, DCS have managed to make PG know what application is trying to use services.exe in this manner, in fact "get in between" that application and services.exe. So now the situation has changed completely - you can allow services.exe to install drivers, because now ProcessGuard can control who can access services.exe. The "allow to install drivers" setting now refers to both the resp. application installing a driver or service directly or via services.exe. Neat, eh?)
Finally, "Block Registry DLL Injection" blocks access to certain registry keys that can be used to have the OS inject a specified dll into every process - without the "attacker" needing to adress the "victim" directly.


preview of the locking prompt

Besides the obvious "Quick Tips", "Help", "Register" and "About" buttons, there is one more interesting thingy on this tab: the "Lock" button. This gives you a way to lock ProcessGuard with a password to prevent any change to the configuration:


PG locked

Note how the user interface disabled anything but the alerts tab and the unlock button:


preview of the unlocking prompt

Here's the unlocking prompt, then:


Zum Seitenanfang

Protection Tab

preview of the process protection tab Here you can maintain a list of programs that you want ProcessGuard to protect. You can use the "Remove Application(s)" and the "Add Application" buttons to build the list (or you can drag'n'drop programs onto the window or use the context menu in the security tab) and when you select an entry, the settings checkboxes will appear at the bottom of the list, providing access to protection, authorization and other options to be set for this single program entry. (You can also add other types of files, not only .exe ones; how about .scr, .sys etc.?) If you want to, you can use the "Reset to Default" button to reset the protection list to just those defaults that the installer provides.


As has been (somewhat) explained above, what they are protected from is this: "Termination" protects from all ways to terminate the application, including a few methods that not so much terminate but rather crash the target application.
"Modification" protects from DLL injection (except for the registry dll injection method which can only be blocked in the main tab for the complete system), patching (Code modification) and suspending.
"Reading" of course protects other processes from reading this program's memory - which includes code, data and meta sections. Actually it is only interesting for protecting processes that have highly confidential data stored (as password managers, e.g.), but even those should normally use a special "protected memory" service that windows itself provides. On the other hand, very many applications and tools seem to frequently enumerate meta data about all processes currently running and they will run into problems if you have processes protected from reading. (So, if you insist on read-protecting some programs, watch the alerts log and maybe grant read authorization to the tools that need it.)

NOTE: Here you can (not) see two of the most important changes since version 2: First, the categories have been re-organized to be easier to understand. (version 2's "Read" and "Get Info" have become "Read", version 2's "Write", "Set Info", "Suspend" have become "Modify" and version 2's "Terminate" is still "Terminate".) Second, and more importantly, now it's the actual access attempts themselves that we're dealing with, and no longer the claim made to the OS to get a handle privileged to maybe later execute the resp. actions on the process.


Since you want (some of your apps) to be able to still terminate a hung process - even processes that are central parts of your security apparatus can crash and eventually need to be killed and restarted, or maybe shut down to free resources when you're offline -, you can also endow programs with "authorizaitons" corresponding to the blocks which overrule the blocking settings. Usually I have one Task Manager and my virus and trojan scanners with such permissions.


Finally you have assorted other options that pertain to an entry in the protected programs list: you can allow it to install global hooks, to install drivers or services and to access the physical memory "device". These settings are overruling the global protection options from the main tab for this one program.
But then, there is another sophisticated feature hidden there: "Securely handle window closure": Again, let's hear a bit of theory first:
At a certain level, you call Windows an event-driven environment: programs (often) do nothing until a certain event occurs. Frequently those events are not handled by the program itself, but by the OS - timeouts, mouse clicks, clipboard pastes, window resizings and whatnot. The program puts up a loop so that a queue of events is polled regularly. Normally the queue is empty and nothing happens. But when an event occurs, the OS sends a message to that queue and when the queue is polled again, the program is made aware of that a certain event has occurred and can react on it. (Of course, what we're primarily interested in is the type of events that makes the program exit by its own. A mouse click on the "x" button in the titlebar of a windows program makes the OS send such a message to a program, and there are others such "Close Messages".
Now, when the program receives a message from the queue, it hands over command to the event handling routine that corresponds to the type of event. Probably you've seen that in carefully crafted security applications, the close message handler will ask something along the lines of "Do you really want to quit?", whereas the standard behaviour is to ask "Do you want to save your changes?", but to just silently quit if there isn't anything changed and/or needing to be saved. Unfortunately there are also a few security apps which simply use that standard close message handling routine.
The problem is that there is no way for the program receiving a close message from the message queue to determine whether or not this close message is legitimate - another program could have sent the message just as well as the OS. So that other program can very easily simulate the user clicking on the "x" button or pressing "Alt-F4" etc. In theory (and, up to now, in proof-of-concept exploits), the malevolent program can just as well simulate the user clicking on the "Yes" button of a somewhat more clever close message handler's confirmation prompt "Do you really want to quit?"...
preview of the human confirmation prompt This is where PG's CMH (Close Message Handling) steps in: It catches all types of close messages and regardless of what close message handling routine the protected program uses, pipes the message through its own human confirmation prompt, and hands it over to the program's message handler only when the user confirms PG's prompt:
In order to counter the malware just simulating the user confirming the prompt, that confirmation has to be made not simply by clicking a button, but by typing in a randomly generated character sequence that is presented as a picture (to prevent another program just reading the box's text/caption) and obfuscated by some noise and moving around (to prevent easy capture and OCR on it). Very sophisticated if you ask me. (Also remember that on a tightly configured system, the malware may not even be allowed to read PG's memory space, so it can't even extract the string relevant to the comparison from there.)
But there's nothing without a drawback: In fact, there's two drawbacks, one where you get too many confirmation prompts and one where you don't get enough: There are actually a lot of apps that use such close messages to destroy many elements of their user interface when they quit. If you have such an app, and you have CMH enabled on it, and you really want that app to close, there are generated lots of those messages in the process of it shutting down and cleaning up (destroying preview windows, document tabs, systray icons, icon bars etc. etc.) - and lots of human confirmation prompts. Some programs even use close messages when they're not even exiting, but merely want to destroy their splash screen, swith between their views etc. Then you'll get unexpected human confirmation prompts in the middle of your normal work with the program.
PG caters for some of the issues by having the human confirmation prompt optionally confirm "all" close messages, but this only works most of the time, i.e. with most apps.
The other problem is programs that have ways of shutting down that bypass the close_message exiting routine. And while actually it is good coding practice to have all the close and clean up routines "go down the same path" rather sooner than later (where PG's CMH is waiting), there is no garantee for it and you can not really tell how a software author has its program manage its exit. There are infinitely many ways to exit a program and very very many of them around the place where PG's CMH could kick in. Thus, in PG version 2, you had people complain about CMH not intervening when they clicked some other "Exit" button (and not the "x"), or used the "File | Exit" menu entry, or something else. All the while DCS could with some reason kept saying that the other very powerful protection measures weren't affected by this, that this was an attack vector not presently used and unlikely to ever be used, and that finally CMH should be considered a beta feature - it seems they felt this was a situation that left something to be desired as well. Now with PG v3 there is a possibility to have PG "learn" an applications "exit events": When you hold the INSert key while you press that Exit button or menu entry that you want protected, PG saves that event and will trigger its CMH on it the next time. (Next time! At least reloading the to-be-protected application is required, maybe even rebooting to re-initialize PG...) Theoretically, you can also have other buttons (like "Disable Guard" protected. Maybe you run into other problems when you try this (e.g. does acknowledging one "disable" event mean that does not intervene when the program really closes (for it thinks the confirmation to the "exit event" has already been given)?), but it can't hurt to play with it a bit. By now it should be evident that DCS work hard to improve their product and they pay much attention to user feedback, so you should definitely report your findings if you think you have something out of the ordinary.

Okay, I am not even sure about this one, but this is the second (possible) issue I see pertaining to PG's protection: There is one other message sent to applications that makes them quit, and that is the "the system is being shut down; please get your stuff done and go away" message. While there has been a short discussion about it some time ago, I don't know how this is currently handled and whether or not it possibly presents something that can cleverly be used to defeat PG's protection. Maybe it's handled now, maybe you can't exploit it for system-architectural reasons, I just don't know. But I said above that I would mention two issues I know of, and so here it is/was.

All in all, while CMH has improved immensely from version 2, I would suggest to still use it wisely and rarely - and to watch what happens when you do use it. While it is a powerful protection method, don't count on it to suit all your apps. Use it only on very important security apps that don't do a proper CMH on their own - and try how it works with those (esp. if you consider this feature to be an important selling point and you haven't yet made your purchase decision).


Generally, if you don't know how to handle these protection and authorization things for a certain program, start by disallowing everything and see if your program still works as expected. In most cases it will. In other cases, you probably know what's going on and can allow certain things without having to worry much (i.e. you will most certainly allow your screenshot capture application to create global hooks). Finally, if you find that your program obviously wants to do something sensitive, but you don't understand why, then ask the developer what the thing is trying to do - and actually this applies regardless of whether the app still works when you block the attempt or not (but admittedly it's a bit more urgent to get that information in the latter case).

Zum Seitenanfang

Security Tab

preview of the security tab As has been discussed above, the process protection part of ProcessGuard only protects your security apps when they're running. When they're running, no malware can come along and disable or tamper with a protected process in any way. That is a bit different for the program files as they are saved on your harddisk (or wherever): A malware can perfectly come along and modify the program file of your virus scanner and the next time you run it, the "hacked" version is being executed and will get all the privileges to scan and terminate that you have specified in PG's Protection List. (Clever Virus Scanner do a self-check to prevent this, so it's (again) an arms race between self-checks and malware patching that very self-check routines when they're already at it.)
Again, ProcessGuard has something in store for you there: it keeps a list of checksums so that it can determine if a program has changed since you've specified how it should be dealt with "last time".


preview of the new program launching prompt

Two more upsides, and one downside:
As you can guess from the screenshot, this checksum protection applies not only to protected programs (the list of programs in PG's protection tab, that is), but to any one. Every time you launch a program that hasn't been launched before, you'll be asked if this program should be allowed to launch or be blocked from doing so, and you can specify to do it like this just now or every time it's being launched:


preview of the changed program launching prompt

The same applies of course for programs that have changed in comparison to the stored checksum:
Of course, you can also later change what to do when a certain program launches.
This checksumming alone makes for a very good protection, since you can use PG to restrict the programs that are able to run on your computer to a list you maintain, and you can use it to detect any changes in those programs and prevent changed programs from running as well. (For the ease of setting up that list, making the restriction mandatory for the user and even more on that, see further below.)
A second, although maybe minor, advantage of the way PG handles this is the following: As you can see in the screenshot, you'll also see when your programs have been launched for the last time. You can use the column heads to sort the list (just click in the resp. column head), so you can get a rather good overview over program useage on your computer.

Now the downside, though: Actually it's not a downside but a missing feature - checksum protection as of now only applies to executable program files, not dlls, activeX controls etc. I have discussed this above (the "DLL hell" part), and I don't know whether or when DiamondCS will extend that protection on other files containing program code...


It should be obvious what the "Refresh" and "Remove Application(s)" buttons do, but don't miss the context menu of the list entries: you can display the OS's properties dialogue, add an entry to the protection list and change the policy on the entry.

Zum Seitenanfang

Alerts Tab

preview of the alerts tab Finally, here's how the log window looks like. Remember that protection is working independently of the procguard.exe GUI and that the service is writing its reports to the logfiles all the time. (Open the folder with the logfiles with the "View Logfiles" button.) Still, when procguard.exe is present, it will also display what the service reports. When you get non-execution alerts, the systray icon flashes and you can configure PG to display a balloon with information about the alert hovering over the systray icon - when you click the balloon, you're taken to the last alert on the alerts tab.
By the way, what you're seeing in the alerts list is an attempt to unload a dll from hijackthis.exe with DiamondCS' APM, an attempt to inject a dll into hijackthis with the same tool, an attempt to suspend hijackthis, four attempts to kill it and two attempts to make it crash, all with DiamondCS' APT. Finally, there is an attempt by SDTRestore, a small proof-of-concept tool, to "untie" PG's hooks using physical memory access.
Note that when you select an alert, the details area below the alerts list provides not only more details, but also one or several buttons to adjust your protection settings if you think the alert makes it clear that there's something to be tweaked.

Zum Seitenanfang

Good Configuration

Of course, the most interesting part of the review - besides the screenshots - is to see how to configure it well. So I will describe my approach to this here, too.

Remember the "Learning Mode" checkbox from the main tab? That's the most important item in setting up ProcessGuard, for all its improvements it has become even more important than it was in version 2 already. It not only learns to allow programs to be executed, but also what special authorizations they need, if any.
But let's have first things first:

  1. Disable any resident protection (AV, AT, Anti-Spyware) before you install ProcessGuard - it shouldn't be necessary but it's a good practice and avoids problems in many cases.
  2. Run ProcessGuard's Installer
  3. At the end of the install, you will be asked to reboot, better do so.
  4. When you're back in, open PG and click on the "Register" button on the main tab, enter your unlock code and validate it.
  5. Restart ProcGuard.exe or reboot, whatever is suggested by the validation routine.
  6. Back in PG the next time, enable all 4 global protection options, verify that Learning Mode is enabled and reboot again. (Then PG will learn the settings that your startup apps need with regard to those global prot. options.)
  7. Run your taskmanagers, security apps, internet apps etc. But don't connect to the internet and don't run apps that you don't fully trust. Also, don't forget to run your screen saver (and maybe add system32/logon.scr manually to the Security list with Permit Always set, just to make sure)!
  8. Reboot again.
  9. PG should have automatically disabled Learning Mode. Verify that Learning Mode is in fact off now.
  10. Review your list of entries in the protection tab:
  11. Review your list of entries in the security tab:
  12. Read the helpfile and the tips.

If you want, you can build your list of crc-checked trusted programs (the "security" list) also with learning mode: In learning mode simply launch every app you normally use and quit it again. Then disable learning mode and browse the list in the checksum protection app to find programs launched indirectly or in the background that actually you don't want to run on your computer, and change their "Last Action" (open the entry's context menu by right-clicking at the entry) to "Deny Always". (Hint: When you sort the list by path, you will better locate silly Microsoft programs like e.g. mobsync.exe or mdm.exe that get started without you wanting to.)
The drawback of that method is that all those apps will be added with default protections and authorizations (!) to your protection list, so you'll have to review that list as well, removing those that need not be there. Or you build your security list another way:
Don't use learning mode, but just use your computer as usual, with all your apps and what you do with them, for a couple of weeks. When you're about to use a program that PG doesn't know yet, it will ask you about it, and it's easy enough to permit them always and thus get your entry in the protection list. You just don't do it in one afternoon.

Here are some further tips on tweaking your protection list:

Zum Seitenanfang

That was it

With this setup, nothing can mess with your vital system processes nor with your security apps, nor with your firewall, nor with those apps that can communicate through your firewall. No communication that you didn't authorize will leak, no illegitimate or illegitimately changed apps will run.
But you still need a firewall to take this to its end, and you need a virus scanner. Why? The problem are programs that are launched by mistake. Suppose you've downloaded some program and want to launch it in good faith - you'll tell PG to at least allow it this one time to launch. It will not be able to intrude into your system internals because you didn't give it permission to access your central processes, to install drivers or hooks etc. But it can read personal information from your harddisk and send it out into the internet, if you don't have a firewall that allows such communications only to a restricted set of programs (like your email program and your webbrowser). It can delete or infect all sorts of files on your harddisk (in the first case your system might become unusable, in the second case, at least the infected files will be stopped from running when they're executable files - which can in turn lead to an unusable system), if don't have a malware scanner that can prevent this by recognizing the malware and correcting your mistake of trusting that program.

Remember two things: my taking part in a partner program which might generate some small reward for me if you decide to purchase PG via this link, and, more importantly, that this my taking part is motivated to a very large extent by the excellent support and the general friendliness of the people at DiamondCS and on the BBoards. You should make a habit of visiting those boards regularly and just posting there anything that comes to your mind - well pertaining to DCS products and security in general at least. Here are the boards again:
PG forum at Wilderssecurity.com
DiamondCS-hosted Forums
More DCS forums at Wilders

Zum Seitenanfang