AppGuard Beta is Live (64 Bit, MemoryGuard)

Could it be because Prevx SafeOnline is preventing while you're on a secure domain? And, due to the conflict between Prevx and AG, Prevx won't display a warning asking whether or not you want to proceed with it?

 

I'm having the same problem with Trusteer Rapport. Given that Prevx has embedded SafeOnline code, the common theme may be that they are both browser protection utilities, which protect the browser memory space in order to guard against keylogging, screen grabbing, etc.

I've mentioned this issue twice now in different posts in this thread (#656 and #679), but no response as yet from Eirik or Barb.

 

@moonblood
That's exactly what I thought at first cause I do have Wilders protected with SO and I turned it off before I uploaded just in case. The manage attachment section keeps telling me it is in progress. I waited several minutes to see if the status would change and it never did.

Anyways, Appguard is a good tool but I think the Blue Ridge engineers really should take a deeper look into compatibilty of these two products.

 

OK, so you managed to take the screenshot, but you just can't upload the images? I don't think that problem would be caused by SO; at least, not directly.

It could be the conflict between both applications or something else in the mix as well?

 

I had AppGuard off when I was uploading, so I really don't know?

Update: For some reason the issue resolved itself.
Here are the Screenshots for my earlier post #800.

 

Some points of enhancements:

1. User space default can not be deselected (ones you add are possible to include YES/NO).

2. On x64 internet explorer 9 RC does not play sounds while playing you tube

De-installing for now, looks promising waiting for 3.1 where all glitches will be ironed out.

 

Agreed. I noticed IE 9 RC x64 won't work well with Flash x64 when using AppGuard. I really think that should be high priority for the next release.

EDIT: I'd like to add that with AppGuard at max, some .wmw files won't have sound either.

 

Prevx has compability issues with AppGuard at the moment. I've notified PrevxHelp about it and he's passed the information to their engineering team.

 

This is true.

And as I have previously said, it can't be assumed that every additional disk partition other than C is user space. Drive D on my machine is a system recovery partition - hardly user space. It's okay to make user space the default for additional partitions, providing the user has the ability to take them out of user space and move them back into system space where required.

 

Just select the partition in the User-Space tab and set Include to No.

 

That doesn't move the partition back to System-Space because it doesn't prevent guarded applications from writing to it. It simply removes launch protection from a User-Space folder. System-Space is where guarded applications cannot write but where applications (guarded and unguarded) can launch.

A partial workaround for this is to add the partition to be protected to the list of private folders that guarded applications cannot access. This doesn't take the partition out of User-Space but it does prevent those guarded applications for which privacy mode is enabled from accessing it. There are two reasons why this is only a partial workaround. First, depending on how AppGuard is configured, not all guarded applications may be running in privacy mode. Second, an additional partition may be created to hold programs, some of which may need to be guarded, in which case adding the partition to the list of private folders wouldn't work.

I feel this could have been solved in a simpler way by allowing the user control over which folders lie in which space, permitting movement in both directions between System-Space and User-Space in order to override the default AppGuard configuration, as required. As currently implemented, folders can be moved from System-Space to User-Space but there does not appear to be a way of moving folders from User-Space to System-Space.

 

Nice surprise to see Appgaurd's protection agent uses very little CPU and all its disk I/O is cached by the 4GB read-only part of the hybrid harddisk

Laptop owners with a hybrid disk or desktop powerhouses with a solid state disk (SSD) like low I/O. Will enjoy this in setups without an AV.

I have failry standard setups (only Micosoft Office Pro) with all signed exectables. Another pleasant surprise for me was that you can use the safe-admin tweaks: HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System and set "EnableInstallerDetection" to zero (off) and ""ValidateAdminCodeSignatures" to 1 (on). This will only elevate signed programs. To only allow users to install signed drivers set HKEY_CURRENT_USER\Software\Microsoft\Driver Signing,
"Policy" to dword:00000002 (2=block, 1=warn). I changed these after inistalling the unsigned AppGuard driver and executable. The pleasant surprise is that AppGuad functions without any problems when you apply those tweaks after installing AppGuard.

Together with user space and memory protection AppGuard with the above safe-admin tweaks is rock solid defense on x32 and x64 windows7 systems.

 

From log file:

03/12/11 12:24:09 Prevented process <gcswf32.dll> from launching from <c:\users\gabe-gamer\appdata\local\google\chrome\application\10.0.648.133>

I get the following error message whenever I'm starting Chrome:



How do I solve this? I don't get this on my netbook or HTPC with the same setup and settings in AppGuard (out of the box settings and protection level at 'high'). I think it all started when I updated to the latest Chrome version the other night. I can just click "ok" on the error message and keep browsing the web without any problems. When at protection level 'normal', I don't get the error message in Chrome.

 

I'm not familiar with this one; never saw it. However, I generally recommend that folk use Google Pack to install Chrome into Program Files. This also migrates bookmarks from your user space Chrome.

I'm assuming you're in "High" protection mode from the blocking if a DLL binary, which is unknown to me. As anything may write into user-space, one must regard this DLL with skepticism.

When Chrome is installed in Program Files, processes that consume stuff from the outside world that might be malicious ought to be guarded, then only trusted Apps may place things into system space. One shouldn't guard the Chrome update process, which is NOT spawned but runs independently of chrome.exe.

An alternative to my approach is to create user-space exceptions that tell AppGuard to 'look the other way'. I don't like this because an attacker could target this exception area to place a malicious executable.

Medium protection mode may be acceptable. But if you're running your PC with admin rights, High is substantially better.

Eirik

PS there may be a note in help on installing chrome in program files. Otherwise, it's an easy Google answer

 

Say Folks,

Shall we put this thread with BETA in the title to bed? A new thread might be: AppGuard 3.x 32/64 Bit.

Cheers

Eirik

 

Thank you. Installing Chrome into 'Program Files' solved my problems!

I'm also creating a new thread which you suggested with the name; AppGuard 3.x 32/64 Bit

 

I disabled gcswf32.dll in Chrome's plugins - there are two flash plugins so disabled this one and kept the other one enabled.

 

Is MBR-Guard not available stand-alone anylonger?

Is there any possibility to only install MBR-Guard on an x64 maschine?

 

You could install AppGuard and set protection at 'off' and you'll still have the MBR-guard active.

Please use this thread in the future about questions regarding AppGuard: https://www.wilderssecurity.com/showthread.php?t=294876

 

Thanks.