AppGuard 4.x 32/64 Bit - Releases

The instructions I got was just run it over your old copy and all will be fine. So thats what I did.

 

SIR****TMG, thank you for the upgrade instructions recommended by BRN! I didn't bother asking BRN since I believed either upgrade method would work. I uninstalled the current build first, and installed the latest build. All settings were preserved on my machine using that method also.

Edit 1/19 @ 11:24: I used the license sent to me with the latest beta build, but Barb's post above says you don't have to if you are upgrading from the latest stable build. I'm not sure if using the method I used to upgrade will prevent users from being able to use their previous license, or not. I don't think it will prevent them from using their previous license, but i'm not sure.

 

bothersome to have to wait a beta link via email...

 

Feel same here, could anyone please?

 

the link should be posted on this thread; it is not a closed-beta AFAIK...

 

I would send it to you, but I don't have permission to. You know how it is when you work with developers, and the trust that goes along with it. Barb sends a new license in the email with the link, but you can use your old license also. I agree though that it should be easier to get more timely access to the beta.

 

yes i know. i have my own license , don't need another. just need the installer

they really should have their own forum with a (closed) beta section. still wondering why they don't do.

 

Someone missed the point on the wild-cards; users don't just want embedded support for User Space and Power Apps - they want the ability to white-list command lines.

They also want alerts so that they can Allow or Block events - instead of having to manually configure AppGuard from a log - in a tedious, after-the-fact manner.

 

Yes, I don't know why they only added embedded wildcard support. I was going to bring that up to them tomorrow. In the case of PowerApps it already takes care of what one would do with a wildcard when using *, but I would prefer to use hashing in some circumstances. I already sent them several recommendations. I definitely don't want them to remove the Locked Down setting from the Slidebar. I've also reported some other bugs recently that they are going to fix in this build. They already fixed a bug with the service that I reported in this build. I checked to make sure that it has indeed been fixed with this build.

 

I guess they figure AG gets more exposure on Wilders. People may come to Wilders for many different reasons, and they may learn about AG once they become an active member on the forum. A closed forum for beta testing only would be great. It would be more beneficial though if AG development was more active. I'm not sure what the cost to benefit ratio would be for them. Emsisoft has a closed beta testing forum, but active development is always going on.

 

A few more points about Beta:

1. We are going to limit the beta to those that are already familiar with AppGuard. If you have changed your email address, it would be helpful if you include your current License ID (available on the Help->About menu item) so that our Ops people can find you in our system.
2. You cannot upgrade your current version with the current beta. Hope to have a fix soon.
3. We understand that many of you use Locked Down and will probably not like the removal of it from the GUI, but think about this from the perspective of an average user. Our view is that with the Medium (now just "Protected") level, you are Protected from all* malware. We do all of our live malware testing and demonstrations using the current Medium level. Having Locked Down was confusing people and causing their updates to fail resulting in increased customer support calls. In fact many here were pushing to remove Locked Down all together. Also, as I was modifying the help in support of the new UI, things became much simpler to describe (this leads me to believe that this change is moving in the right direction!).

* Of course no product can make the claim to be able to stop 100% of malware, but we have yet to find something in the wild that gets past AppGuard in the Medium (now "Protected" level).

 

