JeremyNicoll

Member
  • Content Count

    1818
  • Joined

  • Last visited

  • Days Won

    28

Posts posted by JeremyNicoll


  1. 9 hours ago, toadstew2016 said:

    In custom scan where drives are listed I am clicking on D drive,but still wants to scan C drive.Could you show me with a screen shot what I should be doing to scan drive D.I am not getting something here.

    You've already been given a screenshot of what's necessary.  So if that didn't help you, we're not understanding your problem.  Maybe you need to show us a screenshot of what you are actually asking EEK to do. 

    Arthur's made the point that ALL THE DRIVES listed in the top section of the panel get scanned.   Earlier you said "but you should be able to click on D drive (indicated by blue highlite similar to copy and paste"... which makes me wonder if in the list of several drives you're clicking (turning blue) the entry for D:\   ?    From what Arthur said, that will NOT just ask EEK to scan D alone.  Did you follow his advice to remove the other drives from that list?


  2. No oridnary forum user (eg me) can see the files you attached, though Emsisoft staff will be able to.    If there's nothing private in them, c&p their contents into posts.

    Depending on what options each scan ran with,  presumably what was examined will be

      "C drive only"  - system files on C, plus user files on C

      "D drive only"  - system files on C,  plus user files on D


  3. In EIS, the pop-up help for "Malware Traces" says that means the registry and configuration files will be looked at... obviously that's going to include the system drive.  But I don't see what your problem is.  If you tick these systemy things, locations of system files on C will get looked at, and after that, the ordinary files elsewhere on your nominated drive(s) will be examined.  Are you stopping each of your test scans before processing of the ordinary files starts?  


  4. I've never used EEK... but if its GUI is the same as the EIS one, underneath the section where you specify drives to be scanned there's two columns of options dictating what sorts of things will be looked for on your whole machine, as well as the drives you nominate.  As GT500 said, some of those things, if ticked, will always look on your system drive - and on your machine that means some scanning of some parts of C:\ will happen if you've got those options ticked.

    You need to look at each of the tickable things in turn and decide whether you want them active.


  5. Perhaps the issue would be better framed around why reports generated for users, and user-defined sets of scanner settings, are placed in an OS folder rather than a user-specific one?

    I've used apps in the past whose installers separaretely ask whether user-data should be deleted, and normally point out that if one is planning a subsequent reinstall that such files might still be required.  Ideally just installers also tell you where the files are, so you can make an informed choice.


  6. Are other reports still viewable?  I wonder whether the problem is that the log files are not in c:\ProgramData, or that they are there and corrupt, or that they are there and something's altered their permissions so that the EIS app can't open them.  If they are actually present in the folder (you can look with File Explorer) do they have .txt file extensions? 

    Here, if I double-click a .txt file it opens in Notepad (though I also have several other file editors and rarely use Notepad) - do your report files open that way if you double-click them?   


  7. If I try a custom scan, which has 5 stages, there's a very clear allocation of 20% of the progress bar to each of the 5 stages.  As the first four stages run very quickly one gets to 80% (the start of the fifth stage, which is - here - the scan of all my files, as opposed to memory, rootkits etc) in a few seconds.  Then that last 20% of the progress bar's movement has (here) to show 510,000 or so files being scanned, so it does then move a great deal more slowly.   It's not, in my view, a useful indicator of anything.


  8. I'm curious: how does a problem like this get out into the wild in the first place?     If doing a few on-demand scans uses up file handles, surely that's the sort of thing that automated testing of new builds would, or should, pick up.   So, does that mean you don't do automated testing?   And, if you do, when you solve a problem do you also modify the test framework to try to detect that sort of thing happening in future builds?


  9. 2 hours ago, GT500 said:

    There wouldn't be any need to hash it. We can save every file detail we want (such as name, size, last modified date, etc) and then simply compare them later. In most cases that would be faster than pulling the file details, saving them to a file, and then hashing it in order to determine if it has changed.

    The advantage of the hash, as I saw it, is that your developers would know how much space it was going to take up - it'd be easy then to store that finite small amount of data inside the structure where you define whitelist entries.  OTOH storing an arbitrary amount of information for an arbitrary number of files in the whitelisted  directory would probably need yet another sub-database.  I suppose it's possible that a user confronted with a "something's changed in this whitelisted folder" alert might want to know what had changed, and for that it might be worth storing the generated directory list somewhere - but only as a plain text file not intended ever again to be processed by EIS.  Malware couldn't alter it (to mislead the user) because its original hash would be stored inside EAM/EIS.  


  10. Even in an interpreted scripting language, I can get detailed directory listings extremely fast; I'd expect tailored compiled code using the relevant API to be able to do the same thing more quickly.  The purpose of the idea, remember, is to spot extra files being added to a whitelisted folder, where the user might not want those extra files also to be whitelisted, and of course to spot changes being made to existing files.   Make-a-dir-list and hash it code doesn't have to be really finicky, it just has to decide if it looks as if there's been a change to folder contents, so the user could be asked if they wanted changes since whenever to be whitelisted as well.  You're right, it wouldn't be perfect, but it would be safer than the present whitelist mechanism that makes NO attempt to track changes in a folder.