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 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).
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.)
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.
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 ;).)
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.)
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.).
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.
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:
Note how the user interface disabled anything but the alerts tab and the unlock button:
Here's the unlocking prompt, then:
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?"...
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).
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:
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:
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.
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.
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:
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:
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