Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


zombunny2 last won the day on March 8

zombunny2 had the most liked content!

Community Reputation

19 Good

About zombunny2

  • Rank
    Advanced Member

Recent Profile Visitors

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

  1. Many generic Windows installers can be called from the "run" dialogue (SUPER + R) or from the command prompt with the "/silent" option. It's generally undocumented and support is not universal, but it sometimes works. So, if the Immunet installer is called "setup.exe" and resides in the root of drive D:, you'd hit SUPER+R, and type "D:\setup.exe /silent" in the box, then hit enter/OK. Other commandline options that may get you what you want: /silentinstall or /verysilent or /y I've not tried any of the above but I've seen and used them for various other installers. I'm fairly certain Chocolatey makes use of this trick for most installers, so you may want to see if you can find Immunet's NuGet install script on Chocolatey's web site to see how it calls Immunet's installer. To deploy this on another machine, you'd have a .bat file calling the installer with the correct commandline option, and run that instead of running the installer directly. This does of course sound a bit like you might be managing some sort of commercial deployment, so if this is the case then AMP will suit your needs better and is of course licenced and supported for such scenarios. Sometimes it's worse to use the wrong tool for the job than to just not do the job at all. If something's worth doing, it's worth doing right. If you're doing this for an organisation, just get AMP.
  2. I suspect that adding Adobe's "program files" directory will do little or nothing to alleviate your problem, unless it also uses that location for its cache. Do you know (or know how to find out) where your Adobe software stores all its cache files? Seeing as all the file reading and writing is causing Immunet to repeatedly scan everything as it's read/written, you need to find out the location on this disk where all the reading/writing is taking place. I.e. you need to find the directory that Adobe uses for its cache. If you exclude this directory, you may find that performance returns to normal acceptable levels. Good candidates to watch would be any "Adobe" related folder that resides within %programdata%, or see if Adobe creates an "Adobe" folder within %temp%. In the meantime, you can speed up your systems slightly by de-activating the ClamAV engine, and/or blocking mode - however the former will decrease your offline-protection and the latter will decrease your overall protection. Good luck.
  3. I've just had a look at the Blackmart app description and I'm not surprised Immunet's quarantining it. It's an unofficial app store, so contains code to download other apps - hence might have code similarities to trojan droppers. So could be a false-positive. But there are much bigger concerns with this app: It's worth noting that Blackmart's description says it makes-available cracked versions of premium software. I'd therefore suggest you don't use it as you're far more likely to get a virus or trojan in cracked software and the app-stores that promote such software. Shady developers of cracked apps already have less morals, therefore are more-likely to insert malware to further their own ends. They have no problem stealing from developers, why would they suddenly develop a conscience when faced with the choice of stealing your bank details or uploading your nude selfies to porn sites? They also come into contact with other shady developers and shady apps more often, therefore are more likely to have been compromised themselves, and therefore are more likely to unknowingly be inserting malware into their apps. I'd recommend steering clear. There's no need to ever crack an app when there's almost-always a freeware or free/open-source app with the same functionality. Try to stick to app-stores such as F-Droid (free and open-source), UpToDown (virus-scans their apps and supplies legitimate apps), the /e/ store (legitimate apps) and Aptoide (if you stick to the verified apps and avoid cracked apps, there are a few security checks performed on them). If it's a particular game you want to crack, or something else that you can't really find an equivalent to, make your decision: it's either worth paying-for or it's not worth playing at all.
  4. You're right, an Android .apk will not harm a Windows system, as Windows can't execute an APK by itself, without an Android emulator. However, it's common (and a bit of a courtesy) for virus scanners to detect malware for other platforms - ClamAV, the engine that powers Immunet's offline detection capabilities, wouldn't exist if this wasn't the case, as it was originally developed for Unix-like platforms at a time when viruses for these platforms were simply not observed in the wild. The ability to detect threats in .apk archives is therefore handy for people who sideload apps on to their Android devices using ADB, etc. - Just as scanning a word .doc on your BSD or Linux system helps prevent you passing an infection on to a Windows user when you send it to them. If you don't know where the APK file is coming from, I suspect a web site is dropping it on your computer in an attempt to infect you. Most web exploits used to target Windows, but with the massive amount of Android devices now, as well as the fact that manufacturers stop releasing security-patches for them far too early, this means that there are millions of people browsing the net on insecure Android devices, which makes them a desirable and easy target, much like Windows used to be. One of the web sites you're viewing may have been compromised, (or more likely, the ad network displaying ads on it has been compromised) and it's speculatively dropping an infected apk onto your machine, in the hope you're an Android user who can get infected. Immunet rightly detects the apk and attempts to quarantine it. If the site deletes it before Immunet has had the chance to quarantine it, then quarantine will naturally fail. Also, if Immunet is your secondary protection, your primary protection might neutralise it before Immunet gets the chance, resulting in the "quarantine failed" message. If you have downloaded the APK manually yourself, there's a good chance that the .apk file is compromised and has a trojan in it along with the legitimate program. Sometimes it's a malicious download where someone's compromised a popular app and uploaded it to one of the many download sites - and sometimes it's the developer's fault because they often bundle in telemetry and adware into apps (especially gratis ones). After e-mail, the biggest vector I've ever seen for malware-distribution is the advertising/tracking networks. You can embed an ad in your website or app one day, thinking it's clean - but the ad will be different each time it's viewed, and each time is an opportunity for a malicious ad to get displayed. The ad networks don't care so don't check their own ads before serving them. Again, this will result in a detection from Immunet and a quarantine-failure if either the file is deleted or your primary AV cleans it, before Immunet gets the chance. It might be worth doing a full scan of your system with Immunet, and then another with your primary protection (and/or Windows Defender) to root-out anything stubborn. Don't use your computer until the full scans are all complete, and try to close anything you can that's running in the background before you do the scans (temporarily close/exit any unnecessary tray icons like Skype, your printer software, your Sat Nav updater, iTunes, and so on).
  5. If you are running Immunet in parallel with another AV like Norton, you can safely disable the ClamAV module in Immunet. ClamAV is very CPU-intensive, and you may find that this is the component that's causing the CPU-spike. I personally leave ClamAV enabled, because I often add custom signatures to it - but it does really hammer that CPU. You should also make sure you've gone into Immunet's settings and excluded Symantec/Norton's directories under %programfiles%, %programfiles(x86)% and %programdata% as relevant/necessary. You may also want to add Immunet's folders to Norton's exclusions (these are %programfiles%\Cisco\Immunet, %programfiles%\Immunet, %programdata%\Cisco\Immunet, %programdata%\Immunet if you are running 64-bit). I'd be willing to bet a lot of your trouble is Norton and Immunet scanning each other whenever they do anything. As WilliamKing321 states, updates and things also cause this behaviour. I know when my W10 is running an update because Immunet in particular starts consuming massive resources scanning it all. And seeing as I'm a fairly infrequent Windows user, this is very noticeable every time I have the misfortune of needing to boot that operating-system.
  6. Oh, and by the way, I forgot to mention Ritchie, it goes without saying that all the work you do on these forums is really appreciated. It must be pretty hard as it's probably quite a frustrating and thankless task, but the fact you haven't given up is an absolute godsend to the remaining loyal users! I try my best to help too, but you seem to have super-powers and have usually already solved someone's issue before I've even read their post!
  7. I have done a little more investigating. It seems that on a fresh install, attempting to run an update manually from the gui ("update now") fails if ClamAV is enabled and it's a new, fresh install that hasn't updated before. If you leave it for a while to silently-update, the process then seems to be "fixed" (i.e. works as expected). I've tried on a couple of PCs now. Basically I install Immunet, disable ClamAV, blocking-mode, and ClamAV updates, and leave it for a few minutes. I then re-enable ClamAV and ClamAV updates, and again leave it for a few minutes. Then, triggering an update in the GUI seems to result in the statement that "everything is up to date" - and indeed, checking the ClamAV subfolder within Immunet's program folder, reveals that main.cvd, daily.cvd and bytecode.cvd are all present with a recent timestamp. Finally, I re-enable blocking mode. All seems OK. On a slower machine, you can actually tell when this first automatic update happens in the background, because when ClamAV first verifies/loads the database, it will consume a lot of CPU for a moment, causing the machine to be less responsive, and causing Immunet to appear frozen/not responding for a few seconds to a minute. Then, all is well. I'm not sure why updates were temporarily broken on my older installation though.
  8. Haha thank you Ritchie! I'd of course "like" your posts, but until you mentioned it I didn't even know how you gave other people "likes" on here! Will give it a go on your post. I don't always keep Immunet installed, but I do pop on here occasionally to check on its progress and to help other users as I really want it to succeed. It's lightweight and minimalistic, doesn't require an account in order to use, and optionally uses the ClamAV engine, which I find indispensable as it means I can add custom signatures. TL;DR I really like Immunet when it works, and I don't want to stop using it!
  9. ^^ This is yet another reason why Cisco should provide a dedicated removal tool for Immunet, like most AV vendors do with their own products. AV integrates itself so much into a Losedows system that if anything goes wrong (which it eventually will), a clean-up tool to fix broken installations/uninstallations is an absolute must. I've solved this problem before with both Revo Uninstaller (gratis but proprietary) and BCUninstaller (true "free" software - i.e. released under the GPL3-compatible Apache Licence 2.0). Revo is the older and more well-known, established program. I think BCUninstaller is a bit more rigorous and thorough though. Perhaps try Revo first and see what happens. BTW OP, I can fully sympathise with your girlfriend. I'm very comfortable tinkering and experimenting on any system that's Unix-like, but I the reason I now call that OS from Redmond "Losedows" is because I just find it too fragile and easy to break, and am getting pretty tired of constantly repairing it for both myself and friends/relatives.
  10. Exclusions to do in Immunet's settings: Exclude the entire folder C:\ProgramData\Kaspersky Lab\ or if you want to reduce the amount of excluded content, try excluding C:\ProgramData\Kaspersky Lab\´╗┐AntiRansom4\protected\Bases\Cache\ instead. There is no need to do both, as you see one is just a subfolder of the other. Similarly, you should also exclude Kaspersky's folder within "Program Files" or "Program Files (x86)" as necessary. Exclusions to do within Kaspersky's settings: I have never had a problem with Kaspersky detecting Immunet's updates, but just in case (and to improve performance), go to Kaspersky's settings and exclude C:\Program Files\Immunet\ (or the equivalent in "Program Files (x86)" if you are on 32-bit), and C:\Programdata\Immunet\
  11. Hey Ritchie, Thanks for the suggestion. I did wonder whether I should have created a new topic or just done a "me too" on this one. Sorry I can't post on the announcement topic you link to. Maybe I need to have reached a certain number of posts or reputation before being allowed to post there or something. I seem to remember last time I had this issue, installing via Chocolatey seemed to work at least temporarily. I may try another re-install and will post back if it works. It would be in Cicsco's interests to either fix bugs in Immunet and monitor the forums more closely, or just kill Immunet off completely, once and for all. I have actually been steering my company and others away from considering AMP because of Immunet's relentless bugs, as the two solutions share common code. That in itself is no big loss to Cisco, but if I'm doing that, many others may possibly be doing that too.
  12. I have the same failure - The ClamAV module downloads the database update and then finishes saying it failed to apply the update. This is when performing a manual update via the GUI - no indication is given that it fails when automatic updates are tried, so I have no idea how long this has been going on. This is on any machine I use or administer for friends/family, with Immunet present. Nothing seems to be blocking Immunet updating (e.g. firewalls or other security software). I suspect updates have been silently failing on many users' systems for a long time. Seems to make no difference whether Immunet is the only security solution on the system, or whether it is run in tandem with others (obviously with each included in the others' exclusion lists). As an experiment, I downloaded ClamAV for Windows, and freshclam was able to update with no problem, so it's not a connectivity issue between Immunet/my machine and the ClamAV servers. In fact, from the way the error occurs, it seems to be that the problem is with Immunet actually applying the downloaded update! Maybe Immunet is preventing all writes (including its own) to its program directory?
  13. I presume you weren't trying to install another program at the time? If it just happens randomly, out of the blue, could it perhaps be that your other antivirus is updating at that moment? Perhaps check if it's performing an update when you see this message. When I tried Immunet alongside Bitdefender free a long time ago, I noticed that Immunet always popped-up with a detection of the "Eicar" test file whenever Bitdefender updated. Additionally, it always said it couldn't quarantine the detected file - presumably because Bitdefender had already used and deleted it. I couldn't add it as an exclusion, because it was always a different random-string filename within the temp folder, every time. I didn't want to exclude the whole temp folder, either - so it was an annoyance. These detections look like they're coming from the ClamAV engine, which makes me inclined to think they could be false-positives. Especially as it's always the same signature that's triggering the detection. Another thing that can cause it is your browser's adblocker. I sometimes get a lot of ClamAV false positives like this when my browser's adblocker updates its blocklists - but they are usually in the browser's folder, not the temp folder. You can probably get rid of these messages by disabling the ClamAV module (but leave Ethos and Spero enabled), especially if you have another antivirus program running at the same time. Ethos and Spero detect more than the Clam engine, and the Clam engine is only of use when you're offline. If you're not using another AV in combination with Immunet, then I'd perhaps be a little more concerned about these detections.
  14. Can confirm Ritchie's solution. I've had this issue before. Solved it exactly the same way: I rebooted into Safe Mode (I think I used safe mode with command prompt, but safe mode without networking will probably also work), and used Revo (proprietary freeware) on one occasion, and BCUninstaller (FLOSS) on another. It's a shame the Immunet/AMP developers don't produce a removal/cleanup tool like the other AV vendors do.
  15. By the way, with regards to the error code EX0 or whatever it is... I have issues with these forums in Firefox, Vivaldi, and Icecat (based on Firefox ESR); however these forums work perfectly in the Pale Moon browser (forked from an early version of Firefox, but with security patches and modern web technologies added in).
  • Create New...