OSX Beta - Continuation

Ref: OSX Beta (Part 1)

Yes things move relatively slowly sometimes in the cross-platform development so here I am again just a week or so after the annual anniversary of announcing I managed to temporarily break Mac WSA v8.0.1.44 in referenced thread back in Oct 2012 on Lion(10.7) platform and guess what?
Yep looking forward to Mavericks (10.9) I incrementally upgraded my test platform to Mountain (10.8.5) and installed Safari 6.1Seed8 and managed to crash it repeatedly still using WSA(Mac) 8.0.1.44.

Yes it's still the same WSA version as my previous post a year ago as it seems that Joe's contemporary on Mac development team hasn't quite inherited his passionate zeal and tireless enthusiasm that served Prevx so well over previous years prior to Webroot takeover/merger! )

Now Joe did mention a forthcoming beta…. (a year ago), but clearly I'm no longer in the Beta testing loop or Mac versioning change control is radically different to it's PC brother?

Now I know I should raise a support request, but I'm still awaiting some response first from the Webroot Fora in the unlikely event any other Mac users can replicate my scenario as I almost feel these days like I represent only 50% of the minority using a Mac that manages to break this WSA thing!

Anyway the rest of the family is secure with 4 PC seats of my 3yr Family license so I'll hibernate now till October 2014….. and moan some more.

 

I just replied in the other thread - we've put out literally dozens of updates and are on the 8.0.4.x branch, I'm not sure why you wouldn't be there already. Could you try manually updating?

Thanks!

 

As I already post in the release v8.0.4.17 thread I will post it here.

HTH,

Daniel

 

@horseman

I thought that maybe you would be interested in this test with Mac AVs against Mac malware. FYI Webroot is included.
http://securityspread.com/detection-rate-results/

It is updated often. And since no of the Big testing Orgs have done anything like this so far, this is better than nothing as I see it.

 

My thanks to Swex and Daniel for their feedback as well and of course after multiple kernel panics I managed to extricate the Webroot kernel extension(driver) that appeared to have caused the problem!

It appears that (at least initially) Webroot likes to reside in the root of the Application folder and if one attempts to place it into a nested folder then one misses all future updates as well as some confusion with Webroot (un)installer!

In fact I managed to have two instances of WRSA loaded under /Application and /Application/Security during my interim attempts until finally I managed to delete the latter instance.

To prove this I'll need to regress my testbed via TimeMachine but at the moment I'm leaving it as is on Application root and now intend re-testing Safari 6.1Seed8 to see if I can break anything else again!

I also notice that my son's laptop is also stuck on v8.0.3.x (whereas stated by Joe the current and mine is now 8.0.4.231:118 ) so I'll need to check later if his MacPro has a similar issue?
However circumstantially there initially looks like something is amiss with the way WSA (Mac) checks it's version status?

 

Does manually checking for updating on your 8.0.3 system still not download them? Have you changed any of the default settings or customized anything within the product? We'll probably want to diagnose this closer if possible - let me know and I'll speak with the team shortly.

Thanks!

 

Thank you - unfortunately my son (and his MBP) are currently 200m north of me and I don't get physical access until his return on 6Nov. As I recall his WSA install was on a OSX10.8.2 factory default initially with default WSA install and I haven't dabbled with his system, nor WSA configuration other than remote Restart/Scan's which are clearly not being honoured yet.
I'll see if I can arrange a remote session in meantime and report back before 6thNov.

Thanks again.
EDIT: Further update - arranged a quick remote handhold with son and I believe this is a non-issue as we both incorrectly assumed that "engine" updates were automatic and at least on Mac that have to be manually invoked via "Check for updates"! My Q'd cmds also got pulled so will confirm later this weekend that manual update has worked/installed. In meantime my apologies in advance for wasting others(and Joes time) in what I believe was just "Pilot Error" on us users!

 

