AppGuard 3.x 32/64 Bit

thank you so much for you in depth explanation Barb_C, will try that out and post the results soon.

 

Lol, kinda defeats the purpose when you put alot into the PowerApps. I like the Locked Down mode with don't notify me about anything.

 

Wow.. the more Power Applications one adds the more likely one is to create a hole for something nasty to slip in. I would only add security applications as Power Applications. Why are users using so many?

 

So that's why, I've added Sandboxie's Executables ( Needed for it to run sandboxed apps), Microsoft Security Essentials' Executables, and MCShield 2's executables (Although I uninstalled MCShield now as with AppGuard, it's not needed).
EDIT: FYI, it's all security applications with many exe's, lol

 

The following description on the PowerApps tab suggests that there shouldn't be any need to routinely add security applications as power applications: -

"Typically only other security products should be added as power applications and only if AppGuard is indicating that it is blocking the security product's operation."

Even before PowerApps was introduced into AppGuard, I've run AppGuard alongside a number of other security applications at different times without issue, including Sandboxie and MSE 4, so I'm surprised that people are finding it necessary to add so many executables as power applications.

 

It's actually suggested at Sandboxie's forum to include it in PowerApps, as for other, I just find it a habit to exclude security application with each other to prevent slow down. I guess I'm wrong, as I've already uninstalled MCShield, I guess, I'll just remove MSE in PowerApps, but Sandboxie will stay because of compatibility problems.

 

I had a look at the Sandboxie forum and it appears that the issues reported are on 64-bit Windows 7 systems, which is probably why I'm not seeing any problems as I'm on 32-bit Windows XP. If you are on 64-bit Windows 7 then I agree it may be necessary to add the Sandboxie executables to PowerApps if that's the only way to resolve the problems reported.

 

Yup! I'm on Windows 7 x64. I've already removed MSE from PowerApps and retained the default and Sandboxie.

 

You shouldn't have to add all of a security suite's exe's as power applications unless they are called individually. If they are called by a parent power application they will automatically become power applications themselves. I think that would cut down on the vulnerability because malware cannot some how take advantage of the child programs. They would only become power applications if called by a designated power app. Of course I don't know how your security products are architected so maybe it is necessary to specify each exe as a power app.

 

Hi Barb, sorry it took me so long to reference those post I was telling you about. I just completed a huge relocation, and now i'm trying to break in a new career field. The following post below appear to be different possible bugs than those bugs reported by BRN. If i'm mistaken then my apologies! These appear to be similar to what I was experiancing on XP x 32 where I was unable to add a Power App by browsing to the application from within AG. Instead I had to type in the full path to add the application. I was informed that BRN could not reproduce this, but I can 100% of the time on the one XP x 32 machine I tested on. Their appears to be nothing wrong with the machine since the beta build worked just fine on that machine when using the same image as now. I'm just trying to insure that Appguard is the best quality product possible since it's a favorite of mine.

Post # 958
Yes, I have the same problem since day one of the release. I just thought it was my system and waited to see if anyone else got it. Well I see that you got it also.I'm using windows 7 and 64 bit......same problem indeed........

Post # 961
Now I also experienced this, but it's to random, sometimes I can add a x86 application, but sometimes nothing is happening.

Post # 967
Hi, Using 3.3.4.0 and I'm getting weird behaviour when adding a folder to Guarded Apps-Folder-Settings.
I select folder and a blank line is added to the list with the drop down box available.
If I accept this then go back to add a different folder, Appguard says "directory <> already exists" and refuses to add (another blank line) to the list.

Windows7 Enterprise x64. No UAC, MBAM on demand, Sandboxie added to power apps (only Internet facing apps sandboxed), Appguard Locked down .
This also happens on High setting.

Can I go back to the previous version if this is a serious bug, without getting the on boot pop-up to upgrade?

Thanks

Post # 968
@delah, this is a known bug that the developers are aware of. Until it's fixed, if the browse dialog is blank or it's showing the parent directory and not the actual directory you want, you'll have to manually type/edit the path

 

Thanks, Cutting. I appreciate your comments and we welcome all feedback - good and bad (in fact the "bad" feedback is more helpful when it comes to improving the product!).

