itman
-
Posts
12,195 -
Joined
-
Last visited
-
Days Won
320
Posts posted by itman
-
-
Also, after the AdBlocker Ultimate uninstall/reinstall test, do the same for Privacy Badger.
My take is the conflict has to be related to one of these add-ons. I use Ublock Origin with Firefox and it is the only add-on I have installed. I have zero issues with B&PP anti-keylogger protection.
-
On 10/28/2023 at 4:06 PM, zoltanthegypsy said:
The FF privacy add-ons I'm using are Ublock Origin, Adblocker Ultimate, and Privacy badger.
I suggest you temporarily uninstall AdBlocker Ultimate and see if the scrambled keyboard character issue when using Eset keylogger protection disappers.
Also, using two adblockers could have adverse impacts on browser performance.
-
8 hours ago, Skier said:
There needs to be a means of recovering the contents of an ESET Encrypted Drive.eed when created on a drive (whether boot drive or not) following, for example, a Windows reinstal
The solution here is to modify or replace existing ESSP Secure Data with Endpoint Encryption feature: https://support.eset.com/en/kb7432-using-virtual-disks which supports virtual drives created on another system. It also includes the ability to backup/restore the keystore file.
-
6 hours ago, Guest Branko said:
How do I send a personal message here, I can't find it here how?
Refer to the below screen shot. For any posting made by Marcos in the forum, hover your mouse pointer over his name. Then select the Message tab.
-
There's a vulnerability in this software although it's rated low risk: https://www.cybersecurity-help.cz/vdb/SB2023091339 .
However, any vulnerability can be exploited. Might be an explanation for what happened here.
-EDIT- Vulnerability rated high risk here: https://nvd.nist.gov/vuln/detail/CVE-2023-3112
-
11 hours ago, Ming Chou said:
however it looks like that the client connects through IP address(52.160.70.199) and not DNS name(edf.eset.com).
How can we make sure the clients are connecting through DNS name and not IP Address?
Reflecting on this statement, the only way I can think of for this type of behavior is the client modified his Windows hosts file and entered;
52.160.70.199 edf.eset.com
Host file entries override and bypass DNS processing.
Why he would do this is beyond me.
-
Going through the multiple Wi-Fi connection problems in the forum, the only solution to the issue posted was;
QuoteStill, the root of the problem was the mac address. Later, by trial and error when I found out about it, I talked to a senior employee of the Internet provider and only he confirmed the information that I need to register a fake poppy address in my personal router (I don’t use the provider’s router).
none of the other employees by phone or those who came to my house, to replace the ONU equipment (converter from optics to ethernet) , they did not talk about it, everyone was leaning towards a bad wi-fi connection
The first randomly generated mac address did not work (there were problems), it turned out with the second one. Everything is fine now, there are no mistakes. What I understood from the conversation is that there is some kind of binding by mac addresses...(long story). There were no such problems on the old provider, but on the new one, they appeared immediately.
-
I ran tracert edf.eset.com and the final connection was to 52.160.70.199.
Next, I ran DNSChecker for edf.eset.com and all DNS resolutions world-wide were to IP address 52.160.70.199;
As such, whatever DNS resolution issues you are having are on your end and nothing to do with Eset.
-
-
5 hours ago, Ming Chou said:
however it looks like that the client connects through IP address(52.160.70.199) and not DNS name(edf.eset.com).
Per Robtex, edf.eset.com resolves to the following IP addresses;
-
As the article states, Driver Verifier utility analyzing epfw.sys might be able to shed additional info on what is going on here.
In this article: https://answers.microsoft.com/en-us/windows/forum/all/bsod-kernel-mode-driver-attempted-to-access/dc240524-45d9-4219-bd03-184b2725953c , an update of PC manufacturer motherboard chipset drivers fixed the problem.
-
Some further info on why encrypted VHD recovery might be "an effort in futility."
From a May, 2023 Secure Data forum posting;
QuoteESSP Secure Data creates an encryption 'keystore' file called 'premiumkey.dat' in C:\Users\USERNAME\AppData\Local\DESlock+\
If you delete this directory and the files within, then the encryption key is no longer available and your encrypted USB cannot be decrypted or accessed. Re-installing ESSP and enabling Secure Data will generate a new keystore file, which will NOT work for anything encrypted with a different key.
If we're lucky, and you still have the directories and files you deleted in the Recycle Bin, then you should be able to restore them and access your USB stick! If not, perhaps you have a Windows backup that you can restore where the DESlock+ directory and files are intact and can be restored to regain access to your USB.
Failing this, the data on the USB is inaccessible and you will need to format the device for future use.
I checked for this same folder on my device and it does exist. So it appears it is also created when a VHD drive is created.
Since the OP installed a new boot SSD and reinstalled Windows, this original Secure Data keystore folder no longer exists. Therefore even if it was somehow possible to associated the old VHD .eed file with the current Eset Secure Data installation, it would be impossible to decrypt those files. If there was a full backup of the old boot SSD taken prior to drive failure, it might be possible to restore the keystore folder from that.
Finally, Deslock+ documentation clearly states the this "keystore" folder needs to be backup to external media for just this event occurance; something Eset documentation is silent on.
-
Your hosts file is fine.
At this point, I have no clue what G-Data was detecting on the VT scan. Your TCPView screenshot shows a number of processes using 127.0.0.1 among them are Discord and Teamview. Both are known to contain vulnerabilities in other than most current versions. You could start by verifying latest versions are installed.
-
39 minutes ago, AlSky said:
but they say the version 17 will be released only in 2024
Not so according to Eset publication;
-
-
To get to the bottom of this, here's what I did pain in the butt it is.
I activated Secure Data and created a virtual encrypted drive on a non-boot HDD I have installed. Verified I could access it via password and that the drive loaded into Win Explorer.
I then exported my existing Eset settings.
I then uninstalled ESSP. While the uninstaller was running, I saw Secure Data roll by. Oh-oh. Sure enough, when ESSP was uninstalled, all traces of the previously created VHD were wiped from the HDD it was previously installed on. I will continue, but this in itself is enough to state that any VHD created by Secure Data option is 100% dependent upon the current Eset installation.
I then reinstalled ESSP and imported my previously exported settings. Secure Data was still showing as never setup after settings import completed.
"I again say to thee", yes the OP new system shows that an existing old installation VHD exists on his non-boot SDD. But as far as his current ESSP installation on the new system is concerned, this VHD doesn't exist. It is in effect an "orphaned" VHD. Unless Eset developers can come up with a way to associated this old VHD with the current ESSP installation, it will remain inaccessible.
-
You're talking "apples vs. oranges" here.
SSL/TLS protocol Application scan rules relate to Eset Web Access protection and have nothing to do with the Eset firewall which is related to Eset Network protection.
Eset has posted previously in the forum that users are not to modify SSL/TLS protocol Application scan rules. These are maintained internally by Eset.
-
Based on your TCPView screen shot, you are using both Outlook and Thunderbird e-mail clients. Eset e-mail anti-spam processing only works with Outlook; not with Thunderbird.
As far as the VT detection, it's for localhost port 8080. Eset default firewall rules allow all traffic within computer; i.e. 127.x.x.x.. Check your Windows hosts file to see if has been modified.
-
5 minutes ago, Marcos said:
I've found only these 3, all purchased through the Hong Kong distributor Version2:
Appears OP is referring to the currently active NOD32 license.
Multiple past forum postings all refer to license purchases in U.S. dollars are forwarded to Eset N.A. for payment processing. As such, issues with the purchases must be resolved by Eset N.A..
-
7 hours ago, Guest Branko said:
but this year local EXCLUSIVE distributor in Croatia out of his own reasons refused to send an offer for payment stating "his company can choose with whome they work with"
Are you an Eset partner; i.e. value added retailer (VAR), associated with Eset Croatia LLC? If so, it appears they are terminating their business relationship with you.
-
33 minutes ago, iandev said:
but they said I have to ask the US ESET for a refund of US$118.98
Eset North America handles all Eset license purchases made using U.S. dollars. You can contact them here: https://www.eset.com/us/about/contact/ about this matter.
-
I believe you are referring to this registry key, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run.
Malware will store there malware payload in this key for persistence purposes ensuring the malware always runs at system startup time. The point to note is the malware still exists on your system regardless if present in this registry key.
-
4 hours ago, Skier said:
To emphasise, again: I have Secure Data enabled
Pondering more, there is another possibility here and your not going to like it.
First, a clarification of what the .eed file is. It appears to be the Secure Data executable file. The file is used to access Eset encrypted data on a created VHD or removable drive.
When your old device crashed, so did the VHD and any data on it. Unless you backed up that data to external media prior to the crash, I am afraid it is lost. Or if your very lucky, the data still physically exist on the SDD. But I see nothing in the Eset Secure Data documentation this is the case. Also if the Eset encrypted files from the old system still exist on the SDD, there is no documented procedure on how to link those files to the new Eset VHD created on the new system.
Now if you instead had created Secure Data removable media drive, Eset would have created the data on that drive permanently. This is why it can be accessed again when Eset is reinstalled either on the existing device or a new device.
-
Let's "take it from the top" again starting with the very first statement in Eset Secure Data FAQ;
QuoteESET Secure Data is a new feature available in ESET Smart Security Premium that enables you to create encrypted directories on removable drives to protect against data theft in the event of USB flash drive or laptop loss.
https://support.eset.com/en/kb6266-eset-secure-data-faq#deleteVD
Next is when reviewing Eset product on-line help in regards to Secure Data processing are the repeated references to removable drives,
My take here is Eset never fully designed Secure Data to be deployed on internal HDDs. It does so by creation of a virtual hard drive. My assumption is VHD's are directly linked to the device OS where created. Installing the SSD on a new device/OS no longer has an Eset VHD relationship. Did you create a new Secure Data VHD on the new device specifying this SSD as the source? Also, this might not work in that all that is created is a new empty .eed encrypted folder for the new VHD on the new device I assume.
Also if you exported Eset settings prior to the old system crash that contained Secure Data settings and imported those settings after ESSP installation on the new system, the VHD might have been auto created w/o issue. But again, I am not sure this would have worked.
In any case, I believe you need to create a support request for this one.
-EDIT- Pondering a bit more.
The problem here is a way to replace the newly created empty .eed folder associated with the new Secure Data VHD on the new device with the old existing .eed folder created on your old device. This I have no clue on how to do or even if this is possible.
Secured browser keyboard protection & FireFox - mistyped characters
in ESET Internet Security & ESET Smart Security Premium
Posted
Another solution here is if this issue is not add-on related is to disable the Secure all browsers option in B&PP settings. When you wish to conduct a web based financial transaction, open B&PP secured browser via Eset desktop icon option.