Updates should definitely be automatic on Mac or Windows, and remote commands should work as well. It may be worth having our developers look at this to see what's happening. Could you PM me with some availability so that I can have our guys ready to take a look?

Thanks!

 

He's a tad busy until his return around 6thNov and even his dad has to book a 30min appointment! Can confirm that at least manually using "Check for updates" has now updated his WSAC from 8.0.3.203 to 8.0.4.231 and does "pull" any Q'd commands.

If he can't predict say a 1hr slot for Derby development (or wherever) before 6th then I'll try some more tests + console/WSA logs with Q'd cmds with whatever time he can give me along with testing mine in a similar fashion over reboots to see if Auto appears to be working now.

 

FYI only - In the meantime I now have 3 boot volumes on same MacBookPro (7.1 with 8GB ram), one MountainLion 10.8.5, one Maverick 10.9 and trusty SnowLeopard 10.6.8. The first two obviously can run WSAC…..but

I find WSDaemon on both is occasionally maxing the CPU for considerable periods. Browsers(Safari & Chrome) on Maverick were both unable to accept my 3rd party 1Password4 vault entries and system temp was escalating.
Rebooting to Mountain Lion I found that two concurrent scans were initiated - which eventually appeared to stall about 90% through. Cancelling these still left WSDaemon maxing the CPU >90%.
A reboot so far has restored normality.

Clearly I'll need to engage Development Support at some point (as per above my son is experiencing similar issues with Mountain and I've advised him to uninstall WSAC before upgrading to Maverick!).

Unfortunately Sod's Law has determined it's not the most convenient time at the moment to interrupt my current work and let WSA Support work their magic. I'll therefore continue my own crude diagnostics in the interim interleaved with work until I either discover what plugin/extension or concurrent app is causing the issue or sufficient time to allow WSA Support to untangle my system.

 

...the saga continues with another update:

I located an issue with Sophos HE 9.0.3 on Maverick volume which required disabling it's Web monitor which was apparently preventing all my browsers from connecting:
http://f.cl.ly/items/3a1b2U3Y0a3H0t3c1e3O/Screen%20Shot%202013-10-26%20at%2021.19.34.png
I subsequently de-installed Sophos anyway and I'm not suggesting it was tripping over WSAC either at this stage. I re-install it later when I have more time.

Meantime I'm intrigued why WSDaemon is caning my system? Around 700k scanned files it starts to load abruptly as per this monitor:
http://f.cl.ly/items/0O1R2t1E3W3b1v3V0E1o/Screen%20Shot%202013-10-27%20at%2007.57.52.png

Temp can peak at 86degC before my tired old MBP fans spin up. Previously I've bottled out from a potential China syndrome and re-booted but I'm going to let this run while I handhold today and it's currently stable at 84degC:
http://f.cl.ly/items/1B2y243p22022Q0Q3S1u/Screen%20Shot%202013-10-27%20at%2008.17.34.png

Finally WSAC detected a couple of potential virus/virii on it's scans although being resourced constrained it only produced blank scan logs. I believe at least two were false+ (1 was thrown by my TeamViewer install) and heres a NDOC framework that I did capture:Automated Cleanup Engine
Starting Cleanup at 2013-Oct-25 17:31:29

Code:

Starting Routine> Detected /Library/Frameworks/Mono.framework/Versions/2.10.2/share/NAnt/bin/lib/net/1.0/NDoc.Documenter.Msdn.dll [Name: "W32.Malware.Heur", MD5: 35dbf954b48a2078f134a18ae799cbd7]

Yes Daniel & co - I know I should raise the latter via support!

EDIT: now upto 3million files scanned and exhaust has peaked at 5347rpm at 88degC - nice knee warmer! I suspect load is proportional to number/size of compressed/zipped files as the perverse (Scan mounted drives) option I set was designed to stress the product/system anyway! Currently i suspect it's checking sparse bundles on my NAS Time machine which will be interesting as TM is also concurrently backing up Maverick for first time as well!
EDIT2: ....and ironically just as I wrote that it must have touched a locked file as AFP TM backup just aborted itself!
EDIT3: 4hrs later and we seem to have stalled for at least 40mins at about 3.5million files!:
http://f.cl.ly/items/221v323N1R3F3i0g3j00/Screen%20Shot%202013-10-27%20at%2011.18.36.png
Looks like gui has frozen. Have a scan log if required but doesn't reflect 3.5million files either!?

 