Thank you for taking the time to collect all of these references. They all are related to a bug that was introduced with the changes we made to the "Browse" dialog in 3.3 (we have been able to reproduce in-house now and it will be fixed in 3.4). Since you and I have identified a viable work-around for this particular bug (i.e. manually typing the path if it doesn't appear by browsing - see post #974), it is still my opinion that 3.3 is the recommended version to use (vs. sticking with 3.2).

There were other bugs identified in 3.3 but they are related to power-apps or are also in 3.2 so reverting back to 3.2 gives you no advantage in this case (my logic here is that it is better to have a buggy power-app feature than no power-app feature - note the power-app bugs do not affect all platforms or are related to child processes of power applications - not the power apps themselves). Also 3.3 provided some bug fixes for 3.2 bugs and additional protection (blocking at.exe and schtask.exe attack vectors).

Since 3.4 will address the power-app bugs and some more of the older 3.2 bugs, I understand if anyone would prefer to wait for 3.4 (which I hope will be out next week) insteading of going through two upgrade processes.

P.S. Good luck with your new career field!

 

Speaking of version 3.4: As I mentioned last week we hoped to release some time this week. That is still a possibility, but most likely it will be next week. We've been waiting for Microsoft to respond officially about whether one of our potential "bug" fixes would compromise security. Based on their preliminary response we don't think that we can include the bug fix so we will release 3.4 without it and include it at a later date.

This particular bug relates to AppGuard interfering with audio on 64-bit WMP and 64-bit I.E. The work-around for the time being is to use the 32-bit versions of these applications (even though running on 64-bit OS).

I do have a couple of questions for those that reported the audio problems: Is there a reason that you are running the 64-bit versions of these applications vs. the 32 bit versions? It seems that all of our Windows 7 64-bit PCs come configured to run the 32-bit version of these applications by default. We have to actually browse to the 64-bit version in order to run them. Did you change some configuration settings to use the 64-bit versions by default?

 

I agree. A quiet AppGuard makes life easier for me - I don't have to answer questions about why AppGuard is blocking what it is blocking

Here is my stock answer to that question:

Unfortunately you really can’t know if AppGuard is blocking malware or whether it is blocking a legitimate application operation without doing extensive analysis of the events and files involved. AppGuard does not make a distinction between malware and legitimate applications - it just blocks suspicious behavior. That is one of the reasons that AppGuard is so effective. AppGuard is designed to stop applications from performing high-security-risk activities. These high-security-risk activities are often exploited by malware as entry vectors into the system, and that is why AppGuard blocks these operations – usually with no adverse side effects. These activities may be the result of a legitimate application having been exploited by malware or it may simply be the result of the application programmer not adhering to best programming practices. In the latter case, the legitimate application may be requesting privileges that it really doesn’t require (for instance it may indicate that it requires write access to a system directory when in fact it only requires read access). In this case, AppGuard will block the write access (which is suspicious) and allow the read access to proceed. Fortunately, most of the time, these types of blocks do not result in any side effects even though AppGuard reports the blocking event. Occasionally, where an application actually intends to make changes to the system, such as self-updating programs, AppGuard may block a legitimate action.

 

The main browser I use is Waterfox (x64 Firefox), though it's not set as my default browser. Apart from that, I just like to give applications a thorough workout and find as many bugs as possible.

Until a viable fix is found, I can still happily live with the minor inconvenience of switching to Firefox to watch videos.

 

Thanks for responding.

 

So I followed your steps and have to say that it works only for the time the child process (procexp64.exe) exists. The rules that I had to set in Appguard (user space exception, powerapp etc) won't have any effect after the child process (procexp64.exe) is automatically deleted by procexp.exe (when you close the program). When procexp64.exe is deleted automatically the Appguard rules lose track of the original file (procexp64.exe). That is why Appguard blocks all newly created child processes (procexp64.exe) that share the same path as the rules you set up in Appguard. But these rules don't count any longer because they belong to the already deleted procexp64.exe.

I hope it's not too complicated how I explained it but basically Appguard has a problem with the child processes which get deleted automatically every time you close Process Explorer.

You would have to exclude the whole Temp folder I guess to get it working properly but I don't think that is a good idea...

 

You could always just use an app like LordPE to dump the "BINRES" resource #152 which is procexp64.exe, or copy the dropped exe from the temp directory to system space.
You also get a much faster launch directly using the x64 exe.

 

I'm not sure I understand what you're saying. Did you have trouble adding the rules that I specified? Or are you saying that after successfully adding the rules that the power-app feature was still not working? If it is the first case, when the procexp64.exe does not exist, you must manually type in the full path for that rule in order to add it. There are bugs in this area so it looks like you cannot browse to the path and then edit it. Anyway, if it's the second case, will you tell us why you don't think that procexp64.exe is not being treated as a power application (i.e. what AppGuard blocking messages are you seeing)?

 

didn't try that but that might work. I created the rules while PE was running in the background. Maybe if you type the path manually the rules will count for all procexp64.exe created at that location.

Just tried something different btw. I launched procexp.exe just to get procexp64.exe created and then cut the procexp64.exe to a different location and then deleted procexp.exe. procexp64.exe doesn't delete itself as it seems. So maybe I can just run procexp64.exe directly without having to set any rules in appguard.

EDIT: Works now finally. procexp64.exe survived a reboot and I can run it now from system space without any specific rules. I will just replace task manager with it

EDIT2: Just set the image hijack for taskmgr.exe but at first I wasn't allowed to do any write operations to the registry although I have opened regedit.exe as administrator. Turned down protection of Appguard and immediately had write permissions to the registry. I really didn't know that even in that case Appguard protects the system/registry, that's nice to see.

 

Barb, thanks for taking the time to read back through those post! Also, thanks for the good luck wishes!

 

Hows progress going for solutions for identified bugs?

 

Glad you asked. We finally got a definitive response from Microsoft regarding the issue with Audio on 64-bit IE and WMP. We have a fix and are now testing. I will speak to the head of the test department later today to try to get a timeline for the release. With this last fix, I beleive that all known issues will be addressed in the next release.

 

Im not sure if this has been requested before ,but is there any way that appguard can show hidden files and folders ,when using the ADD> BROWSE function?.Its really annoying having to open control panel ,folder options etc just to add something from program data

 

Thanks for the update Barb! I'm in no hurry. I would rather the developers take their time to make sure the job is done right

 

I'll check into it for an upcoming release. It won't make it into 3.4 though.