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. However, it is focusing on version 2.000 which, at the time of writing, is being superseded by version 3.000 (which is currently in beta stage).
Who wants to rather study the review of the more up-to-date version, should skipt this page and go here. I am keeping this page here around, though, for historical reasons and for those who still have version 2.000 and want to learn more about it. But you should know that it's strongly recommended to upgrade - which you can do for free by going to ProcessGuard's homepage, member section and downloading the new version and a new key along with it.

Zum Seitenanfang

a bit of history from the malware front?

Actually I'm rather excited about 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 in case the trojan wasn't detected, why should it worry to kill the trojan scanner that doesn'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.
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.
The trick is now, that, just like with TerminateProcess(), any program can call a function on another program that makes the other program load a dll of the function-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 the 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 potentially allowed to send data out. Unfortunately, there are applications that are very common (like InternetExplorer or WindowsExplorer) that load really very many dlls out-of-the-box, and so that control is not only a venture into territory 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. Technically, that 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 (rootkits): They mess with central system tools 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 the author wants them to, but on those core processes that 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 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 provide functions which puts everything about a process in 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 question is of course, as anyone can easily guess: Nope.)

Enter ProcessGuard

Venerable anti-trojan developers DiamondCS have presented a security program, ProcessGuard, that I use 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.) Now every attempt of any process to gain access to another process is filtered: processes can be either protected, in which case the admin can specify which modes of access attempts (read/write/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 yet been used by malware, not even in a proof-of-concept way. And those strategies that are used by malware "in the wild" are all covered. (When PG was launched, there was some discussion about it fulfilling the task it was designed to fulfill, but being too easy to shut down itself, and so some of the defenses were introduced as reactions to some small proof-of-concept programs that had been presented with great noise. This has calmed down, almost all of the bases, certainly all of the easy ones, are covered, and when a new (theoretical) vulnerability shows up, DCS quickly responds to it. Most of the time, however, they discover themselves new internal aspects of Windows that can use some strengthening and implement it into PG before there's an alert of any sort about it.)

Once in the kernel internals, DCS developers have also added many other tweaks like control of hooks (so ProcessGuard prevents keyloggers from working), and preventing Windows' own File Protection System from being disabled.

Almost as if to provide an example for what I've said above, the following had happened: Consider what happens if the user configures PG so that a program is explicitly permitted 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, the malware will not be able to access or change it when it is running, for then 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 granted to some security tool. We have discussed this scenario a while in the beta and now imagine what the solution was:
DiamondCS have introduced a new feature 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 great privileges has changed on disk and ask you if you want to 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 those modifications right away.
All this monitoring and checksumming is implemented very efficiently so you don't have a perceptible delay introduced by it, 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 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.

A word of caution, before we delve 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 $25-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 2.0), the most annoying problem 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, 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 provoked 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 updates, 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 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 ;).)


There are several options available from the menu, and three tabs: protected programs, registered programs, and the log. I will discuss the menu and the first two tabs, showing the results of our settings in the log tab.

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" and "Add Program to Protect" buttons to build the list and when you select an entry, there will appear a dropdown selection box at the bottom of the list, providing access to block, allow and misc options for that entry.

