AppGuard 3.x 32/64 Bit

We will be doing a new release soon, but the changes are fairly minor so I doubt that it will require a beta test. The planned changes are:

1. Some minor bug fixes (I'll enumerate them when we get closer to the release).
2. The phone home will not retry if it does not succeed. The max it will phone home is every 24 hours.
3. We hope to fix a minor issue with Office 2013 on Win8 (with AppGuard protection on, you cannot open a file that originated from another computer - the current work-around is to either temporarily disable AppGuard or unblock the security setting on the file properties).

 

The ETA on version 4 is much later this year. We are planning a minor release soon (see my previous post). I would not recommend waiting for 4.0.

 

It does!

 

We just had our Enterprise version evaluated by a 3rd party security expert (which I hope to be able to reference at some point) and they threw 6 attacks at both AppGuard and EMET. AppGuard stopped all attacks. EMET stopped 5 out of 6. EMET stops known attacks. AppGuard stops 0-day (or unknown) attacks. I believe that the Enterprise policy that the testers were using was essentially the same as the "High" consumer level policy.

The AppGuard license is a life-time license! For the version that you buy (and minor updates) you will not have to renew. If we ever make a major upgrade (such as the illusive 4.0), we *may* charge a nominal upgrade fee.

 

Sorry Seven64. I am pushing to get this fixed soon. I can't promise that I can get this to be a user-settable option, but as a compromise, at a minimum it will only check once a day but if it fails to get through your firewall, it will not retry until the 24 hour timer has elapsed.

 

By design, in Medium through Locked Down protection levels, AG stops MSI installs. Set the level to Install or Off and AppGuard will not interfere with MSIs. To my knowledge, AG does not usually trigger BSs for most MSIs. AppGuard may interfere with a program installing properly, but I don't think a BS is usual.

You should be able to just turn AppGuard off and uncheck the re-enable checkbox. Turning AppGuard off from the GUI does not turn MBR Guard off:

 

Based on our last email exchange regarding this issue, I have asked legal to revisit this once again. The agreement was written primarily for our managed service customers who use the Enterprise version. The Enterprise version automatically sends us their logs and that is why the TOS is so general. The holdup now is that the legal department wants to identify what we might be "collecting" when AppGuard phones home. I know that the AppGuard application is not "sending" any data - just reading the version number from the web site, but just by virtue of accessing the website, the website is able to record the IP address from the originating PC. Anyway, I'm frustrated too, but anytime you involve lawyers it seems like the most simple things require a major effort (I shouldn't be so disparaging of lawyers, my daughter will be graduating from law school in May).

 

No. They are virtually the same. There is one known anomally on 64 bit systems. If you have the 64-bit version of Office installed (most people use 32-bit even on 64-bit systems), you need to explicitly add the Office Applications to the Guard list. This will be fixed in the upcoming release.

The consumer version of AppGuard has basically the same protections that the corporate version has, but in the corporate version, the AppGuard policy is centrally configured. Also, the end-user cannot add applications to the Guard list or change the folder definitions. It is intended for corporations that use a standard image and do not necessarily provide their end-users with admin priviledges. Also, the enterprise version collects the log information from the PC and sends to the central management server. The central management server requires a web server as well as a SQL server and an FTP server (two recommended) to deploy.

It is signed by Blue Ridge. You get the prompt because it is a kernel level driver and it is not signed by Microsoft.

That is currently not possible in the current release, but we will consider it for a future release.

To answer some of the concerns in the 1st url:

AppGuard automatically Guards most vulnerable applications without the end-user having to add them.
​

To answer some of the concerns in the 2nd url:

• Explorer.exe cannot be guarded without crippling your PC.
• InstallGuard (which is on in all levels except Install and Off) blocks msi's (unless they are signed by a trusted publisher) from being executed.
• AppGuard blocks vbs files from being executed from user-space.
• AppGuard will not allow a system executable to launch a file from user-space (unless the system executable is defined as a power application).

 

I'll see if we can get this into the upcoming release. In the meantime, have you tried disabling Privacy Mode for Adobe from the AppGuard tray menu (I understand there may be a chicken and egg type situation though if you're just trying to double-click on a PDF and don't have Adobe open already)?

 

I think someone may have responded to this already, but if you click on "Ignore Message" you will see the path. I have requested that we add another context menu item to provide this info as well.

 

Thanks for getting back to me on this. I'm still having problems with AG and Sandboxie. I have no problems with Palemoon, Comodo Dragon or when running Pidgin and Thunderbird with Sbie yet when I launch Opera I get this message SBIE1241 Cannot mount registry hive: [C0000034 / 22] and when I try and launch Firefox it says it is already running. I would like to buy AG, it offers good protection and is really good value for money but only if I can get it working properly with Sbie.

