AppGuard 4.x 32/64 Bit - Releases

Thank you! I don't have a lot of free time for my studies right now, but I try to do what I can.

 

Thank you!

 

Thank you!

 

I suppose I expressed myself incorrectly again somehow (I do that a lot), can't say I'm surprised. Maybe another attempt will help to get my thoughts across?

I didn't mean to say that what you are working on/already found (I had no idea about the naming thing and honestly don't understand at this point) isn't important. Instead I should say that I am wondering if you [BRN] are 'looking at it wrong' (instead of going in the wrong direction). The problem I see on my end, given what you've said about the naming issues you've discovered with ImDisk, don't seem to match up.

I suppose part of my wording before came from my experience with the new alert on an existing (ImDisk) rule in the new beta. It only happens in Locked Down mode. Just like the original issue I was hoping you could reproduce. So unless it's an oversight of when this new check is made I am suddenly back to the same question: If Protected mode works, why doesn't Locked Down?

At this point it's only a hunch on my part, call it (yet) another crazy theory...but I am thinking if you can reproduce the issue as I originally described and then find the difference between locked down mode and protected mode which allows one to work and not the other then you might already have the solution for the all the problems in your code. eg make a few extra calls in locked down mode, port over some of the code from protected, whatever...This all, of course, hinges on the idea that the new check is already implemented in all protection modes at this time and that is pure guesswork on my part. I'm likely wrong [again] about it all but I'd sure appreciate it if you could find the time to test it with the soundcard dll to see the issue I was actually trying to report originally in a VM and be sure.