`

Did you reboot after upgrading?

With the new build, when in "Locked Down" you will see the "Locked Down" at the top of the slider bar and the icon in the "AppGuard" banner will indicate that it is in Locked Down, but you will not be able to select "Locked Down" from the slider bar.

Those that are seeing the "Locked Down" selection in the slider bar, will you navigate to the Program Files\Blue Ridge Networks\AppGuard directory; right-click on the AppGuardGUI.exe program, select properties and check the version number there (on the Details tab).

UPDATE: Our lab just reproduced. There is an issue with the update process. Sorry we didn't catch it before posting the Beta link. I was rushing them and knew that it hadn't been tested, but really didn't think that it would be an issue (nothing was supposed to change in that area!).

 

PM you my License ID , seems it is long via email.

 

It was a bug that "Install" level was specified for that publisher. The fix is already staged for the next version.

Though, I'm going to enter a bug about not being able to delete until you change the level. That's weird.

 

Actually we'd like to have some control over the beta. Otherwise it becomes unmanageable.

 

I don't know for others, but on my win10 x64 , the UI is the same as before, with all functions identical (sliders , etc...).

AppGuardGUI.exe is still at 4.2.8.0 while "About" say 4.3.4.3

 

Yes, we've established that there is a bug. The reason that the About is indicating 4.3.4.3 is that the Install is "succeeding" and registering verison 4.3.4.3 with MSI, but for some reason the files aren't being replaced. You will need to uninstall and reinstall in order to get the beta to work (or wait for update).

 

Yes a clean install will work, but when i did it, my own license was rejected. seems only the beta license is valid for it, am i right?

Anyway i will test again tomorrow, time to sleep , 2am here

 

The problem with Medium Level is that it allows signed malware to execute with limited rights. Most of us here at Wilders do not want to allow malware to execute at all. That's why we was pushing for the policy of only allowing digital certificates on the Publisher's List in Medium Protection Mode. That will allow the user's software to update while providing better protection. A considerable amount of the Crypto-malware is signed, and it's not just the Crypto-malware that is being signed these days. Times have changed. I think there's one thing that BRN may not have taken into account with Medium Protection Mode. After signed malware has been allowed to run in Medium Protection Mode with limited rights you have all these infected files in the user-space. They are not contained to a sandbox folder that can be emptied like with other sandboxing software. They are still there attempting to execute. The average user may not understand this, and that's even if they know that AG has blocked a threat at all. A threat could have been blocked a month ago, and could still be there trying to execute. Now here comes the really bad scenario. The user then disables AG to install some new software, or to allow some software to update. Many of us here have talked about having to disable AG to allow some software to update. Now that malware that was contained is allowed to run free, and infect the entire System. I still think it's a bad ideal to allow all signed files to execute from the user-space in Medium Protection Mode. Also, what benefit is there by doing so? The publisher's list can still be used to allow one's software to update without having to allow all signed executables.

Edited: 1/20 @ 2:27

 

Your own license should be valid.

 

Ok Barb mine all say the wrong numbers in details 4.2.8 ,not 4.3.4.3 so Ill wait for true update fix.

 

Let me first thank you for the thoughtful feedback.

That feature is in the works. Maybe ready by the time the beta is over.

We're definitely aware of it. That is why we recommend that users still run a free AV. Eventually they catch up and do the cleaning.

After a reboot, the malware files would actually become dormant - they would not continue to try to execute. They are not trying to run because there is nothing that would trigger them to launch. For example a typical way that a malware becomes persistent is to put an entry in one of the "run" registry keys. Because a digitally signed user-space application is guarded, it cannot write to these locations. If you know of one that we're not protecting, let us know. There are exceptions to this: for instance a downloaded malwarized document. I suppose someone could have AppGuard in the install level and re-open the document or re-visit a corrupted web site.

The benefit is ease of use. I would venture that most end-users don't even know what a publisher is. Our goal is to provide the best malware protection using our default settings without affecting the productivity of the user.

I suppose when the user slides the protection to Install or Off for the very first time, we could have a popup that warns them that they should close all documents and browsers when going into the install mode.

 

I'm still not sure why schtasks.exe is just now being blocked on my machine by AG. schtasks.exe was added to the user-space by BRN a long time ago. Below are the 3 scenarios that I can think of that could be causing the sudden change in behavior.

1. BRN corrected a bug that was preventing AG from correctly blocking schtasks.exe in previous versions.
2. BRN introduced a bug in this build that is causing this change in behavior.
3. Something has changed on my machine that is causing schtasks.exe to run which would mean it did not ever run prior to this since AG is just now saying it is blocking it.

 

I was aware that AG will block many malware from running due to it's registry protection, but without knowing which keys are protected it's hard to make an informed judgement as to how well AG can prevent malware from running. We have never been provided with a list of which keys AG protects that i'm aware of. A user wanted to know about 2 years ago, and I don't think an answer was ever given. I got the feeling BRN did not want that knowledge to be public domain.

I would be the wrong person to even attempt to list all the registry keys that should be protected. I might know the right person for the job though. She writes malware for testing security products, and then reveals there weaknesses. I'm not sure if she has time to do it though. She is very creative, and has defeated many great security products. I don't want to ask her for too much because she does it for free. To be clear though I still would not want the infected files on my disk. I found a trojan two months ago on a wallpaper website that did not get a single hit on VT. I was informed my version of Firefox was not patched, and that I needed to install the patch lol Yes, AV's tend to catch up eventually, but there's no need to wait if you don't have to.

I think you can only protect so many keys without potentially running into problems. It could be avoided though by providing an option to define exclusions for software that may need access to protected keys. Less knowledgeable users may have to get support at the forum though to help them make registry exclusions.

Edited 1/20 @ 4:46