• Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by Raynor

  1. If you add a hard drive, that changes the Machine Key. If you then remove the hard drive, it changes it back. If an update happens after the first Machine Key change, and then again after the second Machine Key change, then that counts as two remappings.


    I apologize for not mentioning the timeout is 24 hours. After 24 hours the license can be remapped again.


    There is no problem with it, however if the license key is locked out in our system it won't allow you to activate it again until it is unlocked again (24 hours after it gets locked out). If it's locked out, then you can use the free trial for the 24 hours until it's unlocked again.


    Thanks a lot for your detailed reply. Now the whole thing seems much clearer to me.


    As HDDs in my 5.25" drive bay can be hot-swapped, I will just disable automatic updates before inserting my backup HDDs and then

    eject and remove the backup drive before re-enabling auto updates. This should hopefully revert the machine key to its original state.


    This is of course a slight annoyance, but one that I can live with as I only do HDD backups on a weekly to monthly basis. :unsure::lol:




    Unfortunately it is difficult to generate a unique ID for each computer that is reliable. Since the vast majority of users don't change hard drives often enough to trigger license issues, using hardware such as hard drives to generate it is usually fairly safe. Even in a corporate situation


    We've tried a number of other methods, and we keep running into issues with them. Not every motherboard has a serial number embedded in their firmware, for instance. Many OEM computers are indistinguishable from each other because the exact same hardware is used, and since it's almost always cheap hardware many things get overlooked. For Microsoft this probably isn't an issue, since they got their money from these OEM computers and in most cases don't need to worry about whether or not they can uniquely identify them. Windows also doesn't have a free trial that's tied to a Machine Key like our software does, and we had issues where the free trial was already expired on many computers because they all had the same Machine Key.

    Obviously if we think we can make generating Machine Keys better in the future, then we will. For now, the best recommendation I can make is to use USB since it is the cheapest alternative that won't cause license issues.


    Also, thanks for clearing that up. I'm keeping my fingers crossed for future improvements in this area.


    Thanks again and all the best


  2. Emsisoft Internet Security and Emsisoft Anti-Malware will generate a unique ID ("Machine Key" or "Machine ID") that our license and update system uses to identify your computer. Hard drives (or at least certain information about them) are used in creating the Machine Key for your computer. If the hard drives connected to the computer change, then a new Machine Key will be generated, and the next time updates are downloaded the license will be remapped since the Machine Key is different. If a license is remapped 5 times in a day, then it gets locked out from being remapped again in our system, which could easily cause the issue you are experiencing (assuming it switched to the free trial due to being unable to remap the license key).


    Thanks for your reply. Unfortunately, some details still remain sketchy to me ...


    I have been switching HDDs quite frequently (as posted above), but not five times a day ?!

    What happens if a key gets "locked" from being "remapped" ??? Is this a temporary lock, just for the same day? This is still not clear to me.


    It did indeed revert to some kind of trial key (This happened twice so far). Both times I then reentered my original purchased license key,

    which worked without any problems. Is there a problem reentering my original key straight away? Could it be permanently blocked ?

    Should I wait a few days before restoring my original license for safety reasons (this would be possible, as I am granted ... 30 days :P) ?


    In other words: I could live with having to reenter my key at times (which should not happen too often in the future, as the HDD changing bonanza

    that I've started a few days ago days won't happen again so soon after it is finished), but I wouldn't want to run the risk my key getting blocked...

    So any advice on when to reenter my original key would be appreciated.


    Hard drives connected to the computer via USB are ignored when generating the Machine Key, as are NAS drives, so we recommend connecting backup drives via one of these two methods instead of using SATA/eSATA. Obviously USB hard drive enclosures are cheaper than NAS, and access/transfer speeds should be faster with USB, so that might be the best place to start.


    I am really sorry that I have to say that this piece of advice is not satisfactory.  :blush:  An AV program (no software for that matter) should not dictate the way how I connect my backup HDDs.


    I have a 5.25" internal docking station in my computer that easily lets me switch normal (i.e. not contained in an enclosure) SATA HDDs,

    which then are connected directly to the mainboard's SATA port 4.


    This is the one I use:



    This is a very cost-effective way of doing backups as I just have to buy simple standard HDDs, and don't have to fork out more money for the cases/enclosures.


    I would like to reiterate that the algorithm used to calculate the key seems too STRICT and DUMB ^_^ , as I have only been switching ONE HDD, while three other drives

    (the ones that are permanently in my computer's case) remained the same (see HDD config as posted above).


    This should really be possible and not cause any license key issues :(. I certainly won't be switching the way I do my backups

    because of some piece of software. Don't get me wrong, I really like Emsisoft Internet Securiry a lot, but this behavior seems a bit overbearing ...


    All the best,



    PS I absolutely understand that you guys need a way to uniquely identify a PC in order to check If a license is not used

    too often ... but maybe the machine ID could be calculated a bit differently (graphics card ? some other serial numbers?

    MAC address? etc.), or the HDD part could be toned down a bit ... After all, Windows itself doesn't seem to mind and stays activated,

    so MS must have figured out a smarter way of identifying computers (AFAIK they especially focus on mainboard changes which seems smart to me).

  3. I have just been struggling with the same issue.






    Using several Backup HDDs connected via SATA causes the license to change to a 30 days trial :unsure:.


    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  :unsure:.


    Something is definitely wrong, please investigate :ph34r:





  4. Do you connect and disconnect hard drives to your computer frequently, or perhaps use some sort of virtual hard drives?


    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 :unsure::wacko: .


    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 :blush::angry:






    (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.)

  5. First of all, thank you for you reply.


    In the case of Firefox, the firewall wouldn't be able to help, since Firefox needs to be able to get out to the Internet to load webpages, and any exploit it would attempt to load and run it would do so as if it were a normal webpage (it's all loaded over HTTP/HTTPS).


    Yes, I'm aware of that - I'm only talking about setting the Behaviour Blocker to "Custom".



    As for the exploit itself, EIS isn't going to detect it, beyond perhaps the File Guard detecting a malicious HTML/JavaScript/etc. being saved in a browser/Flash/Java cache somewhere. What EIS will do is block whatever the exploit saves on your computer and executes, thus stopping the infection. The point of an exploit is to get a malicious executable (usually called a "dropper") to run on your computer, and then this "dropper" will install the infection, so we focus on stopping the dropper since it's what's actually dangerous.

    Setting Firefox to be monitored won't change any of this, and could potentially lead to strange problems with Firefox.



    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 :unsure::wacko: ... but maybe I'm overthinking the whole issue. :D

  6. Now here's a thing which I've been wondering about for quite some time now :wacko::


    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,


  7. When Beta Updates are turned on, stable updates will still be installed if they are newer than the latest beta version. Once the fix is included in a stable version you can simply disable Beta Updates if you don't want to continue to receive them, and no further action should be required.


    Thank you for clarifying that.


    This could be your Internet Service Provider's IP address. You may want to check this list and see if you can find some information about the specific IP address you saw.


    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 :P

  8. If using the beta, will it require uninstall, when, it out of beta, or will the update correct from beta to non beta?


    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!

    Download Image