Discussion in 'other anti-malware software' started by novirusthanks, Dec 17, 2017.
Windows 7 x64, Sandboxie, NOD32. Uninstalled test 14 using Revo Uninstaller Pro, installed test 16, runs smooth no glitches.
A question: After an uninstall of OSA would it be better to restart the computer before installing the new build?
this is best practice.
I've been using OSArmor test 16 for about 8 hours without any problems so far on Windows 10 X64 Pro.
OSArmor is a BB; its intended to supplement ERP which is an AE, providing complete all-around protection.
Yep, this is the reason why I'm looking forward to ERP 4.
OSArmor seems to me like ERP 4 with some predefined rules (ERP Lite). These rules should be default rules in ERP 4, too.
Its a BB because its set and forget it. ERP is more configurable, which is what you want with an AE, setting rules to define what executables to deny and to allow.
They protect in somewhat different ways and there is no conflict with them running side by side.
OSA warnings on Blocks - Can this be set or adjusted? Or Wait for user input? Am I missing something?
Here is what happened to me today. I had ran a SFC on my Win 7 box cause I surmised something was wrong. Some files did not get replaced by the SFC and research indicated that running KB947821 would assist me. Research indicated that this 500 MB monster can run from 30 minutes to 8 hours. So I went and did something.
Note. I forgot to turn off OSA. (Shame on me - lesson learned ) Something I would guess than many casual users would do as well.
Later I was checking to see if that Update had in fact ran and it appeared it ran but did not do anything. hmmmm It ran for a couple of hours and there was no indication that it had NOT worked - a Pop Up or whatever.
And no pop up that OSA had done anything - I was not sitting here watching the screen.
In digging thru the OSA logs I found this:
Date/Time: 1/7/2018 6:24:52 AM
Rule Name: Block execution of suspicious command-line strings
Command Line: "C:\Windows\SoftwareDistribution\Download\Install\Windows6.1-RTM-Client-NEUTRAL-AMD64.EXE" /q /x:..\..\..\CheckSur\v1.0
Signer: Microsoft Corporation
With 13 entries for each of the upgrades that were packaged in this KB.
In this case there was no message from the KB Update that it had not in fact succeeded. Nor any pop up or indication that OSA had prevented it.
And YES - I should have thought about it and dropped Protection. Or changed my settings for that rule.
But I have been trying to use this like average Joe or Jane might. That and Age Induced Forgetfulness
So far no issues with test build 16. Running Windows 10 x64 fully updated. At the moment I am also running EAM and Heimdal Security Pro alongside it.
Its intended for the average user. Nothing to configure and if you need to set rules then something like ERP is more suitable for advanced users.
Nothing to configure? That's not true. What about exclusions? I guess you could just chose to deactivate options but that lowers security dramatically. There will never be a set-and-forget security app. Tweaking will always be needed, because what works for one will not for someone else.
Huh? Average user would think his/her M$ Updates were installed and they weren't. I was running at that point out of the box configuration.
A Big Pop up saying:
Do you REALLY want to disallow installing these Critical updates? Y/N/Dunno.
Would be helpful. Such a popup did not occur. They were auto blocked by OSA unbeknownst to me. Average user would have no clue.
We can add an option like "Do not close the warning popup when something is blocked" + we can add a button like "Close" to manually close it.
So if you go away from the PC, when you come back you can view it and close it.
Thanks for posting the log, I will fix the FP later and upload a new build.
Ok, will try to reproduce.
If the user returns to the PC and OS Armor has blocked for example 50 processes in the meantime, the user must click 50x times on "Close"?
Or is it displaying the latest blocked process and only one click is needed to close the dialog.
If the latter, an idea might be to display the amount of blocked processes in the dialog ("and [<insert amount of blocked processes here>] more blocked processes") so the user knows that there were several blocked processes while he was away.
Can we categorize the anti-exploit tab page something like that:
Thank you. My biggest concern is/was with the typical ignorant user. Since it operates sequentially I presume, in a case such as mine it would stop on the first encountered in the installerr? There were 13 .exes that were bundled in one big package. All blocked. Unbeknownst to me.
" I will fix the FP later and upload a new build."
So then you consider the blocking of the OS upgrade package was a FP? I was not sure, but scratched my head. Again - my concern is with average user. We want them secure - not frustrated.
TY for ALL your efforts on this exciting project!
I assume, because it's been done numerous times before, that he is going to tweak the internal ruleset to prevent the blocking of windows updates (which your log suggests was done.) Essentially, novirusthanks has your back....no user intervention required for this obvious FP.
Here is a new v1.4 (pre-release) (test17):
*** Please do not share the download link, we will delete it when we'll release the official v1.4 ***
So far this is what's new compared to the previous pre-release:
+ Block execution of .wsh scripts
+ Block execution of .reg scripts (unchecked by default)
+ Enabled by default "Block execution of .vbs scripts"
+ Improved internal rules
+ Fixed false positives
To install this pre-release, first uninstall the old one.
Yes, the idea is to display the latest blocked process and only one click is needed to close the dialog.
Yes we will do that, but in next versions.
Yes, it was triggered by an internal rule, it is fixed in this test17.
Much thanks for reporting it
Thanks, will do.
17 running grrreat. I uninstalled 16 but no reboot before installing 17. Andreas knows how to write an uninstaller, desho ka?
I will most certainly buy a license for OSA, when such is available. I MUCHLY appreciate folks who continue to support XP.
Now that I have dumped Zemana, I'm using DrWeb CureIt for periodic on-demand AV scans. I shall probably buy DrWeb's realtime AV, but doubt I'll run it -- simply a purchase to express my thanks for CureIt. CureIt even has a Users Manual!
For Andreas: The element that explains the appeal of RPG games to many programmers is neither the fire-breathing monsters nor the semi-clad, sexy damsels-to-be-rescued. It is the joy of writing a program from start to finish without any change in the user requirements.
Andreas, can you also allow OSA manual disablement to persist on reboot for those programs that need reboot to install?
Unless it already works like that.
I'm running build 17 and like the previous two or three builds the system tray GUI icon doesn't load although OSA is running in the background and reporting events OK. If nobody else has this issue then it's probably confined to this one machine.
UPDATE. I've just uninstalled Heimdal because it was slowing my Internet browsing and not allowing some pages to load properly. After a reboot OSA is now back to normal. Go figure!