I've raised a Support request as suggested with a link to this thread. Let's see if the Mac team are as expedient and efficient as Joe's team were last year?......

EDIT: OK Fan started to annoy me now after 9 hours so I'm going to disable WSAC and see if I halt WSDaemon..... and it' just spawned another SCAN! :
http://f.cl.ly/items/2C1L3o0W3v2X3E3l2W1p/Screen%20Shot%202013-10-27%20at%2017.08.32.png

EDIT: Well WSDaemon is presumably for Backup & Synchronisation and isn't that well protected as it can be FORCED QUITTED. Which stops the CPU maxing but doesn't then restart! Presumably the only way to delete the whole of WSAC completely is to use SUDO batch commands in terminal after stopping processes?
I can confirm my sons MBP is also seeing similar max CPU on WSAC with poor response while scan is ongoing.

 

The sorry saga continues as predictably at first the system stabilised on reboot with another WSAC re-install but this time both WSDaemon and WRBackNsync were showing as unresponsive in Activity Monitor even though WSAC appeared functional with Passwords and Backup/Sync still linked. Scans completed without any elevated CPU and just when I thought we'd cracked it the system threw a kernel panic recursively.

Having attempted and failed a repair via 10.9 recovery partition I'm back on Mountain 10.8.5 attempting to salvage data from Maverick volume that had not finished backing up. Mountain has WSAC installed but with CPU maxing with WSDaemon!

When I attempted to update my support ticket to advise that a remote on Maverick volume was no longer currently possible then that had disappeared as well! What jolly fun!

There must be a "sudo" batch script via Terminal that will safely remove/re-install WSAC without shafting the kernel/file directory?

 

So is WSA causing problems on Mavericks? I'd really like to try it but I don't want to mess up my new installation of Mavericks.

 

Well for me it's causing a problem on both Mountain 10.8.5 and now even a fresh install on a Mavericks 10.9 volume (albeit on same MacbookPro 7,1).
Same symptoms are evident on my son's Maverick and his previous Mountain installs on his MBP!

Providing you have TM'd,Ghosted your pre WSA volume then worst case scenario is a kernel panic, which you can recover from with a re-image/recovery partition.

It would be useful (for Joe and/or Webroot development) and of course myself if you are able to try this on a testbed? Which of course is the reason I posted this on a Beta forum.

Symptoms I currently have is :
WSDaemon is maxing CPU and initial scan has stalled(according to WSA gui).

I have minimal image with only essentials installed over default install:

• 
  1Password v4.0.5
  Dropbox v2.4.4
  Orbicules Undercover v5.5.1
  TM is concurrently running backing up this fresh install (12GB) as I daren't reboot with WSDaemon currently maxing(non-responding).

Should you wish to accept this mission....... your Webroot(Mac) will self destruct in 30secs!

Good luck Jim!

 

https://www.dropbox.com/s/dz9t5lch4zvcvsi/Screenshot%202013-10-29%2011.09.55.png
"Danger! Danger! Will Robinson - Alien Webroot kernel extension encountered!"

Groan..... hours spent analysing this and please don't tell me Webroot have an incompatible kext for Mountain and Mavericks?

(Never would have happened if Joe was leading the WSA Mac Developers! )

Oh well - my own fault!: "Eventus stultorum magister"

EDIT: Raised my second support ticket just now....

EDIT: Support have promptly replied to confirm that Apple have changed Mavericks in final release and WSA will not correctly run until their package has been re-certified!
Now all I need is the WSA uninstaller (or "sudo batch script") to remove WSA before my MBP fan wears out! (or do I have to figure that out myself as well! )

 