As has been (somewhat) explained above, what they are protected from is this: Another process asking the Operating system to get a handle to the protected program, which (the handle) is supposed to provide the possibility to read or write to the program's process space, to get or set information about the process's working environment (such as execution stack, registers etc.), or to suspend or even kill the program. In this request PG interferes and you can specify what exact kinds of requests will be blocked (and logged).
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 can need to be killed and restarted, or maybe shut down to free resources when you're offline -, you can also endow programs with "allowances" corresponding to the blocks which overrule the protection settings. Usually I have one Task Manager and my virus and trojan scanners with such permissions.
(Note that a block will of course come unexpected to the program that's making the request. There is some difficulty coming from the fact that many programmers are developing their programs to request more privileges than they actually need. Programs that are actually only enumerating the running processes seem to request a handle with "all" privileges, while it would actually needing at most "read" and/or "setinfo" privileges. Very often they won't even make use of these privileges, but still request them "just in case". While this is somewhat bad programming, it normally doesn't hurt - but now it does. Well, to a certain extent that is: If you block the privileges that the program doesn't need (and usually common sense is quite sufficient to tell if a program needs to have the right to terminate programs you want to have protected), that program usually will just continue to work as usual - it won't notice that the request wasn't successful, because it really doesn't need it. But it will generate lots of log entries. (Imagine that the program in question tries to get such handles every 2 minutes on all active processes, 8 of which you have protected. That will result in 120 lines in your log in only half an hour.) It will soon become difficult to read your log to find out if there is really sensitive information. The only way to prevent this (until DiamondCS include an option not to log certain things) is to allow the program to get all the privileges it is requesting - which then applies to all protected programs. In other words you trust it not to mess in an improper way with any of those apps so dear to you that you have included them in your list of protected processes. IMHO, which way you prefer depends on the program in question: generally I wouldn't grant a program privileges it doesn't really need, but there are programs - like my virus scanner - which I grant all the privileges to.)

Finally you have assorted other options that pertain to an entry in the protected programs list: you can allow it to create global hooks (i.e. routines that are called when certain events occur, no matter if the program actually has the focus or not. This is mostly used for creating mouse and keyboard hooks, for example to set a keyboard shortcut (that is supposed to work also when the program doesn't have the focus), but also to install keyboard logging routines.
Similarly you can allow your program to install drivers, and thereby gaining access to really really really central parts of your Operating system. Where Process Guard is. The only place where ProcessGuard can be defeated. Only very few apps need this, but some legitimately do.
general protection options These two options overrule the general protection options 3 and 4 for that specific program, and thus only make sense if you have those general options enabled. They can be accessed via the "Protection" menu entry and can be seen here:
Generally, if you don't know how to handle these things, start by disallowing everything and see if your program still works as expected. In most cases it will. In other cases, you 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).

You also have the option to add "Close Message Handling" to that specific entry. This is again something very clever, but also very difficult, still providing room for improvement. Again, 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. When the 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 is of interest to us 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 routing that corresponds to the type of event. You'll notice 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.
human confirmation prompt 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 can 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?"...
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:

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 properly configured system, the malware won't 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: There are actually a lot of apps that use such close messages to destroy many elements of their user interface when they really 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 views etc. Then you'll get unexpected human confirmation prompts in the middle of your normal work with the program. Finally it seems that for some programmes that use lots of these messages in shutting down, when CMH messes with it, the messages somehow get confused and you end up with a program that doesn't properly shut down anymore.
PG caters for some of the issues by having the human confirmation prompt optionally confirm "all" close messages, but this doesn't work all the time and for all the issues mentioned above. So the bottomline is:
Use it wisely and rarely. While it is a powerful protection method, don't count on it to suit 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).

Program Checksum Tab

preview of the checksum protection 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".

Two more upsides, and one downside:
New Program launched prompt As you can guess from the screenshot, this checksum protection applies not only to protected programs (PG program protection tab protection, 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 a) allowed to launch just now, b) allowed to launch every time, c) blocked just now or d) blocked every time it's being launched:

The same applies of course for programs that have changed in comparison to the stored checksum:
Changed Program launched prompt

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, tho: 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...


Let's start from the right for a change:

Options Menu
Options Menu The options menu allows you to select a color scheme (the strange colors in my screenschots result from the reduction to 256 colors, don't worry about that, the schemes all look very nice), to enable/disable/view and clear the window log (that's what you see in the log view/tab) and the log file - and to specify the path to the logfile. You can also have PG's systray icon flash when there's something going on - you'll see what has happened in the log window (if you've enabled the window log).

Protection Menu and General Protection Options

Besides dis-/enabling all protection measures with a single click and saving your list of protected programs (process protection entries, not (yet) checksum protection entries), the protection menu provides access to general protection options, i.e. those that do not pertain to a single program; and to tweaks that let you handle the full power of PG's checksum protection.
General Protection Options Menu I have discussed the items 3 and 4 above, here's what 1 and 2 do: (1) Interestingly, windows' own TaskManager uses none of the mentioned methods to terminate a process when you click on "End Task" ("Kill Process" uses the TerminateProcess() call mentioned above), but a completely different approach, which, apparently isn't used anywhere else. In order to prevent malware from some day using this EndTask method, you can disable it, but only for your computer wholly and completely, without an option to overrule this restriction for some occasions.
(2) There's a registry key that makes windows load what is specified there as a dll into all newly launched programs. Since one of PG's main motivations is preventing the more or less forcefull injection of dlls into protected processes, you have the option to disallow new entries to be added to that key, and this to prevent new dlls from being loaded into every single started program.

Protection Menu, Program Checksum Protection Options

Program Checksum Options Menu Besides dis-/enabling this cool feature, here's two things to make your secure life with it easier: You can enable a "learning mode". When in that mode, every program launch is allowed and registered as legitimate. This way you can build up a list of allowed apps along with their checksums very quickly. "Learning mode" thus is a nice thing to use right after installation of PG (provided you've made sure that your system is clean beforehand), and it can be disabled either manually or will be disabled when you log out.

Learning Mode Logentry

(Note how learning mode only extends to learning apps/checksums that can legitimately be launched, not to granting them special allowances.)

Block Unknown OS Error message When you have a good list of allowed apps together, you can also take the opposite way: not allowing everything that's not explicitly blocked, but blocking everything that is not explicitly on you list of allowed application. Then, new or changed programs will not generate a prompt, but simply refuse to launch. You'll get an error message by your OS:

and a log entry telling you more:

Block Unknown logentry
File Menu
File Menu

The file menu gives you a way to quit PG's user interface (just the user interface - protection remains the way you have configured it!), and to lock ProcessGuard with a password to prevent any change to the configuration:

PG Locking Prompt

Note how the user interface disabled anything but the log view and the unlock menu entry:

PG locked

Here's the unlocking prompt, then:

PG Unlocking Prompt

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.

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 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