AppGuard 4.x 32/64 Bit - Releases

Just a follow-on question. AG by default only guards system32/regsvr32.exe and powershell.exe, not syswow64 equivalents. Is that by design or should the syswow64 versions be added?

 

Appguard will guard both the system32 and syswow64 versions of regsvr32.exe, rundll32.exe etc as they reside directly in those top level directories.
Any executable that resides in a sub directory of system32 or syswow64 will not have its counterpart automatically guarded. So powershell.exe will need both the system32 and syswow64 versions added.
Clear as mud, isn't it?

 

Yes .
I asked because I had regsvr32.exe for both directories as User Space=Yes (c:\windows\*\regsvr32.exe) in my hardened .xml, but I decided to change these back to Guarded, for convenience.
But in the Guarded Apps tab, if one hovers over 'Microsoft(C) Register Server, one sees 'c:\windows\system32\regsvr32.exe' only. There is no separate entry for sysWOW64. But I guess AG resolves this internally, because I manually added a sysWOW64\regsvr32.exe entry but I see now there is still only one entry ...
With regard to powershell, I have left these in User Space = Yes (c:\windows\*\windowspowershell\v1.0\powershell.exe and powershell_ise.exe) and unticked Windows Powershell in the Guarded Apps tab.

 

The SysWOW64-equivalent is not shown in the GUI, but it is protected. Even if you add it, it is gone from the GUI after you have opened the GUI again.

The counterpart is automatically guarded, this also applies to powershell even if it's in a sub directory.

If i add an executable in a subfolder of System32 as a guarded App, the SysWOW64 counterpart is automatically guarded.
For example after adding the following file as a Guarded App:
c:\Windows\System32\test\abc\csvfileview\CSVFileView.exe
The same protection applies automatically to:
c:\Windows\SysWOW64\test\abc\csvfileview\CSVFileView.exe

 

i can guess because some users only have one partition and it is C:

misread ^^

i think you don't get my point... by putting on another partition, you have less difficulties if you want set AG and Sbie to work together. I dont talk about isolation escapes or whatever...

 

And with all due respect, your comment defeats my notion about Sandboxie and its mechanisms. I'm scratching my head right now just to stop, or not, that acronym crossing my mind: FUD.
I don't understand, honestly.

 

That is obvious, since the issue is related to another soft, he has no obligation to solve it, and could say like any other support team would say "remove the other software"... but he still give input and help, so don't blame him for that...

 

This really seems sarcastic.

@Mister X That's probably why you don't quite understand it.

 

Yeah, maybe.

 

Just noticed someone has changed their handle.

 

And just so everyone knows, placing Sandboxie's sandbox on a non-system partition has nothing to do

The person asked a direct question to solve their particular issue and I provided an answer that solved the problem.

My obligation is not to figure out where that user wants to place the sandbox of a 3rd-party solution. It is not my obligation to explain to any user how to configure their 3rd-party software. Nor am I obliged to provide an answer that encompasses all possible configuration scenarios.

This is a support forum for AppGuard. If someone wants configuration advice specific to C:\ Sandbox for Sandboxie, then they should go to the Sandboxie forum. If someone is trying to get a 3rd-party product to work, where AppGuard is blocking something, then I will help them solve that issue.

However, it isn't my place to explain how to configure 3rd-party software on the system under all circumstances. Like I said, I don't know what the user wants to do with their 3rd-party soft.

It is as simple as that. You can try all day long to make it out to be something other than what I have explained repeatedly. I don't see @Infected complaining about my answer.

 

Yeah, I'm not concerned about the rest of what people are saying about putting sandboxie on a separate partition. How I have my system set up is fine with me.

 

Unfortunately, this detail is not common knowledge among Sandboxie users.

 

Did I answer your question to your satisfaction ? Did it solve the problem you brought to this forum ?

 

Yes. I made a pain ************ by making my handle too long to type - so I changed it to a single word.

 

Yes, as others state, they are also Guarded.

The GUI is designed as it is to prevent a user from having to figure out which file path is relevant under Windows sysnative. In other words, do I need to Guard only System32 ?, only SysWOW64 ?, or both ?

Even with the way it works, it still causes confusion - obviously - but I can assure you that it works. Dependent upon what is installed on your system, you might see a block of the System32 process' corresponding SysWOW64 file path.

The User Space list is where you must create rules for both System32 and SysWOW64 file paths. The easiest, most efficient way to do this is by using the * wild-card in the file path:

C:\Windows\*\powershell

as opposed to creating two separate rules - one for System32 and the other for SysWOW64

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe

 

AppGuard uses explicit file paths and also automatically protects the SysWOW64 counterpart to System32. It was done this way so the user doesn't have to fumble about and make decisions regarding Windows sysnative.

All Guarded Apps are launched Guarded - both the System32 and SysWOW64 file paths.

 

If you add the SysWOW64 file path to Guarded Apps, then those file paths will eventually disappear after closing and re-opening the GUI.

You only need to explicitly specify both System32 and SysWOW64 file paths in the User Space list - when you wish to completely disable a process that has both a System32 and SysWOW64 counterpart process.

The easiest way to do this is to use the * wildcard in the file path. See my earlier post.

 

The igfx blocks seem to randomly occur on my one test system (never at system startup). I am certain it is connected to an Intel task:

01/14/17 12:00:19 Prevented <pid: 3856> from writing to <\registry\machine\software\classes\clsid\{d5f5053a-9585-4d80-8f6f-7b6587cefb93}\inprocserver32>.
01/14/17 12:00:19 Prevented process <pid: 3200> from writing to <c:\windows\system32\igfxpers.exe>.
01/14/17 11:58:23 Prevented process <reg.exe | c:\windows\system32\cmd.exe> from launching from <c:\windows\system32>.
01/14/17 11:58:22 Prevented <pid: 3856> from writing to <\registry\machine\software\classes\clsid\{d5f5053a-9585-4d80-8f6f-7b6587cefb93}\inprocserver32>.
01/14/17 11:58:21 Prevented process <Windows Command Processor> from writing to <c:\windows\system32\igfxpers.exe>.

No harm, no foul.

 

I understand what you're saying, but this AppGuard sub-forum has evolved over the years (at least from Blue Ridge's perspective) for two purposes:

1. General support
2. Beta testing and reporting

As far as general support, the range of topic complexity will vary widely. The whole range of topics remain openly available for other users who might wish to avail themselves of those topics - either by participation or searching the sub-forum. Also, keeping all the infos publicly available eliminates, to some extent, the need to keep re-posting the same topics over-and-over.

 

If you are still placing the sandbox on a RAMDisk then there is little, if anything, to worry about.

 

I know, thanks. Still I sustain my comment above.

 

For what it is worth, your best source of infos regarding such matters is Invincea - but I wouldn't expect them to openly discuss breakouts. I know I wouldn't.