I'll steer clear for now

 

Webroot support were again very prompt and helpful once I did manage to successfully raise a ticket (and I didn't even have to flounder around myself for a "sudo" script to manually remove WSAC! ).

Again the often repeated advice is to raise a support ticket if you're affected by these symptoms and can't fully de-install successfully.

Ironically just before I received Supports last reply I had already impatiently taken a leap of faith and rebooted my Mavericks test volume and fortunately was not presented with a kernel panic! Possibly the previous "sandboxed" install had too many symbolic links that aggravated my issue?
Curiously WSDaemon then subsequently appeared to load/run correctly (or at least without maxing the CPU) although the other WRBackNsync process still exhibited (not responding) errors so I've left this install in situ for the moment.

Now I just have to figure out why my Mountain 10.8.5 test platform hasn't also "healed up" and is still exhibiting the same symptoms?

 

Horseman,

Why would you want to run Weboot for Mac when is has a horrible detection rate?


http://securityspread.com/detection-rate-results/

The "here" button has the latest test.


As to the developers of Webroot, why when the Security Spread test posts MD5s of all the files Jay uses don't you detect 99% of them?


I was the one of the key guys pushing the results of this test to the Mac AV vendors to get them to step up to the plate. Some did. Intego to their credit was on that quest to be #1 the first day I contacted them. They were all over building new definitions and within a week or so they caught many more sample in this test.

Intego, Avast, and F-Secure have all stepped up to the plate and added new definitions. Other big names have done NOTHING IE = Sophos and Bitdefender to name a few. Lets add Webroot to that list too. How hard is it when you are given the MD5 #s and have access to all of them?

.

 

Could you please send me a PM with the details/a link to this test? We've recently made significant improvements to our Mac scan engine and should be scoring very well.

Thanks!

 

Sorry, was in a hurry to get out the door. I forgot the most important thing.

Large PDF

http://securityspread.com/detection-rate-results/

The "here" button has the latest test.

.

 

Thanks! I'll make sure our threat research team is aware of this and takes a look at the samples.

 

Thanks for that feedback/link! Although I found it somewhat ironically amusing to get:
https://www.dropbox.com/s/lg08d0uar72t8mz/Screenshot%202013-11-03%2004.28.11.png


As to answering your question which I suspect was mainly rhetorical:

1. I enjoy testing it (perversely attempting to break it? ). I thought that was self evident from posting on Beta forum?
2. It's not the only malware product I run concurrently.
3. There's more aspects to the product to test than just relying solely on independently reviewed detection rates.
4. Paul Stokes original "Prevx Home" release (to the public) in 2004 which was the basis for the continued development over the years culminating in current Webroot PC/Mac versions has always had a somewhat "chequered" development history? However I've always found the Support/Developers over the years extremely receptive and far more responsive to feedback than other company?
That level and quality of support I've not personally experienced since I used to test IBM's (White Plains) original (initially) internal IBM AV back in mid-80's after the Pakistani Brain virus was released in the wild!

 

Re: OSX Beta - Continuation - Beta/Release versions?

and in a FUTILE attempt to return to topic (ish):

I've just installed a fresh Mavericks on another MacBookPro(5,1) with a Beta(?) key code. My Release version is still 8.0.4.231 but the "Beta" is 236 so can anyone clarify what the current latest respective versions are please?

I note that while I'm not getting CPU maxing any longer on 231 the install of 236 did raise a warning regarding a non certified module so presumably that Mavericks related issue still has not been resolved yet?

If a newer release of either is due(or already available) then this will help me establish/test whether or not the auto-update feature is (or not) still failing potentially on 3 separate Macs before I raised another support ticket?

 

The latest official release version is now .236 (as of 11/2), although auto-updates may take 72 hours to be fully pushed out. If your live version doesn't update by 11/5, I think we'd have a reproducible case which the dev team would definitely like to look into closer if available.