JeremyNicoll

Member
  • Content Count

    1818
  • Joined

  • Last visited

  • Days Won

    28

Posts posted by JeremyNicoll


  1. Win 8.1 64 bit

    The application restart process didn't work properly - or at least, not as I expected.  I got the pane saying an application restart was needed, with a counting-down button and a do it at restart button, and clicked the counting-down one.  It sort of froze for a few seconds (whereupon I expected the GUI to vanish from the screen) then came back (with the countdown about 5 seconds further on) and continued counting down to zero.  Then the restart was done.


  2. 1 hour ago, digmor crusher said:

    I prefer to use 2 solutions as no programs are 100% effective 100% of the time. I always recommend using one of these as secondary protection: 

    Voodoo Shield ( free and paid versions)

    Hard Configurator (free)

    Osarmour ( free now, soon to be a pay program)

    Syshardener ( free for now)

    Configure Defender if your using W10.

     

    That seems a bit at odds with your earlier reply; is the difference that these latter programs take a different approach from whatever it is that Checkpoint's software does?


  3. I'm using Win 8.1, but - if I had Win 10 - would be quite tempted to experiment with its "Controlled Folder Access"... except that I think that needs Windows Defender's real-time protection enabled and I suppose it either definitely can't, or maybe can't coexist with EAM.

    Likewise "novirusthanks" have a product called "file-system-protector" which I'd like to play with... but for all I know it may have a similar limitation. 


  4. In the short term, the customer could change Settings - Notifications - Notifications Location  to "Right center" or "Right top".    

    I use "Right center" as the location (which the help file says is the default one).  It looks as if the code that displays the notification doesn't properly take into account the pane's necessary depth (for both the ".... following program" and filepath parts of the message (though surely the latter could wrap onto several lines), and is possibly positioning the top of the notification pane at a fixed location rather than (bottom of screen) - (depth of taskbar) - (depth of pane).

    Or maybe it assumes the taskbar will auto-hide, but auto-hide isn't happening?   Here (on Win 8.1) it won't hide if some other program wants my attention and that program is only represented by a miniature taskbar icon - and it's a constant annoyance because one has to deal with all the possible culprits to get the hide to happen.


  5. > No, not the serial numbers. I found the SHA number and ran it through VT and all I get is No Engines Detected This File. 

    OK.  (I replied to your "There are no hash's on them....)

    Asking VT about SHA numbers is fine.

    "No Engines Detected This File" means none of the multiple antivirus programs that VT use think there is a problem with any file which has that hash.  It doesn't mean VT "couldn't find the file". 

     

    I hardly ever run Chrome here, but just ran it.  It updated (the usual way, from the About Chrome pane) to something just a little more recent than your version, ie: 84.0.4147.105


  6. > I'm a she.

    The paragraph I'd just written had "she" and "herself" in it.   Before you explicitly said you're female I thought you might be, from the "gal" ending in your name, but I thought I'd taken care not to write anything that made any explicit assumption.  Apart from that I referred to you as "the OP" (ie original poster) because it's quicker to type that than plug your (anyone's) 'name' in; I regard "them", "their" etc as non-specific. 

     

    > hashes

    At the very start of this thread you showed us a BB log message which contained a hash.  Since then, are all your notifications coming from File Guard?  That is, not the BB?  Do these log messages not also contain a hash?  I just tried to download an iffy file and the log message was

    27/07/2020 20:57:25  File Guard detected Malware ...... details ... (SHA1: 3395856CE81F2B7382DEE72602F798B642F14140)

    and the part at the end, starting "SHA1:", is a hash.

     

    The "serial numbers" on these files: do you mean the 5 letters and digits after the "CR_"?     If so they're completely random, and the five of them can produce more than a million different file names.   The advantage of asking VT questions about files via hash values is that hashes depend on a file's contents, not its name.


  7. 16 hours ago, GT500 said:

    I already know what the file in the log entry he posted is. It's a legit Google Chrome installer, digitally signed by Google.

    That was true of the first file described at the start of the thread.  I checked its hash on VirusTotal (as you'd have seen at post 2).  I would have said we couldn't be quite so sure about all the other files as the OP neither shared their hashes nor confirmed whether she'd checked them herself at VT.   There IS still a mystery: what precisely is triggering these updates, bearing in mind that the OP thinks Chrome is already uptodate, and also why is it being offered over and over again.  

    Edit: offered over and over again - I suppose that's obvious - it's because whatever is in the update, it's never been installed.


  8. > @GT500 said: BTW: @JeremyNicoll this topic seems to be getting a bit confusing. Do you mind if I handle it?

    Of course not. 

    I was wondering though, if Wallacegal is quarantining every instance of this installer, if there's some way to submit those files to Emsisoft so someone can (unpack them? and) find out what they actually contain?   And, are they all apparently signed by Google?


  9. > The only automatic things I have turned on is the updating for Emsisoft and to automatically quarantine programs with a bad reputation which wouldn't trigger that message.

    Correct, it won't cause the message.  But the automatic quarantine is why you earlier only got a few seconds to read the alert and had the decision made for you.

    A while back it was possible for users to look at the info stored on the AMN (ie where EAM goes to check file reputations) but that's not been possible for ages.  It's a pity because we have no idea why the earlier file (and maybe this one) are thought bad even though VT thought it was fine.

     

    You said: "All of the browsers I have are set to a manual trigger in Services."?     Why would a browser be defined in Services?     Do you mean their updaters?

    I wish I understood what is fetching these update files.

    Are you running a "Home" version of Windows, or a Pro/Enterprise one?   The latter can, I think, have Policies set that dictate if/how/when updates are looked for.  (I read some webpages about that earlier.) Maybe Pro/Enterprise versions ignore normal user settings?  (They'd have to, to prevent normal users turning off things that Pro/Enterprise system administrators wanted done their way.)

     

    Last time around you showed us a log message that started "Behavior Blocker detected suspicious behavior..." which would only happen when the iffy program was actually run.   But this time your log line doesn't mention the Behaviour Blocker ... which would suggest that File Guard regards the file itself as a problem.   Or were there earlier BB messages for this one too? 

     

    Did this most recent file's hash also appear to be a genuine Google Chrome file when checked at VirusTotal?

    I just had the VT website repeat its scan of the earlier file - which means that signature changes that have occurred since last time might have altered the result.  But all 69 programs still think the earlier file is innocent.

     

    Someone had a similar problem (with Brave) a while back: https://support.emsisoft.com/topic/31523-brave-browser-installation-problem/   but they knew they were trying to install Brave, or an update to it... and the file concerned was identified as Brave (on the VT website).

     


  10. > I've tried everything from zero to 999 and I still get about 3 seconds so that option doesn't work for me.

    Well, that strongly suggests that you have the "Lookup" and "Automatically..." options turned on.   The BB displays the initial alert, then does a Lookup, then gets a result and automatically does the preset action and at the same time takes away the alert pane because it no longer needs it because it knows what to do.   If you don't want that to happen you need to turn off the "Automatically..." options.
     

    > In the folder for that .tmp file was an executable.

    That in itself is not all that unusual (though it may be, for Chrome).  Updaters quite often work in a two-stage process; the first unpacks whatever was downloaded (into a randomly-named folder in %TEMP%) then the thing itself is executed.

    I googled for: Temp\CR_xxxxx.tmp     - that being a sort-of generic version of the temporary filename your weird file was given - and there's a handful of posts with people discussing google chrome updates using these sorts of filenames.  It's odd though because it IS only a few posts, and some of those are pretty old.  But see eg: https://www.reddit.com/r/chrome/comments/al8zui/chrome_installing_from_cwindowstemp/

    One of the posts describes folders of these names being created by "silent installs" (which are usually run by network administrators to install things on their users' computers without the users knowing it's happening or having to do anything) of the Vivaldi browser (which presumably uses the innards of the Chrome browser and therefore maybe fetches and runs some Chrome updates).   Do you have the Vivaldi browser?   This post was at: https://forum.vivaldi.net/topic/7463/install-property-s-for-windows-installations-sccm/2   Even if you don't use Vivaldi, how about any other Chrome-based browser?

     


  11. > You know, I barely get 3 seconds to read whatever's in that box.

    I didn't know that.    If you look at Settings - Notifications ... and then the top value (for "Real-time detections") how long is it set to?    Here, I have the times for all detections set to 999 seconds (which is between 16 and 17 minutes) so - assuming I'm not away from the pc for ages - I will see and have time to react to at least some detections.   There are parts of the Behaviour Blocker's processing where an early detection notification might be replaced by one describing an automatic decision though, depending on what else you've configured EAM to do.

    In Settings - Advanced, about half-way down the list of options there's one "Look up reputation of programs" - which dictates whether EAM will attempt to find out whether other users think a specific program is good or bad, and two options under that ("Automatically allow..." and "Automatically quarantine...") that allow you to determine if the result of such a lookup should tell EAM just to go ahead and do something.  You probably need to have a think about how you have these things set.  Having an antimalware program make its own decisions, faster than you can decide if they are the right ones, is your choice.   Here, I do allow lookup, and I'm happy - if that process thinks a program is ok - to allow it.  But I do not let something get automatically quarantined.

     

    > The ideal thing would be that when that box with the message opens, that it doesn't go away until it's acknowledged one way or the other

    Well, I agree with that.   But maybe the behaviour you saw isn't how it's meant to happen.  And then again, maybe you've explicitly configured EAM not to do that.  It would help to know the notification time setting and the choices you've made in the Advanced section.

     

    > but I suggested that long ago and was ignored.

    I am not the person to complain to, though.  I'm just another user.

     

    > As to updates to Chrome and the few extensions that I use, I regularly update things, but was not working on anything that would trigger an update. I'm using the Chrome
    > stable browser right now rather than Canary, so the only thing I should have gotten for Chrome would be the green update arrow in the upper right corner. That's why I don't
    > have a clue what triggered this.

    Nor me, but as far as I understand it, Chrome updates itself on its own schedule.   This:
    https://www.computerworld.com/article/3211427/whats-in-the-latest-chrome-update.html
    from a week ago, albeit slightly ambiguously, suggests that Chrome "updates itself in the background".   I'm not totally sure if that means that updates are fetched AND installed without user intervention, or whether it's just the fetch... but it doesn't sound as if it waits for you to do something.   Me? - I hardly ever use Chrome, and when I do the very first thing I do is visit "Help - About Chrome" to trigger an update if one is pending.. so I don't know what regular users see.


  12. Presumably "Marking as safe" adds a user-defined rule to the Behaviour Blocker... so you could delete the rule: find it in the BB list of processes (where if it's not running at the time it will be marked as "Stopped"), right-click it and choose "Delete rule".    Next time it's detected make a different choice?   But perhaps first look at the thing.  You don't want to disable genuine updates to Chrome.  I'd have expected a genuine one to be digitally signed, though, and maybe therefore not produce an alert.

     

    I plugged your SHA1 hash into the "search" box at VirusTotal.  That shows:
    https://www.virustotal.com/gui/file/bdfffe10be52adb2a0f9ac36652811fa86279e43dd5e5580f049ef7dfbda66a2/detection 
    that many antimalware apps (in fact, every one of those VT currently uses) think the file is safe; moreover they say it IS digitally signed, and it categorically IS a Google-supplied Chrome installer - see the "Details" tab from that initial results page.   That means the BB alert is probably a mistake, with the BB mistakenly categorising something inside the installer as malware.

     

    > ... I'm using Chrome, but I'd not clicked on anything that should have started a download.

    There are "google update" services that may or may not be running on your system that can perform automatic updates.   Even venturing into "Help" or "About Chrome" clearly runs some logic to see if an update is pending; I'm not sure if, if one is, it is automatically fetched.  I wouldn't be surprised if it is.   There's also plugins/extensions; I review those occasionally at the special "internal url" / settings page:   chrome://components   and have noticed that if I force Chrome to update specific extra parts from one of my userids, the other userid seems to benefit - suggesting that Chrome is installed "per system" rather than "per user".  

     


  13. > problem is...

    Do they?   I'm pretty sure we'd have noticed.

    There are some settings that I used to change by accident - eg on some of the notifications I'd accidentally click on "don't show this again" rather than the "X" to dismiss the pane.  Now, I check around once per week that all the notification settings are as I want them to be.


  14. EAM's debug logging (which is completely different from the Forensic log) creates a lot of extra log data.  It's a continual trace of what EAM is doing internally.  It has to be on before the problem happens so that those logs show the logic of what EAM was doing when it hit the problem, and what it did next.   Some people (me, for example) almost always have debug logging on... but I stop and start it every three or four days and throw away the accumulated log files.  However whenever I have a problem I already have the logs to send to Emsisoft. 

    Debug logging will slow your machine down though, especially if your disks are spinning rust; it's not so bad with SSDs.  And, if you turn the logs on and forget about it, they could fill up your disk.

    FRST's logs are quite different.  They're a snapshot of the machine state (critical registry keys, DLLs, eventlog records etc) at the time that FRST is run.

    • Like 1
    • Thanks 1

  15. What you're actually complaining about is a consequence of using default settings - that /if/ EAM thinks a file is dodgy it immediately quarantines it.  That's sensible for users who want to minimise risk.  But it has drawbacks, which is that applications that depend on those files will crash.  (Another typical problem is if an email in a mail-client's files is suddenly deemed infected, the whole file can be removed, rather than just the infected section... which can cause email clients to crash, or try to refetch every single mail, or whatever.)

    I was not suggesting that you turn off any of the scans, but instead change what they will do when they find a dubious file.   For example with PUPs (which are always subjective anyway because one person's PUP is another person's vital programming utility) you have a four-way choice about what EAM should do when one of those is detected.

    Whether you've used Open-Shell on other PCs or for years is irrelevant.  Any anti-malware application can at any time decide, correctly or not, that a file is dubious.  The probem for you as a user is how you balance safety (having possibly dubious files quarantined immediately) versus the problems that that action will cause you.

    Default settings do not suit everybody.   The point is you need to make an informed, responsible choice about which EAM settings suit you best.