Jump to content


  • Posts

  • Joined

  • Last visited

About denixx

  • Rank

Profile Information

  • Location

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi, @Marcos. There is also something like Spindump. Would it be more effective to make this one? This evening I also found esets_proxy hanging on with 200% CPU usage. Usually this MacBook goes crazy if this happens so I could take a closer look at it if this would happen again. Thank you.
  2. Hi, Marcos! Looks like it is working now, thanks! I would test for couple of days, but even now it looks good with Chrome Unstable 83.0.4103.7 dev (64-bit). No flickering, no crashes. Thank you!
  3. Opened link to virustotal again just now, and seeing only 6 of AVs for now. Looks like Fortinet is not in that list today. What is WD? Looks like it is not in list too.
  4. https://www.virustotal.com/gui/file/8609b4f0effc79fa667cad6ae7b822329abcbce4850bb580ce8d8a8f38736477/detection
  5. But if I launch the scan, mobile ESET says this extracted apk is unwanted.
  6. Also, if I extract the apk to sdcard, and send it to my PC, ESET Smart Security Premium is not seeing apk-file as something bad, it says file is OK.
  7. Hi! I'm here to ask about detected application. It's "EWPE Smart", available in Play Store: https://play.google.com/store/apps/details?id=com.gree.ewpesmart This app is used to control the air conditioners (thru AC WiFi modules), at least my Cooper&Hunter AC may be controlled by this app. ESET Mobile Security detected Android/Packed.Jiagu.D in it (/data/app/com.gree.ewpesmart-blablabla/base.apk) and set it to "potentially unwanted app" category. Should I inform someone (from Cooper&Hunter, maybe) about this issue, or this could be normal for this app? I did some easy search, and found someone posted about another app with this issue: (it's better to look the full thread) He says "it's just a packer". So, if this is kinda "manufacturer recommended app" - what I am supposed to do? Thank you!
  8. Strange thing, if I remove NOD32, all works flawlessly. Currently I'm on Chrome-dev 81.0.4021.2
  9. My bad, I not checked that information. I could see this statement somewhere briefly, that "Chromium is not affected", and made additional conclusion from what Craig posted in Google Chrome Community because they say "we are testing new feature".
  10. Reporting: "--disable-features=RendererCodeIntegrity" is not working in Chrome @ Arch Linux. But, "--no-sandbox" is working, BUT PEOPLE, DON'T USE IT, THIS IS A BAD PARAMETER! I removed NOD32 again and would check some news from Marcos.
  11. Thank you! Yep. They named it "Renderer Code Integrity". I found this via search: https://9to5google.com/2019/10/29/google-chrome-78-aw-snap-crash-windows/ "With Chrome 78, Google introduced a Windows 10 specific feature called “renderer code integrity,” which is designed to prevent unsigned code from taking control of Chrome’s page rendering processes. Generally speaking, this was designed to stop most viruses from being able to change the way Chrome’s pages load." Does it mean that, libesets_pac.so is not signed? Does it mean that simple "signaturing" of this lib will fix a problem? Is that available under linuxes? Should Google turn this feature off for linuxes? I could see libesets_pac.so in stacktraces of chrome crashes in journalctl ( https://www.dropbox.com/s/j6rqlinuik612nq/google_chrome_unstable_flickering_and_crash.txt?dl=0 )
  • Create New...