AppGuard 3.x 32/64 Bit

Are the system folders like Program Files write protected ? I have placed emsisoft emergency kit in program files folder and when I started the program it said the folder is write protected. I had to give read/write permission to emsisoft folder alone to do the update, but my antivirus does not have any issue in updating.

 

1) Yes, read/write access to c:\sandbox folder is needed. I didn't mention as It is in this way since AppGuard 3.X

See https://www.wilderssecurity.com/showpost.php?p=2288586&postcount=3204

2) For me, updates are succesful in Medium level

http://imageshack.us/photo/my-images/24/fvmy.jpg/

 

Pete what OS are you running?

 

Yes, MBRGuard should have been removed with uninstall of 3.x.

It seems that everything worked as expected until your last attempt when you ran cleanmbr unGuarded and expected that cleanmbr would take down your system. What protection level were you in? Did you check to see if there were any additional events in the Windows Event Log? Is it reproducible?

It is good to know that we are still protecting against these types of attacks with the Application layer protection. That is to say that AppGuard still protects the MBR even though it is by way of keeping the executables from running at the application layer.

 

High is recommended in version 3. It is equivalent to the new Medium in version 4.
In fact, we've eliminated the old "Medium" level that was in version 3 because we found that most people never used that level.

Unless you are running on XP, there are no known conflicts with other AV programs. On XP, I believe there may be a conflict with some versions of McAfee. You should add your AV as a power application in version 3.x. In 4.0 you should not have to add your AV as a power application.

 

Sorry. We're looking into it.

 

Let me make sure I understand:

Did you add as power app in 3.x?
Have you added as power app in 4.0? If so, are you seeing different results.

Sorry if I'm being so thick

 

You're right, in Install Mode, Opera should have been able to update itself. Do you happen to have the exact AppGuard blocking events?

Also, yes the new 64-bit AppGuard processes should go in Program Files directory. It will be done in a future release.

 

It's a single activation. If you uninstall (and you're connected to the Internet while uninstalling), your license will be deactivated and you can either install on another computer or the same computer.

Also, if you reformat before you uninstall, you may be able to install on the same computer and use the same license (I'll check with the license people) as the license gets bound to the computer using various hardware identifiers so the same license may be able be recognized on the same machine.

If for some reason, you lose a valid license (perhaps your computer goes belly-up for any reason or you can't re-install on the same PC after reformatting) and you need a replacement, contact Blue Ridge Support and they will most likely authorize an additional activation.

 

Okay, I know that my Eirik was generous with the licenses, but I don't recall him providing any single person with 32 lifetime licenses.

 

Any chance you have the blocking events that were reported when the updates failed. They will be in your Windows Event Log.

 

As long as you haven't added emsisoft as a Guarded Application, AppGuard should not interfere with it. I don't this is an AppGuard related issue.

 

I have a question regarding the inheritance of the guarded app status of guarded apps' child processes. Let's say EA's Origin is located in system-space and not running at the moment. If I launch it on my own it should not be guarded. What happens if it is launched from within a guarded app, say Google Chrome. Does it inherit the guarded restrictions in that case?

 

Here they are from Event Viewer:

• Prevented process <C:\Users\USER\AppData\Local\Temp\CProgram Files (x86)Opera\installing\launcher.exe | C:\Program Files (x86)\Opera\launcher.exe> from writing to <c:\windows\inf\setupapi.app.log>.
  
• Prevented process <C:\Users\USER\AppData\Local\Temp\CProgram Files (x86)Opera\installing\launcher.exe | C:\Users\USER\AppData\Local\Temp\CProgram Files (x86)Opera\installing\launcher.exe> from writing to <c:\program files (x86)\opera\16.0.1196.73\opera_100_percent.pak>.
  
• Prevented process <C:\Users\USER\AppData\Local\Temp\CProgram Files (x86)Opera\installing\launcher.exe | C:\Users\USER\AppData\Local\Temp\CProgram Files (x86)Opera\installing\launcher.exe> from writing to <c:\program files (x86)\opera\17.0.1241.45\opera_100_percent.pak>.
  
• Prevented process <C:\Users\USER\AppData\Local\Temp\CProgram Files (x86)Opera\installing\launcher.exe | C:\Users\USER\AppData\Local\Temp\CProgram Files (x86)Opera\installing\launcher.exe> from writing to <c:\program files (x86)\opera\17.0.1241.45>.

 

Was this as a guarded user space launch in Locked Down mode? I gather you must be on an administrator account and allowed the malware to elevate for there to be any chance of raw disk write access.

 

Not trying to take this off-topic, but I'm curious, Pete. . . what was the "other" security program that saved the day? By chance was it ERP?

 

well

 

I checked the event log. It had an error code 80200010 which means no internet connection Guess my internet connection broke momentarily and I dint notice that. Thanks.

 

It was PowerApp in 3.x and ran fine. I removed it in 4.x and it won't run, but does run as a PowerApp. I think it's because it runs from AppData or accesses AppData. Why Blizzard made it run like that, I don't know.