JeremyNicoll

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: https://www.av-comparatives.org/tests/mobile-security-review-2019/

https://www.bleepingcomputer.com/news/security/new-linux-vulnerability-lets-attackers-hijack-vpn-connections/

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?

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.

I used to work for a large enterprise. We did test recovery (of the whole system, from a bare machine upwards) in a machine hall that - for the duration of the test - had no production workload in it. These tests usually ran from late Friday thru late-Sunday and started with the assumption that emergency services wouldn't allow any of the professional IT people into the machine room. So instructions were written for, and tested by, non-IT people - so that eg a fireman might be able to do the initial actions which actually had to be done physically rather than electronically/remotely. It was, of course, expensive to plan, build and test these recovery systems. We also hosted disaster recovery tests at our site for subsidiary companies in the group.

Frank, no-one else (unless they are also Emsisoft employees) is going to be able to explain it if you can't. We don't have access to the code. YOU say that these funny files are perhaps because a browser deleted a file. WHY would it do that if EAM is still in the process of deciding whether the file is ok and if not, what to do with it? You said above "If you set File Guard to another scan level than Default, such issues are expected, when 3rd party apps take care for deletion of detections," ... which I would accept IF the third-party app was not using this much-vaunted integration that Emsisoft says means the browser asks EAM to scan the file. While EAM is doing whatever it does why on earth would the browser, having asked EAM to do that, delete the file? Why would it know it should, before EAM tells it the file is unsafe? Separately from that, whatever the files are, WHY does the EAM GUI not show that they are there? It was EAM that put them there.

Any application beng run in a full-screen rather than a window would do it, I think. If your staff are using a PC just as a terminal into (say) a mainframe application, they may do that to avoid seeing other windows. I know people who only use a PC to run an emulation of another kind of computer; most of them always run full-screen because they don't like seeing any part of a Windows window.

> its a minor thing and most important is that the malware is catched and deleted before it can do harm. Yes, I suppose that's true. But if (real malware rather than Eicar test files) can't be dug out of Quarantine and sent to Emsisoft for analysis isn't there a problem? And - worse in some ways - if these files had been false positives that got quarantined, by not showing them in the Quarantine GUI pane I wonder how you'd expect a user to find them and reinstate them? > This happens because probably moving to quarantine doesn't succeed because the browser deleted the source file already. Why would it do that? I used Chrome for my experiments, so presumably the IOfficeAntivirus/AMSI integration caused Chrome to ask EAM if the file was ok. EAM produced an alert and asked me what should be done with the file. Surely Chrome does not have the opportunity to delete a file until the EAM code returns control to Chrome? Why would EAM return control to the browser before it has done what the user asked, and actually put the file into Quarantine? In any case, the evidence (two files in Quarantine, with the date/time stamps of these Eicar file experiments) is that /EAM put them there/. If they don't represent quarantined files, what are they for? Why, whatever they are, are they not shown in the GUI?

C:\>dir "C:\Program Files\Emsisoft Internet Security\Quarantine" Volume in drive C has no label. Volume Serial Number is F607-7930 Directory of C:\Program Files\Emsisoft Internet Security\Quarantine 01/12/2019 19:50 <DIR> . 01/12/2019 19:50 <DIR> .. 01/12/2019 19:47 26 0ed050c8-7392-4cbc-abaf-1ed4a1b8e9f7.EQF.EIQF 01/12/2019 19:50 26 8d974b5a-b9f9-425d-a92d-24f326157c48.EQF.EIQF 2 File(s) 52 bytes 2 Dir(s) 203,809,226,752 bytes free Both files got there when I tested the download of the eicar test file as described earlier, after EAM asked if the files should be quarantined and I clicked on the relevant button. If the files are not supposed to be there, EAM should not have put them there. If they are corrupt in some way, then it was EAM that corrupted them.

Win 8.1, auto-update here ok, but the GUI's Quarantine pane still shows nothing despite files being present in the \Quarantine folder.

@stapp I think it's because EIS auto-updated in-place to EAM, without creating a new folder for itself. (Similarly I used to use a 32-bit version of Firefox - though I'm on a 64-bit version of Windows - so Firefox was then installed under C:\Program Files (x86)\. When Mozilla finally produced a 64-bit version and it auto-updated, it did so inside the same folder as before so my 64-bit Firefox is also in a subfolder of C:\Program Files (x86)\.)

> Jeremy, your example shows behavior that always was there, as you have *not* set your FileGuard scanlevel to 'Default'. True, it's "thorough". But EAM knows how I have Fileguard set. Whether the alert I got came from the new IOfficeAntivirus/AMSI interface or not, the alert did offer me a Quarantine option and I did choose it. The files did go into the C:\Program Files\Emsisoft Internet Security\Quarantine folder. I don't see why how often Fileguard scans files has anything to do with why the files in Quarantine are not listed in the Quarantine dialog pane.

@spikey Thank-you, but it's not the copying of the (open) PST file I wondered about per se, so much as whether a one-off close and reopen of that file might affect the way EAM's exclusions work. Ie, whether an exclusion not previously in effect can take effect when the file is already open.

Hmm, I tried that link to download the test file using Chrome (and the newer EAM 9864 beta). First time: the EAM alert says the file is downloaded but dangerous, so I clicked the Quarantine button. The log tells me both things occurred, but when I then go to the Quarantine display, it is empty. I repeated that; the test file definitely does get downloaded - I can see it in my \Downloads folder, and it vanishes from there again when I click the Quarantine option in the alert... but again, it's not in the Quarantine display. C:\Program Files\Emsisoft Internet Security\Quarantine contains two files, with recent timestamps, so presumably those are the quarantined objects. Why does EAM not show them?

If your last set of debug logs were made when the exclusion wasn't defined, Emsisoft might benefit from more logs with it defined. I know nothing about Outlook, but maybe it needs to be stopped and restarted for EAM to treat its files differently.