Lynx

Member
  • Content Count

    2546
  • Joined

  • Last visited

  • Days Won

    19

Lynx last won the day on January 8 2015

Lynx had the most liked content!

Community Reputation

34 Excellent

About Lynx

  • Rank
    Forum Veteran

Profile Information

  • Gender
    Male
  • Location
    Australia

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hello guys! {XP Pro, SP3; EAM 6.0.0 56 beta} There were several reports in addition to this one regarding hanging scans including the answer from the developers http://support.emsis...dpost__p__42114 I performed several Scheduled Scans in a row today using new beta (0.56), because unfortunately hangings were reintroduced after my last report and successful runs with previous betas (starting from 0.53). I do have images but they may not help a lot. I may just mention that the progress shown is usually 85-90% (6 of 6 stages). The only suspicion I have currently after running 5 consecutive Scheduled Scans – the scan will most likely stall forever after PC went into Sleep Mode and then being waken up (2 cases). During the other 3 tests I was keeping PC active & the same scans ended perfectly. My regards
  2. Greetings! {XP Pro, SP3; EAM 6.0.0.56 beta} There were definite FP detections during Scheduled Scans tests performed this morning : C:\WINDOWS\system32\notepad.exe detected: Virus.Win32.Virut!E2 C:\WINDOWS\ServicePackFiles\i386\notepad.exe detected: Virus.Win32.Virut!E2 The thing is – if you would scan the said suspicious files having the same/current EAM signatures using Shell Extension scan - no detections are yelled by EAM when you scan \system32\notepad.exe, but …\i386\notepad.exe happens to be detected as above Respectively: SHA256: 865f34fe7ba81e9622ddbdfc511547d190367bbf3dad21ceb6da3eec621044f5 SHA256: 19b2602b2ff52d358b8c86589f4524e8c762609fd5f483ac22d2fb5a319e0121 My regards
  3. Hi francois, 1st , as far as I know from your reply here you’ve upgraded to 0.54 already I’m not sure what the developers have done, but the news from here: I’m using Scheduled (Smart Scan) very rarely (basically for the testing purposes) & I practically never Custom scanning drive G: (purely my data partition) , but since the described abnormalities occurred I’ve tested few times with 0.53 beta, and today after reading your post here with 0.54 beta All went fine without a hitch Cheers!
  4. Thanks Fabian, Sorry for the delayed answer I know about scanning process (es), on a “different” drive. Say, I do have one usually running from D:\, but that triggers scanning just that executable from D:\ which is not included into the Custom Scan – not the whole D: drive Additionally there are no processes running from G: (purely data partition) As for Traces I was always sure that only Registry scan is involved. I’ve never noticed scanning files. Traces could be found whether associated files exist or not. I don’t know details about Rootkit scan Anyway, good news is -I re-tested the same Custom Scan with the new version (0.53 beta) and all possible combinations of the “Objects” options. All went well without even touching, not saying scanning whole G: drive My regards
  5. Greetings! Recently (5 days ago) I’ve posted FP request , which was ignored as several other enquiries Fine. I can live with that At the same time, today I created a copy of the said text file (see the link above) & just renamed it changing a typo (Polocies to Policies) & removing <>.txt additional extension. After simple file renaming I’ve got “OnExecution” Alert (see attached image) Why? The file was opened/accessed/the name was changed, but I’ve never used “onAccess” option since it was introduced by EAM and never will. Sure my response was - “Allow”/& No for creating any rule What kind of execution was that ? Any clue? TIA
  6. Hi scottls1, As I posted above the detection/or FP has nothing to do with scan freezing enquirey here My regards
  7. Hi Today similar hanging appeared during scanning drive G: I had to stop the scan This time it was simple <>.Doc file. Nothing wrong reported when the said file was re-scanned later using Shell Extension Image Attached. Please do not pay attention to FP note – that was prepared for different request My regards
  8. Hi Guys, {XP Pro; SP3; EAM v6.0.0.52 beta} I was performing Custom Scan of USB Stick. See attached settings screen. All of a sudden EAM “jumped over” drive G:\ (partition on a second physical hard drive) The scan eventually hanged (I posted into another thread), but the question here - why would EAM even consider scanning another drive, when it’s not stated in Custom settings? My regards
  9. 1st, Happy New Year 2 everybody! {XP Pro; SP3 32bit; EAM v6.0.0.52 beta} EAM scheduled scan was performed today & got stuck forever on System.Device.ni.dll, (immage attached), which belongs to Microsoft® .NET Framework Recent updates for .NET(s) were issued by MS today (consider offset time zone) I'd just closed EAM & carried on with my work ... sure that is a bug To devs: please tell if any additional info required Thanks
  10. Basically, it is not a major bug as far as I can see it currently, but still… You’ve created an entry in the whitelist. It could be malware or trace name/file/folder/process When the user returns to the whitelist he/she can easily (deliberately or accidentally) edit the Type, say from malware name to folder or whatever is in the list currently. After that the only option is pressing OK. No check is performed by the Software. It seems like the Scanner/File Guard/BB check-boxes settings will prevail Unfortunately I don’t have time at the moment in order to find whether there could be any bad implications that we cannot see yet, but in any case I find the described as being a design flaw. It’s at least misleading & confusing {added} Then, the content of the Item column can be edited without any check by the Software, therefore non-existent items can be created My regards
  11. Hi AaLF, Go Scan PC > Manage whitelist link > in the 1st column ("Type") hit the tick > choose "Folder" option from the list Then when you click the second column - which is ("Item") you'll get the common "3 dots" button > click > set the needed folder Cheers!
  12. Hi Guys , welcome to the forum Ron L, Please use this page as a start in order to get help in case the forum is not enough Especially pay attention to “Customer Center" (white) Emsisoft sign at the left top of the forum is a link. Please click Then you have all pages/info available including “Support” Tab & the respective link provided by me above Cheers! p.s. Marcelle McMillen, That was 1st time I've seen the address posted by you … it could be legit , but it is always better to deal with this forum and with Emsisoft developers/support team. My regards
  13. Thanks for the reply dallas7, We all do know that Ashampoo is using EAM's engine(s) At the same time I am not aware whether they are using the new one that was introduced in v6 of EAM I'm just hoping that developers will reply regarding the matter Anyway, as far as I am concerned, that is about signatures only As for BB - EAM's BB is the best on the market you can have at this stage Between us when nobody listening - I rely only on EAM's BB I do not and did not run any signature related Software for 5 or more years since EAM was developed, except rare cases where users reporting some weird detections & / or suspected bugs I never used newly introduced "onAccess" options by EAM . My choice always was is and will be -"onExecution" only & BB - perfect combination! As for OA++ please read this forum - there will not be any development for OA++ including incorporating new engines any more. So, stick with current OA whether you consider choosing Free or Premium. OA (not OA++) and EAM is one of the best security combination currently on the market Cheers!
  14. Hi dallas7, Settings for Behavioural Blocker (BB) and File Guard (FG) a separate because the detection technique is completely different As you correctly pointed in #3) FG is a signature related detection. So, unless you disable FG you will have those detection alive whether it is just “onExecution” and/or a combination of “onExecution” (only executables are scanned) and “onAccess” (any files involved are scanned) based on current signatures Disabling BB has nothing to do with FG. And yes, as in #1 & #2 - when you disable BB currently created Application Rules are irrelevant – no Monitoring/no Alerts until re-enabling BB (rules are preserved). Unfortunately in the existing Help File (7.1 Application Rules) there is no clear statement that Application Rules belong to BB My regards p.s. as a simple test please - disable BB and leave FG - execute Eicar.exe or TrojanSimulator - you will get FG Alert (based on signatures)
  15. No problems with updates here whatsoever Cheers!