Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Raynor

  1. I have just been struggling with the same issue. See: http://support.emsisoft.com/topic/20326-eis-sudden-change-license/ Using several Backup HDDs connected via SATA causes the license to change to a 30 days trial . BUT I have been using SATA-connected backup HDDs it the past together with Emsisoft (for over a year) and have never had this issue before. It first happened to me a few days ago... Perhaps there as been a change it the "sensitivity" / the way the unique machine key is calculated ? PS looking through the forum, I am getting the impression that there have been quite a few posts recently about strange / unwarranted license changes back to a 30 day trial ... any you can add me to that list . Something is definitely wrong, please investigate Compare: http://support.emsisoft.com/topic/20305-eam-license-troubles/ http://support.emsisoft.com/topic/20301-trouble-with-license/
  2. I have also just been shown another prompt saying that "my licencse would expire in 30 days". I thus had to enter my license details again. This is the second time that this happened to me in the last few days. Incidentally, I have indeed been changing my backups HDDs quite a bit during the last few days as I am in the process of restructuring my backup HDDs (formatting new ones, erasing old ones). They get connected via SATA, so they might be seen as "normal" HDDs (HDD config details see below). But I have always used several extra HDDs for backups and have never been shown such a prompt in the last year. Something is fishy here . Has Emsisoft's "sensitivity" towards HDD changes been increased in one of the recent updates ? Could this be the reason for receiving those erroneous messages that the license would expire in 30 days ? My HDD configuration: SATA Port (1): Intel SSD ("system disk"), never changes SATA Port (2): Western Digital HDD ("data disk"), never changes SATA Port (3): Western Digital HDD (another "data disk"), never changes SATA Port (4): Backup drives, only those disks have frequently changed in the last few days. --> Various HDDs have been connected and disconnected to the fourth SATA port as I am in the process of getting rid of old backup HDDs (erasing them) and formatting new ones for future use... It seems to me that the algorithm used to calculate the machine ID seems to be too strict AND dumb as I have not changed my first three HDDs (System & Data), only the fourth connected HDD has been changed several times, which seems to be repeatedly causing the program to revert to a "30 days" license Thanks, Raynor (PS: please let me know If you need my email address to take a look at my licenses (if this helps with your investigations), I use different email addresses in the forum and in the license center.)
  3. Ah, I see. Thanks a lot for clearing this up. So I'll just leave the behavior blocker set to "allow all" for trusted / digitally signed programs .
  4. First of all, thank you for you reply. Yes, I'm aware of that - I'm only talking about setting the Behaviour Blocker to "Custom". What I've been thinking is that "Is it not theoretically possible to cause a legitimate process/app, e.g. Firefox, to misbehave by exploiting well, an exploit. In other words, is it not (at least theoretically) feasible that an exploit could be used to make a normal program misbehave by making it execute arbitrary code., But thinking about it further ... yes, after all, for an infection to happen, at some point some executable needs to be dropped somewhere ... But couldn't perhaps Firefox itself be "abused" to act as the dropper. This would then be tolerated without any alerts being shown, wouldn't it (because Firefox is trusted and set to "Allow all" in the Behaviour blocker")? I'm talking about protecting against that specific vector. ... I'm still a bit confused ... but maybe I'm overthinking the whole issue.
  5. Now here's a thing which I've been wondering about for quite some time now : Usually, the behaviour blocker automatically creates "All allowed" application rules when encountering digitally signed and thus trusted apps. I've been wondering if it might be safer to manually set the behaviour blocker to "custom montoring", at least for internet-facing, potentially exploitable apps. My reasoning: Let's say there is a critical vulnerability in a trusted program (e.g. Firefox) that can lead to arbitrary code execution / injection. If this vulnerability were executed, the program would be able to do some nasty stuff to the system. Wouldn't this unexpected and malicious behavior then be automatically tolerated by the behaviour blocker because the program itself is trusted and thus has been set to "All Allowed" ? Thanks for any insights, Raynor
  6. Confirmed. After that update everything is working fine again Thank you and good job
  7. Thank you for clarifying that. Thanks for your reply. After doing a bit of more research, I have come to the conclusion hat this is indeed an auto-assigned link-local IP address (for those interested: https://en.wikipedia.org/wiki/Link-local_address).It is not assigned at every Windows startup (i.e. it often is not listed in the firewall's private network IP settings), so I figure that it only gets assigned whenever something goes wrong with the DHCP
  8. I have the same question Right now, I have the beta installed, and everything seems to be running very smoothly. Good job Emsisoft developers! On a side note: while browsing through all the firewall submenus to ensure that everything looks and behaves as it should I noted that a 169.245.X.X IP address gets added to my private network (in addition to the expected 192.168.X.X address). Is this safe ? A quick google search seems to indicate that this is a "link local" IP-adress that can somehow be assigned during (or before) the DHCP autoconfiguration process. So is my assumption correct that this is no bug or reason for concern and that this IP is indeed a "harmless" part of my local network ? Thanks in advance!
  • Create New...