Prevent process from reading other process

trusted process
I check the boxes for...

process guard -> protection -> protect this application from:
reading
modification
termination


untrusted process
I clear the boxes for...

process guard -> protection ->authorize this application to:
terminate protected applications
modify protected applications
read from protected applications


------------------

Using this configuration, is there any way the "untrusted process" can know that the "trusted process" is running? I mean.. I understand it may not be able to "read" the details about the process, but can it still know that the trusted process is running?

Thanks

 

bump, anyone? TO word it better..here is a question:

What specifically occurs when you select "Protect this application from reading" ? If an application scans the protected app, will it get "access denied" or will it not see that the app is even running?


Also when disallow a program to "read from protected applications"..does this mean that it will be unable to know that any protected application are even running? RO will it know they are running, but simply get an "access denied" message when it attemps to read.

Any and all responses are really appreciated. your product is fantastic.

 

I've played with the read/allow read options and found that some applications can still seem to know that processes are running. It seems to be how they are coded, indicating there are more ways than one to see if an process is running under Windows.

For example, if I disable my security apps from being read, I can launch the PG demo termination app and it'll report I have no security applications running to test termination on. But if I disallow some security apps I own from being able to read other processes that I have read protected, it will show them running despite PG displaying alerts that it protected them from being read. It may not show their icons or details yet the protected processes will still show up in a running list on some apps. So there has to be other ways in Windows to see if a process is running.

I really don't know if malware "checks" to see if something is running or it blindly attempts to kill named processes from a script list. I guess it all depends upon how the malware or application is written. That doesn't mean you shouldn't play around and take advantage of this capability in PG. It might just be enough to stop some forms of malware. But I wouldn't count on it being a stop all solution.

 

thanks for the response! great info

 

READ = ReadProcessMemory google it if you really want to know. Usage example is blocking a read by one of the WFPdisable tools. By blocking READ access you can prevent the tool from forcibly reading memory space. This is somewhat a rare incident though, since most forced attacks would need to WRITE to memory. This is considered a modify action by PG and blocked of course.

Block READ does NOT block CreateToolhelp32Snapshot or any of the GetProcess* functions which enumerate WHAT programs are running because PG is not a stealth tool and only designed to block real world malware attacks like rootkits and DLL trojans. Not to hide hacks from games etc if that is what you are after..

 

Also note there are often many other ways to determine if a certain process is running, depending on what the program is.

 

It's really easy to see what Gavin is saying.

Protect some processes from read and uncheck task manager or sysinternal's process explorer's ability to read protected apps and they have no problem displaying running processes anyway.

I still find the feature quite informative. Some apps that you would never suspect, attempt to read all running processes. You'd never know they did this unless something running was read protected.

I always like to learn as much as possible about the programs I'm running and what they do. So I find the feature useful.

Also isn't it possible it could thwart poorly written data harvesting features of some apps? Lots of things like to collect personal settings on your PC like current running processes and they may not use all the calls necessary to really do this.