-
Posts
361 -
Joined
-
Days Won
3
0xDEADBEEF last won the day on June 5 2018
0xDEADBEEF had the most liked content!
About 0xDEADBEEF
-
Rank
Newbie
Profile Information
-
Location
USA
-
🤣🤣 🤣
-
this looks interesting...
-
0xDEADBEEF reacted to a post in a topic: game driver FP
-
I feel many open sandboxs' malicious rule matchers are dumb. You can throw in a slightly modified ccleaner and it will also trigger many "malicious behaviors". Here it is just the driver file that gets detected by the scanner. The original installer is just a game downloader, after you install the downloader and download the game, the driver will be released to the installation directory and get quarantined by the scanner. There are indeed "legitimate" drivers using weird ways to achieve some questionable goals, and sometimes those even make system vulnerable to rootkit infection. I am not sure what's the issue in this file though.
-
0xDEADBEEF reacted to a post in a topic: game driver FP
-
Decided to post here because this has already been reported to the eset's lab email for several days but it has not been processed (or at least, the FP is still there). password: "infected" the driver is from the installer downloaded here: https://honkaiimpact3.mihoyo.com/asia/en-us sample.zip
-
Yes, so if I empty the quarantine, re-add 1~2 malware to it, and open the quarantine in egui, the UAC prompt won't happen. That's valid, but still certain cases will have output encrypted files quarantined (usually if detected by AMS and failed to clean the main process). Just want to see ESET being robust in handling such extreme but possible cases.
-
not necessarily. It is not the first time that I saw ESET move thousands filecoder encrypted files to the quarantine, and those can exceed GBs (and users definitely don't want to empty the quarantine in this case). In other cases I once saw that the ransomware may repeatedly release thousands of ransomnotes because ESET repeatedly move it to the quarantine. In such case the quarantine will be "broken" unless the user manually empty that directory. I think the bottom line is to add a load progress bar so that users are not confused. Plus I don't think repeatedly prompting UAC is considered "normal" when handling a large number of entries/large files.
-
I have found a way to reproduce this issue. After emptying the C:\Users\%user%\AppData\Local\ESET\ESET Security\Quarantine, the quarantine page is back to normal. After re-copying the quarantine files back, the same UAC issue appeared. I have sent you a private message containing those quarantine files. I hope those can help the devs identify the bug. Previously I've heard similar complaints about "bugs" in quarantine and log files: when there are too many entries in these sections, using egui to view them will display blank page. The solution is to empty them.... In this case, my quarantine is pretty large (> 2GB). I feel the QA may need to do some tests to cover such extreme cases.
-
my bad.. this is actually set to "prompt for credential" Turning this two options back to default didn't help though...
-
Yes, I am using admin account. This is the weird part. The only non default setting on my computer: 1) UAC level is set to the highest 2) Local security policy - UAC Behavior of the elevation prompt for administrators in Admin Approval Mode is set to "Prompt for credentials" But I don't think these two will cause this issue.
-
System: Windows 10 Pro x64 EES Version: 7.2.2055 When trying to access the quarantine, a UAC prompt will show up (eecInt.exe). However, after granting the UAC elevation request, the quarantine page is still blank. Meanwhile the UAC elevation will prompt indefinitely. Not sure what kind of diagnostic info I should provide to help debug this issue.
-
theoretically ESET should have update/livegrid servers in the "wall". So I guess this is more of a routing logic issue within the product. Previously users there try to modify host to force redirect the update server to the local ones. However I believe this had better be eventually fixed by ESET...
-
It is about ISP connectivity. The update can work but with high chance of failure during the download process. This issue has been there for some mainland Chinese users with certain ISPs for years. I've heard numerous users there in the past complained that they had difficulty updating the virus db (the download being extremely slow or the download failed in the middle) or connecting to Livegrid. That's why I am providing the network dump here.
-
Someone encountered BSOD potentially induced by ESET. When download files in the virtual machine, the BSOD occurs after some time. After turning EIS monitoring off, the BSOD won't happen. The dump is attached here dump.zip