Having certain paths which are not protected by AppGuard (and which the new check/alert doesn't actually fix; just reports in a way) isn't the same as the problem where I see AG failing completely (universally) in Locked Down mode. Call me silly but I think one is worse than the other. Add to that this idea that they could potentially be linked somehow and that the current path [eg in the wrong direction] only solves part of the problem rather than the root issue - well, I cant help but bug yall while so confused.

Maybe if you could answer a question I might have a better idea of what the new check/alert is expected to accomplish.
The wording of the alert is vague -' unrecoverable error'. Does this mean that AppGuard should be expected to provide zero protection (and if so why doesn't the tray icon change to an X?) until the offending rule is removed or simply that it couldn't process/protect a certain rule(s)?

I am thinking it means that it can't protect certain paths so if I'm wrong already then there is no reason to ask more questions yet.

 

So if i want protect my portable apps, i have to relocate them in the system partition, am i right?

I used to put them in other partitions to reduce my system partition size and isolate it from those apps.

ok so i removed the rules, so i have to run those portables apps under User Space Launches: "unguarded"

 

Yes this error

 

From what i understand now, AG at its current state cant provide protection from programs not located in the system partition (whatever they are in other partitions, ramdisks, virtual disks, etc...).

Lockdown mode works differently from Protected mode, it is tighter and enforce specific mechanisms described in the help files and it is why you encounter issues as do i.

So at the moment , under Lockdown Mode, we have 2 choices. Install/use progs only located in system partitions or remove those soft rules and run them as "unguarded"

 

Are any of you adding external drives partition to the user-space? External drives should already be part of the user-space by default. It always has been. It's listed under the User Space Tab as "Removable Media".

 

My other partitions (on same HDD) are set as User-Space (for security sake).

 

Strange - not for me on 8.1 but I am still on 4.3.9.1 beta.

 

BRN confirmed it; to be fixed next release.

 

so i re-updated AG to the current beta version, removed non-system partition-based rules; all works fine.

 

If WPS is Guarded, then those events are expected. Are you speculating that there should be more events? It really depends on what is happening with the WPS software. The only way to prove that AppGuard is not blocking something it should be blocking is use Process Monitor and see if WPS is actually trying to write and is successful.


BTW, AppGuard does suppress some messages by design, but only when they appear consecutively within a short duration (milliseconds).

 

We're still testing non-partition rules. They seem to work okay as long as there was a reboot after the partition was created and before the AppGuard rules are created. More to come...

 

There was a problem at the Application layer that was caused by an unexpected disk volume name. Unexpected names are now handled (in other words they won't cause a problem with AppGuard), BUT rules with the non-standard names are not enforceable currently.

We have been able to reproduce parts of your problems. We'll try to get to the nuances of the sound card dll before we do our final release.

 

Install Mode should not be blocking the installation of *.job files for Task Scheduler.

 

Normally, as a good practice, partitions should be created before installing AG

but i can understand that some users would create some after.

 

I fully agreed with this. I've always created prior AG install and post AG install too.

 

Glad to hear it. Thanks for the explanation as well.

While trying to find new ways to test for the issues I brought up before and get a better grasp of them I came across a *potentially* different issue but its close enough in results that I can't be sure.

The steps were rather simple performed in a Windows 7 VM:

Set AppGuards protection to off
Launch an unsigned application from a Shared Folder (Network) and keep it running.
Set AppGuards protection to Protected or Locked Down Mode.
Attempt to launch an unsigned application from the desktop.


An unsigned app on the desktop (userspace) is allowed to launch.
AppGuards lauch protections are not being enforced and no alert or notification that it isn't operating properly is issued. AppGuard seems oblivious.

Close the application launched from the network drive.
Re-test unsigned app from desktop.
Same result.

Toggle between AppGuards protections to 'refresh' it
Re-test unsigned app from desktop.
AppGuard now works and blocks the launch.

Update: Having trouble reproducing it suddenly, must be another factor involved again. Maybe I had the soundcard dll loaded on that machine? Oh well, I'll let you know if I figure it out but for now there's no reason to test it on your end.

Update2: I was using a previous beta version to avoid the blocking of the ImDisk path for my other tests. After updating AG to the latest beta I found it only happens when, are you ready for this, an ImDisk is mounted and a rule exists for it in AG.

So the good news is that the added check/block should prevent someone from creating a rule that causes this to happen.

The odd news is that while I got the alert "unexpected error" once, switching between modes without removing the offending rule did not cause it to pop up again. I seem to recall different behavior when I tested it on a real pc. (Possibly related so I added it just in case, but I doubt it)

The bad news is that this may mean there should be another check somewhere else.

I'm just plain confused again.

 

Ok, that's not the same. Are those partitions on the drive with your OS?

 

Not true. Please see my last post on this. AppGuard 4.x 32/64 Bit

 

My head hurts, I'm so confused about this. I do think that more error checking is in order and I think that we can improve so that at least some of the rules are applied and the offending rules are not applied (and reported to the user). The problem with doing this quickly is that the rules are set several sub-functions deep in the service (and this deep in the code, the functions aren't available to report errors to the GUI or to the Windows Event Log). The functions report an error code up the chain of the parent functions where the error can be finally reported. To report which rule failed, we need to add some info in the return code. The best solution is to not allow the user to add the rules in the first place (which is what we did), but this does not help those that already may have these rules in place. Hopefully there aren't that many users out there that added IMDisk rules to their AppGuard policy.

I'm happy to report (again) that my initial fears about rules for non-system disk partitions being problematic was a red herring (i.e. there is no problem).

 

Here's the latest beta: https://blueridge-engineering.s3.amazonaws.com/AppGuardSetup_4_3_12_1.exe

These are the changes:

1. “Unrecoverable” message wording has been changed to less intimidating wording. This message appearing is actually a "feature" to warn when an invalid rule has been set. I think the original wording was unfortunate because it led even me to think that there was a crash situation (and I even approved the original wording so I have no excuse except that I'm old).
2. Bug fix for the publisher settings flakiness reported yesterday.
3. Bug fix for a bug our QA department found (I almost hate to tell you all about this one because it might get you looking for more like these): Select one of the "Allow xxxx Launches" menu options. The icon will change to show lowered protection. Click on the "Customize" button on the main GUI. The icon changes to show that protection is on (but it isn't!). I actually wanted to mention what caused this bug. For some reason (unfortunately the developer can't remember why and he didn't leave a good comment in the code or the source code repository), when the customize button is clicked, the GUI requests that the policy be updated from the Service) and this request is what causes the status to get out of sync. Anyway, Cutting_EdgeTech, you were right about the delay when clicking on the Customize button. There is a 500 millisecond delay added while waiting for the policy update. You are observant to notice a 1/2 second delay!!!
4. Cutting_EdgeTech's issue with java programs not being discovered (fingers crossed). Actually Cutting did try the fix last night, and it didn't seem to work, but the policy version was incremented in this build so this should force a merge of the new policy with the old policy (and maybe that will set things straight).

 

No such luck. I installed this build over the last beta build, and rebooted. Java was still not on the Guarded Apps List. I then reset all settings back to default. Then I rebooted again, and Java was still not on the Guarded Apps List.

 

I will try AG without Eset Smart Security installed soon to see if Java is added to the Guarded Apps List then. Maybe there is a conflict.