• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by JeremyNicoll

  1. I shut the machine down a few minutes ago, then did a cold reboot. When EAM restarted it still showed the red systray icon etc but almost immediately did another update and this time the icon went green after that. I've PMed the location of debug logs for this too, to @GT500 .
  2. @GT500 - yes, I keep logging on all the time, so yes I would hope they explain why updates aren't being indicated. I still have a red systray icon, and the "Overview" pane is still orange. I note that the text on that still says the last update was 2 days ago - one might have expected it now to say 3 days.... The logs screenshot I made yesterday seems to show that updates are being logged properly and the detail view of such log entries (which I did check in several cases yesterday) looks as one would expect. For example, the most recent one says: General Information: Version 2020.1.0.9926 Connection: Direct Update started: 23/01/2020 09:03:17 Update ended: 23/01/2020 09:03:26 Time elapsed: 0:00:09 Update successful Detailed Information: 58 modules, 3218640 bytes a2hosts.dat (4545 bytes) - updated a2trust.dat (323 bytes) - updated a2wl.dat (382 bytes) - updated Signatures\20200122.sig (754 bytes) - updated Signatures\BD\e_spyw.cvd (261 bytes) - updated Signatures\BD\e_spyw.i00 (389 bytes) - updated Signatures\BD\e_spyw.i10 (333 bytes) - updated Signatures\BD\e_spyw.i12 (453 bytes) - updated Signatures\BD\e_spyw.ivd (377 bytes) - updated Signatures\BD\emalware.000 (24830 bytes) - updated Signatures\BD\emalware.412 (268 bytes) - updated Signatures\BD\emalware.420 (227 bytes) - updated Signatures\BD\emalware.421 (288 bytes) - updated Signatures\BD\emalware.422 (3313 bytes) - updated Signatures\BD\emalware.423 (5966 bytes) - updated Signatures\BD\emalware.424 (3550 bytes) - updated Signatures\BD\emalware.425 (298185 bytes) - updated Signatures\BD\emalware.426 (337252 bytes) - updated Signatures\BD\emalware.427 (38046 bytes) - updated Signatures\BD\emalware.428 (268986 bytes) - updated Signatures\BD\emalware.429 (303257 bytes) - updated Signatures\BD\emalware.597 (329 bytes) - updated Signatures\BD\emalware.598 (1203 bytes) - updated Signatures\BD\emalware.i02 (42515 bytes) - updated Signatures\BD\emalware.i05 (14212 bytes) - updated Signatures\BD\emalware.i06 (24019 bytes) - updated Signatures\BD\emalware.i09 (8673 bytes) - updated Signatures\BD\emalware.i10 (314 bytes) - updated Signatures\BD\emalware.i11 (19100 bytes) - updated Signatures\BD\emalware.i14 (276 bytes) - updated Signatures\BD\emalware.i16 (369509 bytes) - updated Signatures\BD\emalware.i19 (20163 bytes) - updated Signatures\BD\emalware.i22 (5978 bytes) - updated Signatures\BD\emalware.i23 (424594 bytes) - updated Signatures\BD\emalware.i24 (40643 bytes) - updated Signatures\BD\emalware.i25 (3429 bytes) - updated Signatures\BD\emalware.i27 (6569 bytes) - updated Signatures\BD\emalware.i31 (19698 bytes) - updated Signatures\BD\emalware.i32 (2020 bytes) - updated Signatures\BD\emalware.i38 (116682 bytes) - updated Signatures\BD\emalware.i42 (1449 bytes) - updated Signatures\BD\emalware.i44 (236 bytes) - updated Signatures\BD\emalware.i49 (3511 bytes) - updated Signatures\BD\emalware.i51 (30244 bytes) - updated Signatures\BD\emalware.i54 (5096 bytes) - updated Signatures\BD\emalware.i56 (125113 bytes) - updated Signatures\BD\emalware.i58 (6189 bytes) - updated Signatures\BD\emalware.i62 (105896 bytes) - updated Signatures\BD\emalware.i67 (136614 bytes) - updated Signatures\BD\emalware.i69 (45942 bytes) - updated Signatures\BD\emalware.i70 (6304 bytes) - updated Signatures\BD\emalware.i71 (14597 bytes) - updated Signatures\BD\emalware.i73 (284003 bytes) - updated Signatures\BD\emalware.i75 (16217 bytes) - updated Signatures\BD\emalware.i80 (24544 bytes) - updated Signatures\BD\emalware.i99 (265 bytes) - updated Signatures\BD\java.cvd (389 bytes) - updated Signatures\BD\update.txt (120 bytes) - updated
  3. I've PMed @GT500 with the location of debug logs, from the time of the system restarts a few days ago, through to a few minutes ago.
  4. The last restarts were on Mon morning (two and a bit days ago) when I applied some Windows updates.
  5. Win 8.1, EAM 2020.1.0.9926 I just noticed my EAM systray icon has turned red. Looking at the overview screen I see that apparently the system hasn't updated for two days - see screenshot: 1250 partial protection.jpg?dl=0 I'm pretty sure I've seen regular notification panes saying updates are happening. And the forensic log seems to say so too: 1251 but log looks ok.jpg?dl=0
  6. > I was looking in db file (SQL log), not the text files, which were written elsewhere. The db file is just the "forensic log". The logs created when you turn DEBUG on are placed in: C:\ProgramData\Emsisoft\Logs and - if you leave DEBUG on for long - can become very large.
  7. > "I even turned DEBUG ON, but there is nothing interesting being logged" Did you disable debug logging afterwards so that the in-use sets of debug logs were closed (and new ones opened)? Also... unless you know what Emsisoft's code does, the meaning of return codes etc from their functions, I don't understand how you think you can tell what the flow of logic described in the debug logs actually means.
  8. @GT500 OK; you say "When EAM's File Guard is configured for Thorough scan level, it scans every newly written file, If a file being extracted from the archive is detected as malicious, the File Guard responds to that just like it would for any other file." The point I'm trying to make is that EAM clearly knows it's scanning the file because it's been newly-written. That being so, the alert pane should look different from how it does when a file is being read for use or execution. In particular the two Allow options /should/ be clear on the huge difference in effect between 'Allow once' and 'Allow always'. Also, EAM knew in this instance that 7zip was the program that created the file. That info is invisible when you first see the alert pane; one needs to scroll the info. Obviously in this instance I knew what program had created the iffy file, but in the general case - when an arbitrary program creates a file that EAM thinks is bad - it would be much better for less-aware users if the alert pane said right at the start that program xyz.exe has just created file bad.doc ... and ideally also offered the option to terminate xyz.exe (or even just advised that a user might want to do that themselves, eg via task manager). The whole point of using EAM is to prtect users against themselves. This experience does not show EAM doing the best job it could do. Regarding single left click, and right-click on a file entry shown in WIndows Explorer, you said ""EAM was monitoring file system access, and detected the files were accessed". But I don't see why WE would need to open a file or get a handle on it etc just so that in WE a line showing a filename can be selected/editable. In the general case for right-click, I expect that either the file's full path, or a file system object gets passed to the chain of context menu handlers. I'm not sure that I'd expect any of those handlers actually to /access/ the file until a user actually selects a specific one off the menu. When one issues a "dir" command in a command window one wouldn't expect to have EAM scan the files contained in the folder, so why would trying to do a WE->Properties do that? At least for the basic Properties that WE itself displays? Clearly there's an extension mechanism there too (eg that digs ID3 tags out of .mp3 files) which DOES need a file to be accessed, but I'd have thought the bulk of the info presented comes from file metadata.
  9. I didn't say that the alerts were "for" 7zip rather than the malware files. The alerts /were/ for the malware files. BUT, it was 7zip that I was running. The problems here are probably more an issue for @GT500 than you, though. I've repeated this. Downloading the .rar file with the samples in it causes no alerts. As soon as I asked 7zip to unpack the archive and provided the password, I got the first alert. (None of these alerts happen if FileGuard is set to its Default scan level - but I normally have "Thorough" set.) Two screenshots, of the alert's first pane and what you see if you scroll that down a bit: Elise malware alert 01.jpg?dl=0 and Elise malware alert 02.jpg?dl=0 This alert follows creation of the file: 0eb7ba6457367f8f5f917f37ebbf1e7ccf0e971557dbe5d7547e49d129ac0e98.doc Opening a Windows Explorer view of the extract-to folder shows that the file has already been created. When reading the meaning of the "Allow" options, which talk about "letting an action continue", that's misleading. Most alerts happen before a program is executed or a dodgy file is processed, when "continue" means let it run/be used. The descriptions of what "Allow once" and "Allow always" could be worded better for this situation. I think most users would regard "Allow once" and "Allow always" as differing only in the number of times that something is allowed. But in this case Allow once - lets the just-created file stay where it is Allow always - lets the just-created file stay where it is AND in future allow it to be used/run Creation of the file (by 7zip) is not in itself dangerous. But future use/execution is extremely dangerous. The distinction in meaning/effect of these two Allow options is nothing like clear enough. I do understand that there's a difference between EAM intercepting an attempted execution of something.exe, where the .exe itself is the danger, and eg a system utility (like part of the scripting framework eg wscript.exe) or a well-known interpreter (eg python.exe) or utility (eg i_view32.exe) reading a file and interpreting its contents. I /hope/ that EAM intercepts attempted execution of a .exe during "program load", or maybe while the .exe is being read prior to load. But in this case, although EAM did know that the parent process was 7zip (though it doesn't really matter what the parent was - the problem here affects any program that may create files), does EAM know that the alert is for a just-created file, something that is not being read prior to use/execution? As a matter of practicality, a user encountering a series of alerts as some unpacker or whatever creates a series of dodgy files could usefully be offered an option to terminate the program that is creating the files. If I hadn't been deliberately running 7zip to unpack these samples, I would rapidly have found it annoying to get alert after alert for every single file it created. As it was, even if I had clicked on "Allow once" (the safe choice of Allows here) I might have clicked on "Allow always" hoping that that would allow this instance of /7zip/ to keep creating files without generating alerts for each one. Again, clarity in the alert box about precisely what is being allowed would help. There's another problem. After (in my test recreation of this) I'd allowed the .doc file "once", EAM produced an alert for the next file (a .vbs one). At that point I looked at EAM's forensic log - see: Elise malware alert 04.jpg?dl=0 See the two log entries timestamped 23:21:33. The .doc file detection happened quite a lot earlier than the .vbs one, but they are listed in the opposite order. That's confusing. And another problem... Last night when recreating this I single-clicked one of the .vbs files' names, to highlight it so I could c&p its full name. Today, I right-clicked one prior to looking at its Properties pane. In both cases EAM generated an alert saying the file concerned was trying to execute. Last night that gave me a hell of a fright. I'm very very careful and had not thought I'd double-clicked the filename. Today I was absolutely certain it was a right-click. When it happened this morning I realised I'd probably been ok last night - the alert is badly worded. Can EAM not tell the difference between standard parts of Windows Explorer's context menu handling (selecting a file's name, or displaying its properties?) and an arbitrary context menu handler offering to do something with the file? [Last night, after the "trying to execute" alert, I clicked on Quarantine on that alert. EAM then told me it couldn't delete the "infection" and I needed to restart. I presume the problem would be that either another part of EAM had a handle open on the file, or maybe 7zip still did? During the reboot a boot-time file deletion was performed, and I did a second full shutdown immediately after that, then a cold reboot. I've also done a full-scan of the machine since then, and there's no sign of any malware.]
  10. Which exclusions list did you add the program & folder to? The exclude-from-scanning one (no use), or the exclude-from-monitoring list (should work)? Also, has it recently worked alright? If it has (in which case it suggests a recently-released version of EAM is the problem), you might be able to tell EAM to use the 'Delayed Feed' (ie an older version of the program) rather than the more-uptodate one. You could try that by going to EAM's Settings - Updates - Update feed and choosing "Delayed", then choose "Update now" from the systray icon menu. If you do do this, as soon as you again reset the feed to "Stable" the newest version of EAM will again be installed. Sooner or later Emsisoft will ditch whatever older version is on the "Delayed feed" and a newer version will replace it, so - if this change does sort your problem - it won't fix it for ever.
  11. @Elise - out of curiosity I downloaded the samples, unpacked the archive, and opened some of the files (the VBE, VBS and PowerShell ones) in a text editor. After looking at each of those, I right-clicked each one and selected 'Delete' - and EAM intercepted the placement of the file in the Recycle Bin (under the system-generated Recycle-Bin filename). But a right-click context scan of the unpacked archive didn't class those same .vbe/.vbs files as malware. I was surprised. Looking back through the log I think I found the reason. When I unpacked the archive, FileGuard told me about each malicious file, preventing the unpack from proceeding. I think I chose 'Allow always'. That seems to have added each of the unpacked files' full paths to my list of Exclusions. I suppose that explains why the files were not detected by a later scan of the unpacked folder... But... when I clicked 'Allow always', during the unpack, I thought I was allowing the unpack process to continue - specifically I was allowing that instance of 7z.exe to create files. I do not think that Allowing 7z to do something should translate into allowing the files it created to be excluded from future scans.
  12. I don't know what "profile" means in what you describe - "an optional group of settings" perhaps? Google tells me that a feature of some/all Deco models is that it has built-in antivirus and scans all of your network's incoming and outgoing traffic.
  13. Personally, I agree with you. But it's not clear whether Emsi will fix this or continue to say it's "working as designed". See discussion in this topic in the Beta forum, at:
  14. Does EAM's memory use climb during the import and then decrease again (eg if it's building a new table while the old one is still there, then removing the old one)? How much real+virtual memory do @GT500 and @G11 have?
  15. > We keep this info visible until user checked the scan results. The blue dot was visible (along with the 100% thing) here, all through yesterday - and maybe today too (until the Beta just updated - now it's gone), but I checked the most recent Custom scan's report, as soon as the scan completed. (Later: I suppose this was a series of blue dots after a series of context scans. But it adds nothing to my knowledge.) There's no way, in English, that you can reasonably claim that "New scan" is synonymous with "Close". "Close" means ending something whereas "New scan" implies starting something. Edited: I just tried a context scan of a few files. At the end of that, not having been told of any problems, the scan screen is displayed, saying "No suspicious files were detected during the scan." What else am I supposed to do to get rid of the blue dot? I have (a) not been told of problems /during/ the scan, and (b) been told there were no problems /at the end/ of the scan. Even if I choose to "view the report" - for which there is no reason because guess what? - it lists no problems - the blue dot is STILL being shown.
  16. With Win 8.1, and build 9915, I see exactly what Marko describes. I do have separate 'Scan started' and 'Scan finished' log entries (eg for a custom scan earlier today of 1.4 million objects). Context-menu scanning a smaller number of files - first a folder containing 100 or so, then just a handful of files selected from a folder view, and finally just a single file ... all each produce a pair of log entries.
  17. @Peter Nowell There's no protocol to violate, and you did not do any harm. I was just curious (as I thought my answer had been sufficient, and was provided only 14 minutes after you asked.) Seasonal greetings to you too.
  18. @Peter Nowell Wy did you ask the question twice? And - if you didn't understand my earlier reply, why didn't you ask for clarification of what I said?
  19. How big is the file you are importing? Does an import of a tiny file work?
  20. Doesn't the decision to delete the key depend on whether or not @Daniel Pipe has the software concerned installed (intentionally) or not?
  21. If you mean "Auto-Silent mode" is being enabled/disabled, it's normal. Silent mode is turned on when you have a program enter full-screen (ie not in a window) - which is most likely to be if you're running a game, or watching a video. The point of Silent-mode is that in a game or video you are unlikely to want to have your game/video disturbed by notifications from EAM. You asked this question in the wrong part of the forum. This part is for general discussions of Malware & Computer Security. Questions about using EAM should really be in the "Customer Support" - "Emsisoft Anti-Malware Home" sub-forum.
  22. Mobile phones ARE computers, computers one of whose programs pretends to be a (real) phone. Various companies (including Emsisoft) produce anti-malware/anti-virus programs for mobiles. You can read a summary of what these various programs can protect you from. Obviously iOS (Apple) and Android differ, and - as with PCs - there's several versions of each one's OS in use, and of course with Android some manufacturers supply variants on Android (ie not every Android phone is running the same OS). That means that odd combinations of phone model, version of Android etc may mean there's exploitable loopholes in subsets of phones, even if most are ok. In theory Apple's phones are more secure, partly because there's only their version of iOS in use, and partly because Apple try to make sure that only reputable apps are available. You might find it useful to read:
  24. OK, thank-you for the information. I'm trying to sort out in my head what the possibilities are. First, can you tell me what precisely you mean by "streams the file to EAM"? My first thought was you meant some sort of "please test the data that's stored 'here' in memory" request (occurring before the file is saved), but since the (Eicar test files) are actually being written to disk I now think you mean simply that the browser saves the file then asks (via integration) for that file to be examined. Is the "stream" terminology aspect significant? Fileguard-wise, you're saying that the action the browser has already taken, to save the file, means that (in my case with Fileguard being "thorough") EAM is separately being asked to look at the just-saved file via FileGuard? In the tests I've done here, my impression is that the FileGuard-triggered test, because it was caused by the save of the file, is being processed by EAM before the browser-integration examination starts. Is that always true, or are these examination requests handled asynchronously? Would eg slow file-systems & a huge file ever mean the browser-integration check happens before the Fileguard/save one?
  25. Not a real-life test? We weren't just trying to avoid ransomware, but also what we'd do if fire or whatever wiped out the building. Do you think we should have burned down our primary data-centre first? What more could we do to make it more real? We did these tests to prove that we could: reconfigure the base hardware as needed, IPL a specially-built minimal OS, use it to restore initial ancillary system disk images (onto new disk drives - maybe in trucks in the car-park?) needed for a larger system, and as more and more of a restored system grew, the processes rolled outwards to the teams responsible for application data & backups, database support & eventually programming teams in each business area. Likewise the operational depts needed to restore a schedule and start to run production work. Outside IT, the business as a whole had to have a realistic appreciation of what the delays would be before each part of the business's critical services could be restored. Back-of-an-envelope guesswork wasn't acceptable. They had to know, and for that we had to test and prove how long each stage would take. In occasional tests (when eg there'd been significant service applied to the OS, or a new version of a critical piece of software) and in any case at least twice a year, the initial part of this test was done - which 'only' required exclusive use of one machine room overnight. (That still required migration of normal workload and data away from that room beforehand, and migration back afterwards - itself a process that took a few days to achieve). Migration of whole machine-rooms-worth of data used the exact same processes as data backup & recovery normally did, so we knew that worked. Large parts of the overall process - eg swapping workloads between particular machine rooms - were done anyway every so often so that we didn't always run production from the same hall and dev/test elsewhere. It was also done once per year per machine room so that rooms could be isolated for power-system safety tests (and note also that we occasionally ran the whole building on generators for a few days just to prove that that capability still worked properly.) Hall swaps proved there'd been no oversight and that we no longer had necessary duplication, and the proceses before, during and after each test meant that there were lots of staff in each area who understood their area's role in the whole scheme. Each machine hall had enough kit in it to run the whole business (that is, non-business-critical workload like giving the programmers a machine to develop & test code would be sacrificed in the short-term in a disaster). Big, all-weekend tests involved many staff. We still needed the ops, on-call etc staff to support the live systems throughout that period. You might want to ponder what sort of costs a company incurs when they set out to have not just one machine hall/building to run their business from, but more than twice that. (More because although we 'only' had duplicates of all the business-critical stuff, we also had tertiary copies of some things, eg a third robot tape silo in a vault under another building - that was planned before that building was built.) We also - despite being high-profile business rivals with another local company - had more of our kit in one of their machine rooms and they had some of theirs in a fenced-off section of our biggest one. When tech developed to the point where it was possible to sync disk I/O across sites miles apart, we sometimes ran our production service out of their machine room. Nothing about this was cheap. It was designed, built and regularly tested by people who were not idiots. Your "not real life" comment reminds me of the common view that Y2K was a damp squib because nothing went wrong. For us, Y2K planning took a bit under two years. It was the single biggest project worked on in that period. By the time the actual date change rolled around, we'd run simulations of "the moment" many times and we had test systems running test versions of our whole workload for weeks at a time, pretending to be at other significant date points - eg end of business year sometime in 2000, end of tax year, end of the following year's significant dates (as they'd be running year-end processes that harked back across the date change). We were as sure as we could be that everything would be ok. Even so, many staff (mostly the senior, on-call, most experienced ones - I suppose the same sort of mix of people as for the major disaster recovery tests - maybe a hundred of us in all ?) were at work when the moment happened, just in case. I am certain that companies similar to us adopted similar approaches.