I would be grateful for help from any forum user.

 

Isn't that patching the kernel? I though PatchGuard prevented that.

 

Early congrats to your daughter! I myself do not care that AG phones home as long as it is only sending non personal info.

 

Hello,

From the The unofficial Shadow Defender Support Thread.
Post # 2293

Post # 2294

The way I understand this is as follows (please feel free to correct me if I am wrong):
The AppGuard Agent (which is the windows service) starts first well before the GUI does by registry key for service to start on boot. It is the Agent that does the actual protecting. Secondly, quite a bit later by a CurrentVersion/Run registry key, the AppGuard GUI starts. The Agent is actually protecting you before you even see the AppGuard GUI icon in the system tray. The red x appears as the GUI starts and is connecting to (communicating with) the Agent. Once this connection (communication) is established, the red x changes to a green check mark to signify that the GUI is now connected to and communicating with the Agent (service). There is nothing to worry about lapse of protection on boot as the service starts quite early in the boot process. Technically, you do not even need the GUI to be running to have protection, as the GUI is only providing means to alter or customize settings and to notify the user of blocked actions by AG. I HTH and maybe explains the red x and green check mark a bit.....

 

Thanks for your reply
How about powershell.exe?
Also, does the built-in Windows update from Vista and higher work properly with AG or does protection need to be lowered when Windows installs updates?

 

Thanks Peter,

I wish I could remember when and whom told me the above as it is a bit confusing. I am almost positive the GUI does not have to be active to be protected, so then it would seem for some reason the Agent is not starting as fast as one would think. I hope Barb_C will be able to shed some light on this as it would be nice to have a definitive answer as to when protection should be active, and whether or not the GUI must be running for protection to be active. I would have thought as early as I see the Agent starting on boot on my system that protection would be available sooner.

Thanks again...

 

I too tested this and can confirm your findings that the protection isn't working until the tray icon turns green. Just to be clear about what I'm saying here, the status of the tray icon at start-up is only an indicator as to when the protection provided by the AppGuard Agent service is operational. It is true that protection is entirely dependent on the AppGuard Agent service, not the AppGuard GUI process. The AppGuard GUI process doesn't have to be running for protection to be active.

 

You are correct.

 

Windows updates work properly 99.9% of the time especially on Windows 7. We were having issues with XP because some of Microsoft's updates were not digitally signed for XP and some of the older Office products. I think as Microsoft is signing more and more of their updates, we will get even closer to 100%. I have recently added c:\windows\system32\wuauclt.exe as a power application (that is the windows update agent) per Kees1958's suggestion and we will be testing that with our next release (it may become part of the default policy).

 

I agree that this part of the UI needs to be improved, but I don't think adding an entire folder of applications is the way to go. The number of power applications should not exceed more than a handful (about 10 at most). With our inheritance mechanism, only the parent application needs to be made a power application - any application that it invokes will inherit the power app property. Perhaps we could use the same mechanism that we use when we create the dialog from which users choose Guarded Applications (we are enumerating the applications based on the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths registry entry) to select which applications should be made power applications. For each Application that is installed, the common practice is for the vender to provide an entry for the default path in this registry key during installation. You would still have the ability to browse for additional files if the vendor doesn't adhere to this guideline.

I guess my recommendation would be to start with the application listed as the default in the registry key and then monitor the events to see if other applications are being blocked. I realize until we make a GUI improvement, this is not something that a novice user would be able to do.

 

I hope that this capability will be in the next release!

 

We've been focusing on the enterprise version of AppGuard. The consumer version was actually ahead of the Enterprise version as far as features and bug fixes were concerned. Now that the Enterprise version is caught up we will return our focus to consumer AppGuard.

 

Safer would be to add as MemoryGuard exception. The difference between a PA and MG exception is rather subtle (in fact we are considering removing MG exceptions in the future to simplify the interface). For example if a MG exception is located in user-space it will not be able to launch in locked down (or high if it is not signed). PAs are able to launch in locked down no matter where they are located. Also, the PA property will be inherted by any application that it launches. This is not the case for MG exception. Also, be careful if you are setting an application as both a PA and MG exception. MG exception properties take precedence. This can be a problem if you set a PA as a MG write exception (vs. ReadWrite). In this case the PA would not be able to Read memory. Not sure if most would consider this a bug or a feature, but that is how it currently works.

 

Is that true? MG exceptions aren't working for x64? Not sure we knew that. Will add to the list to investigate for the next release.