AppGuard Beta is Live (64 Bit, MemoryGuard)

I saw your updated post just as I was starting this post to include screenshots.

To allow 'guarded applications' to perform write operations to a specific file, one must navigate to the exception folders (& files) button and you'd see this window:



Then navigate to the file you wish to specify (some folk have mentioned the one shown below):



Note, these exceptions apply to ALL guarded applications. For now, we're not supporting application-specific exceptions in the interests of simplicity for the end-user.

Cheers,

Eirik

PS Sorry about the white space in the graphics.

 

Hmm, I thought it would be application specific. With that in mind and losing functions for some apps as well as Avast not being able to update to due Memory Guard and in addition to the constant blinking tray icon, I'm gonna have to be left behind on this one and stick with the last Release version of AG. I really hate having to do that too.

 

So I downloaded this and was thinking about trying it later tonight? General thoughts on those who have tried it so far? Yes, no?

Edit: Wow, no responses...that can't be a good sign.

 

So far the only issue I have is with Memory Guard and some performance issues with Guarded apps, but this will depend on your setup apps used etc

it does have potential, but it is a Beta will continue to test.

 

I've had issues with Chrome, Iron, & Application Host Service. I think once they get MG more refined and default exceptions in place, it will be good. The Install Protection works as advertised though.

 

Any idea where the log file is kept? Or the user must collect manually?

I notice after a reboot, events listed under AppGuard GUI are gone.

Thanks.

 

they are viewed under the windows event logs, for ease of use I would create a custom view/log for appguard

 

Many thanks to 1000db for his excellent product suggestions and event log data. One of the main reasons for this beta is to discover all of the different but legit code injection activities on a wide variety of hosts. His logs featured many. This helps improve MemoryGuard.

Cheers,

Eirik

 

Hi All,

I'd like to ask all beta participants to send in event logs. They enable us to substantially improve MemoryGuard.

Thanks

Eirik

 

Thanks Tony.

 

Hello Eirik,

When is the cut off date for this beta? End of July?

I could only submit mine next Tuesday or Wednesday.

I will only have at least one week's worth of AppGuard Event Logs by then.

Thanks.

 

Originally, end of July. We may extend, possibly release another beta build, all to refine MemoryGuard. I'll meet with engineering Mon/Tues to discuss.

Cheers

Eirik

 

Would it be possible to have the beta periodically submit to BRN the requested data from the event logs or a manual submission function? Even though AG doesn't require updates it could submit info similar to MSE.

 

will AppGuard with the new memortyguard be supprting xp2 32 bits to or only 64 bits?

 

.....

 

Yes, this is on our master requirements list but hasn't yet made a sprint list. Maybe 2.1 release.

 

I checked out this thread suspecting from the title that there might be code injection involved. It seems I was correct. Apparently, this is an example of an attack that the MemoryGuard feature would block. A poster characterized this as injecting data into the spoolsv.exe process. However, I believe he meant code injection. Of course, I could be mistaken.

https://www.wilderssecurity.com/showthread.php?t=277316

(I'm uncomfortable posting in a thread titled with another vendor's brand)

We have some more work to do on MemoryGuard in terms of exceptions for legit code injections. I very much appreciate the event logs that folk have submitted. These will help us improve MemoryGuard.

I'm curious if any AppGuard beta folk have experimented with the little nasty in the above thread. Please note, when testing nasties, something can go wrong, be careful, and better yet, don't use a production system.

Cheers,

Eirik

 

Wouldn't the execution of the original malware file have been blocked by the anti-executable function of AG before MG ever got a chance to prevent the injection?

 

Yes. Sometimes the post I envision in my head doesn't completely make it to the post. I meant to suggest that one suspend drive-by protection so that MemoryGuard could take a crack at it. Nice catch!

Cheers

Eirik

 

Check out this post:

https://www.wilderssecurity.com/showpost.php?p=1711135&postcount=1

If someone has access to it, they should test MG against this piece of malware as MG seems to designed to prevent this exact thing.

 

How so? I have not seen any mention of this malware creating remote threads in the address space of another process.

 

It tries to inject code into other processes by using a pair of drivers that it installs.

However, if I understand correctly, AG would have to be set to allow program launches, but maybe not since it's a vulnerability. In that case MemoryGuard should block the code injection.

 

Hi All,

We're going to release another beta at the end of this month. It will include other new features scheduled for version 2.0. The second beta, like the first, is not to be considered production-ready. Though for the most part its been pretty stable. There have been a few reports that we're still investigating.

MemoryGuard will be turned off by default in beta2 but users will have the option of enabling/disabling it at their pleasure. This is because, as many observed, the current implementation generates too much noise. The 2.0 release in August (possibly in September) will incorporate refinements gleaned from the data gathered during the beta. We cannot work these into a build in time for the second beta. But, the lessons learned seem quite straightforward. In beta 2, with respect to MemoryGuard, we're looking for any other unforeseen issues. The refined MemoryGuard will be turned on by default with release 2.0.

Many thanks to all beta participants. The data and observations you shared with us has been very helpful. Its been a pleasure sending out free license codes, though I wish I had an automated system for doing so.

Cheers,

Eirik

 

How are you turning it off? Can it be turned off in the present Beta without affecting the systray icon?

 

Yes, but it involves a little XML tweaking.

Modify the default policy located at:

C:\ProgramData\Blue Ridge Networks\AppGuard\AppGuardPolicy.xml

Edit it with something like notepad, search for:

<bPreventCodeInjection>

Change the value to false, save the change, and reboot. MemoryGuard is disabled.

Editing policy files like this can be unforgiving. Its always a good idea to make a copy and set it aside before making any changes. If something goes wrong, one can simply use the copy.

Cheers,

Eirik