Offline Sword

Member
  • Content Count

    76
  • Joined

  • Last visited

Posts posted by Offline Sword


  1. It would be best to use the whitelist, as entries in it are not automatically removed.

     

    Thank you. It actually works.

     

    By the way, I find that whitelisting a folder from the Behavior Blocker now also works. For example, whitelisting the folder of Sandboxie could depress the alerts shown in #1. It is amazing to me, since in the past, @Fabain Wosar ever said that we could not whitelist an entire folder from the BB: http://support.emsisoft.com/topic/19719-eam-in-a-developer-environment/?p=147193 . I guess this problem was fixed in the recent versions?


  2. It the directory does not exist, then the rules for applications in those folders are deleted.

     

    You are right. To solve this problem, I think EIS can reserve the behavior blocker rules & firewall rules for non-exist files rather than remove them automatically.

    If we really does not need an outdated rule, then we can remove it manually.

    You can also provide a button when allows the user to remove all the rules for non-exist files in a batch, like what we can do with Spyshelter and EXE Radar Pro.


    • Which product, product edition and exact product version number your support request refers to: Emsisoft Internet Security 11.6.1.6135 (64-bit version)

    • Your operating system including the edition, service pack level and the bit-depth (32 or 64 bit) if they apply: Windows 7 Pro 64-bit

    Other security applications you may have installed: Sandboxie (Invincea) and Novirusthanks EXE Radar Pro. 

    If my memory serves me correctly, about one year ago, I found that EIS could automatically delete some rules (like Firewall rules) immediately after these rules were created by answering the alert window. This bug or feature caused a problem that some applications would frequently trigger alerts (like Firewall alerts or Behavior Blocker alerts). of EIS, which I think is disturbing. At that time, the staff here told me that this problem could not be reproduced, though I could reproduce it.

     

    Today, it seems that this problem persists. Please check the following screenshot.

    post-34940-0-26401200-1460722387_thumb.png
    Download Image

    As you can see, the rule for "rmdir" is automatically deleted. So each time Sandboxie remove the contents in a sandbox, it will trigger an alert like this:

    post-34940-0-40763700-1460722536_thumb.png
    Download Image

     

    How to reproduce this problem?

     

    1. Create a sandbox in Sandboxie. Configure it such that all the contents inside this sandbox will be automatically deleted when the processes running inside this sandbox exist.

    2. Running some applications, such as Chrome, in this sandbox.

    3. Close all the applications running inside this sandbox. I think you should see the alert for rmdir like the screenshot above. Choose "Allow always " such that an allow-rule will be created by EIS for rmdir.

    4. Open the "Application Rules" Tab in the main window of EIS. I do not mean that this step is essential. But with this step, I could definitely reproduce this problem.

    5. Perform Step 2 and Step 3 again. Then you should see the alert window shown above again.smile.png

     

    If you still could not reproduce this problem...I give up...


  3. The thing with compatibility is that it outright blocks a whole bunch of features we would like to add. That is why we no longer recommend using EAM alongside any other AV software. At the moment we are still compatible with pretty much all of them and if we can easily work around a conflict we will still do so. However, we no longer consider a degradation of compatibility a blocker for new features.

     

    With the new features you mentioned, especially the anti-exploit feature, could Emsisoft products still be used along with other anti-exploit products? Or would this cause compatibility issues?

     

    Thanks.smile.png


  4. Hi, Emsisoft Staffs.smile.png

     

    Maybe I found a bug of Emsisoft Internet Security v10.

     

    Just now, I downloaded a malware pack consisting of 50 samples.

     

    I decompressed it and scanned it with the option in the context menu.

     

    The detection result is shown in the following screenshot.

     

    post-34940-0-31839100-1446455302_thumb.png
    Download Image

     

    Please pay attention to the items corresponding to 19.vir. (But the problem does not happen here).

     

    Then I clicked the buttion "Delete selected".

     

    After that, one item corresponding to 19.vir was left !

     

    post-34940-0-89855300-1446455419_thumb.png
    Download Image

     

    Then I clicked both "Quarantine selected" and "Delete selected", but none of them works. This is because, the file "19.vir" has actually been removed. So I think the problem that the item of "19.vir" was left in the detection list should be a bug.

     

    I have repeated this several times. I am 100% sure that I can reproduce it.

     

    The version number of EIS is 10.0.0.5735.

     

    My operation system is windows 7 x64.

    • Upvote 1

  5. however there are also plenty of people in China who don't have issues.

     

    Yes, of coursesmile.png . In the current city I have no problem in updating any products of Emsisoft products.

     

    But according to some posts in some security forums, people who have problem in updating Emsisoft may be more than the users who have no problems.

     

     

    It's possible that it's the backbone provider that is the cause, and not the actual ISP.

     

    The problem is that even the ISPs generally have no interest in solving these issues, let alone the backbone provider.sad.png

     

    Could Emsisoft do something on this problem? Like providing offline updates? 

     

    By the way, I notice that there is an option in EIS that "Using SSL encryption for all server communication". I hope to know that, whether the daily updates are also encrypted by SSL?


  6. OK, we can continue this once you are able to return home to do further debugging. It's probably a local issue with the Internet Service Provider, however there's some debug information that we can try getting to help find out what is going on.

     

    Yes, I agree that this might be a problem caused by the ISP.

     

    But it seems that this is not a local issue that only appears in one city. As far as I know, many people in my country (China) find that they cannot update EEK without VPN.

     

    It is really a strange issue, because, unlike avast, Emsisoft has not been blocked by the ***. tongue.png

     

    I hope to help to solve this problem, but I can only reproduce this problem in my hometown, not here...sad.png


  7. This is only happening some of the time? How frequently does it happen? There are no error messages displayed when it happens?

     

    It happens most of time. Until now, only one update is completed successfully.

     

     

    There are no error messages displayed when it happens?

     

    There is no error messages. EEK just keeps initializing all the time.

     

    By the way, it seems that this problem only happens in my hometown.

     

    I will leave my hometown tomorrow because my vacation will end.

     

    So maybe we need to continue this thread three months later.


  8. Hi. Just now I found that, if I open your AMN ("Anti-Malware Network") site http://www.isthisfilesafe.com/, and reopen/refresh it immediately, the webpage cannot be displayed and I will get a ERR_CONNECTION_RESET error.

    However, if I reopen/refresh that webpage in about 1~2 minutes later,  then the webpage can be displayed successfully.

    This issue can be reproduced in both IE and Chrome.

    However, if I use a VPN program, this problem does not appear...

    So...I guess this website is blocked by ... (I am from China) or by the ISP (I cannot confirm...)

    Would this influence the protection capability?

     

    Best regards.smile.png


  9. In general we have no intention of fixing this. Any workaround would be Sandboxie specific. In the end the point of Sandboxie is to virtualize the system and make processes see an environment that isn't there. As some of our components do operate as parts of the virtualized process, they too will only see the virtual view. Doing something like this requires access to kernel mode. So we don't consider it a security problem because if malware manages to enter kernel mode, it virtualizing applications on your system will be the least of your problems.

     

    Thank you for your reply and the information you provided.

    I guess you mean that this problem will not affect the security. Maybe you are right. (I should say that I know little about kernel or virtualization.smile.png )

     

    BUT, this problem indeed affects the usability.

    Since FW cannot automatically create correct rules, it will generate alert again and again and again each time when the sandboxed application wants to establish a network connection...

    Note the log events marked by red boxes in the screenshot at the bottom of this post. You can find that alerts are generated nearly every minute.

    Each time a new alert appears, I will select "Allow All Connections", but the alert will appear again next minute...unsure.png

    This is because, when I select "Allow All Connections", EIS will automatically generate a rule based on the wrong path.

    It seems that such a wrong rule is unable to properly handle the sandboxed programs. This leads to the repeating alerts.

    I mean, EIS creates a rule that allows all IN & OUT connections of "C:\Users\XXX\AppData\Roaming\baidu\BaiduYunGuanjia\BaiduYunGuanjia.exe", which does not exist. And when "C:\Sandbox\XXX\BaiduTestBox\user\current\AppData\Roaming\baidu\BaiduYunGuanjia\BaiduYunGuanJia.exe" wants to connect the network, EIS cannot find a rule that can MATCH this path, then it generates alerts again.

     

    A real mystery is that, this issue seems to be FIXED today...

    Please see screenshot below. You can find that the event marked by the green box shows a correct rule.

    Alert is no longer generated...

    I cannot understand what happened, because, no new version of EIS is released today, right?

     

    post-34940-0-00040700-1436594548_thumb.png
    Download Image

     

    Best regards.


  10. Are you sure that it's being executed in such a way that EIS will see it running out of the folder you expect?

     

    Sorry but I cannot fully understand your question...(maybe because I am not a native English speaker)

     

    So I will provide some more details on my issue instead of directly answering your question.

     

    The REAL path of the executable file "BaiduYunGuanJia.exe" in the screenshot in #12 is "C:\Sandbox\XXX\BaiduTestBox\user\current\AppData\Roaming\baidu\BaiduYunGuanjia\BaiduYunGuanJia.exe".

     

    However, this executable file itself does not know it is located in this path. By contrast, when it is launched, it "believes" that it is located in "C:\Users\XXX\AppData\Roaming\baidu\BaiduYunGuanjia\BaiduYunGuanjia.exe"

     

    In other words, this executable file is cheated by Sandboxie.

     

    The problem is that, EIS tries to create rule for "C:\Users\XXX\AppData\Roaming\baidu\BaiduYunGuanjia\BaiduYunGuanjia.exe", which means that EIS is also cheated by Sandboxie.

     

    As you can see in the following screenshot, although EIS continuously tries to create rules for "C:\Users\XXX\AppData\Roaming\baidu\BaiduYunGuanjia\BaiduYunGuanjia.exe", in fact there is no such a folder. That is why I say that EIS is also cheated.

     

    post-34940-0-34438700-1436519990_thumb.png
    Download Image


  11. I'm glad to hear that the new version seems to have resolved the issue.

     

    Em...It seems that this issue has not be completely resolved.

    Consider an executable file located in the Sandbox folder. If it is launched automatically by other executable files as child process, then 5532 can establish correct rules for it, which is shown in the screenshots in #10.

    However, if it is launched manually by right clicking it and selecting the item "Run Sandboxed", then even 5532 could not create a correct rule for it.

     

    The rules in the following screenshot are all created by 5532.

    The rules in the red boxes contain the correct path, which is corresponding to the former case mentioned above.

    But, the rules in the green boxes are based on the wrong path, which is corresponding to the latter case above.

    Particularly, the executable files in the red boxes are launched as child process by the executable file in the green boxes.

     

    post-34940-0-22912200-1436447201_thumb.png
    Download Image


  12. It seems that the latest update (5532) may fix this issue.smile.png

     

    Particularly, yesterday, a post in malwaretips mentioned some issues of EAM/EIS were fixed in the latest updates.

    I was curious about whether this issue was also fixed.

    Therefore, I installed a trial version of EIS on the virtual machine (My physical machine is running some other antivirus product...

    Disappointingly, at that time I found that this problem still exists...

    The version of EIS I tested at that time might be 5526.

     

    However, just now I found a new post in malwaretips saying that 5532 is released.

    So I launch the virtual machine, update the version, reboot the virtual machine, and test it again.

    The new test result is exciting.

    It seems that this time the automatically added rules are based on the correct path.

     

    Please see the following two screenshots. The first is for BB, and the second one is for FW.

    The rules in the green boxes were automatically created yesterday. The exe files in these rules are actually located in the Sandboxie. So, these rules are still based on the wrong path.

    By contrast, the rules in the red boxes are created today. You can find that the path is right.smile.png

     

    post-34940-0-05931300-1436412691_thumb.png
    Download Image

    post-34940-0-58365300-1436412705_thumb.png
    Download Image

     

    Since the only difference between today and yesterday is that 5532 is released in this moring, I guess this issue may be repaired by 5532. But I still need to test some other applications.smile.png