Webroot SecureAnywhere v8 modifies your files for no reason

Discussion in 'other anti-virus software' started by qakbot, Sep 23, 2012.

Thread Status:
Not open for further replies.
  1. qakbot

    qakbot Registered Member

    Joined:
    Aug 25, 2010
    Posts:
    380
    I don't know what to make of this one.

    This is an XP Sp2 system with SecureAnywhere v8.0.1.233.

    My application modifies certain data files that it owns.

    You will see in the before attachment that there is a WriteFile operation at offset 31 of length 42 on my file test.txt. See below the procmon output.

    Before.PNG

    After installing Webroot, I noticed that Webroot is performing an extra 4K page write to my file. See below:

    After.PNG

    Note that even though procmon shows that the writefile is originating from my test.exe app, I know that Webroot is actually responsible for it by looking at the stack below, where the Webroot Wkrn.sys drive is writing to the file.

    stack.PNG

    Why is Webroot messing around with my file.

    Eventually this also leads to corruption of my file, described here https://www.wilderssecurity.com/showthread.php?t=332777
     
  2. PrevxHelp

    PrevxHelp Former Prevx Moderator

    Joined:
    Sep 14, 2008
    Posts:
    8,242
    Location:
    USA/UK
    You aren't correctly interpreting the Process Monitor logs. WSA is just a filter driver in the stack - nothing to see here.
     
  3. qakbot

    qakbot Registered Member

    Joined:
    Aug 25, 2010
    Posts:
    380
    Haha.. "just a filter-driver on the stack". You do realize that this comment adds little to prove or disprove whether Webroot is issuing its own I/O.

    There is a host of "Flt" calls as you know that a filter-driver can use to FltRead, FltSetInformationFile etc, FltWrite etc., and most/all of these are called from a FilterManager call out. For some reason I am unable to load symbols for that OS, else I would know for sure exactly what Webroot is doing.

    It maybe not the Webroot driver, but somethign in Webroot is causing an extra 4K write on the file.

    I have clearly showed you the procmon traces with and without Webroot and you can clearly see an extra 4K write to that same file when Webroot is on the system, which btw, Webroot has no business writing to.

    Looking forward to an explanation from the Webroot guys.
     
  4. Trooper

    Trooper Registered Member

    Joined:
    Jan 26, 2005
    Posts:
    2,825
    The above poster is a Webroot guy. :rolleyes:
     
  5. Mongol

    Mongol Registered Member

    Joined:
    Jul 24, 2004
    Posts:
    1,581
    Location:
    Houston, TX
    He is in fact THE Webroot guy. Webroot / Prevx has a section right here at Wilders so why do you post this here gakbot?
     
  6. qakbot

    qakbot Registered Member

    Joined:
    Aug 25, 2010
    Posts:
    380
    If he is THE Webroot guy, he should be able to answer my question about the extra 4K write on that file.

    Btw.. if the driver was JUST filtering calls, you wouldn't see a call back into the filter manager from Wkrn on frame 13 :) Time to get my symbols loaded and get some answers.
     
  7. Mongol

    Mongol Registered Member

    Joined:
    Jul 24, 2004
    Posts:
    1,581
    Location:
    Houston, TX
    If he is the Webroot Guy? what about his name and title do you not understand? And why are you writing about him in the third person when you could address your query to him here or at the Prevx Forum right here at Wilders...:cautious: :blink:
     
  8. PrevxHelp

    PrevxHelp Former Prevx Moderator

    Joined:
    Sep 14, 2008
    Posts:
    8,242
    Location:
    USA/UK
    If WRKrn.sys was at the top of the stack then yes, it would be writing to the file. However, it isn't. Test1.exe is.

    If you're thinking WRKrn.sys is writing to your file, then you should be more worried about promon11.sys, fltmgr.sys, ntfs.sys, and ntkrlnpa.exe :)

    I imagine the easiest test here would be to just look at the file and see that it isn't 4K larger.
     
Loading...
Thread Status:
Not open for further replies.