[BUG] Multirow Installer is flagged by norton as a virus

[KhurramFHassan]

I am unable to run version 1.4.2 as norton flags it as a heuristic virus and does not let me run it.

[Izheil]

It indeed seems like some antiviruses do detect it as a virus or a trojan in Virustotal. I assume it's because it needs to ask for root permission and writes some files to program files (We need to patch Firefox installation folder with 2 files to allow the use of external JS for Multi-row).

There isn't much I can do about it, but if you are worried you can check the code on the installers folder to make sure there is nothing shady going on.

Running Quantum-Nox-Installer.py with python is the same as running the .exe installer (for the exe we use the builder.py file, which is the same as Quantum-Nox-Installer.py, except that it changes the python libraries to a temporary folder to be able to be run as an exe without the users needing to have Python installed).

I'll add a note about this in the releases section.

If you still want to install it, you will have to either temporally deactivate norton to use it, or send it to norton for them to flag it as safe (if it gives you that option), or do the manual installation, which is what the installer does automatically, and then copy the multirow or any other function you want to your chrome folder.

[jon-joy-1999]

Windows Defender Antivirus flagged Multirow-Patcher-Quantum-Nox-Installer-Win-1.4.2.exe as Trojan:Win32/Wacatac.C!ml . I saw this thread and then submitted the file to Microsoft. This is their response:

multirow-patcher-quantum-nox-installer-win-1.4.2.exe Submission ID: b81f377e-a473-4bb0-a141-a6b3ae84e235 Status: Completed Sat, Mar 14 2020 11:17:53 PM Submitted by: g*[email protected] Submitted: Mar 14, 2020 8:48:14 PM User Opinion: Incorrect detection Analyst comments: The file is not malware and we cannot reproduce any detection on the file.

[Izheil]

So I tried some modifications on the installer to see if it was due to the needing root, or having the link to the repository (The "view repository" button), and tried passing it to virustotal, but it still flagged it.

I looked around to see if other people had issues with pyinstaller executables (which is what I use to make an executable out of the python patcher files), and it seems that it's actually an issue of pyinstaller bootloader, as can be seen with other people reporting it here or here.

It doesn't seem like pyinstaller mantainers can do much about it for what they say in those issues, apart from reporting it to the AV vendors, and since Pyinstaller is also open source, we could know if there was malware in it.

Since some of those issues are from version 3.5 and I'm using 3.6 (the lastest), I checked with a simple python file to see if it would detect even a file with just print("hello world"), and it still flagged it (so it's most certainly a problem with some AV vendors giving false positives to pyinstaller executables).

I can try sending the installer to the AV vendors that give false positives to see if they can fix their heuristics, but if this issue has been longstanding with pyinstaller so far, (and considering it flags ANY pyinstaller file), I doubt it will help much.

[Izheil]

So I found out that it's possible to get less AV's panicking over nothing if using your own self-compiled bootloader for pyinstaller, so I tested it out.

This is version 1.7.5 with the pre-compiled bootloader that pyinstaller provides (11 detections, including "Microsoft", which is Windows defender).

This is version 1.7.5 with the self-compiled bootloader, with only 2 detections, which are 2 kinda unknown AVs that I don't think that many people even know or use.

Ironically enough, "Fortinet" AV doesn't detect the pre-compiled version, but detects the self-compiled one for some reason.

I think this is as good as it's going to get, since even official programs get flagged there by a few AVs sometimes (specially after big changes).

Either way, Norton (which was the main problem of this bug) doesn't seem to detect it with the self-compiled version, and neither does Windows defender (which is the most common one), so hopefully this should solve the AVs problem.

If anyone can confirm that 1.7.5-rev2 version doesn't get flagged by at least Windows defender, I could close this bug (WD won't detect it on mine since it's created on the same computer).

[pauby]

The latest 1.7.9-rev1.exe is being detected by Windows Defender as Win32/Zpevdo.B trojan on the desktop and Trojan:Win32/CryptInject!ml in VirusTotal.

[Izheil]

I updated the dependencies and rebuilt the bootloader on 1.7.9-rev2, so it should now be fine on WD.

[dlc2001]

Just FYI, WD is at it again, version 1.7.13 is coming up as Trojan:Win32/Zpevdo.B

[Izheil]

I sent it to VT, and I only see the usual unknown AV's detecting it, with Microsoft one not detecting it. I also sent it to Hybrid Analysis which combines a few detectors along with VT ones, and it didn't seem to get anything apart from those few non-relevant VT ones...

I haven't changed the version of Python since 1.7.9-rev2, so it's still using the self-built bootloader, which to my knowledge is the only way to paliate the random detections that appear on VT from pyinstaller freezing, so I'm not sure what could be causing it on Defender.

Either way, I sent the file to Microsoft stating that it was a false positive caused by Pyinstaller, so hopefully it won't be detected in the future (at least until a new version is released, seeing that I already sent a previous version to them time ago... but that was back when I hadn't rebuilt the bootloader).

[dlc2001]

Weird that the MS one on VT is not detecting. This is what I'm getting, in case you need it. My Defender updates are current. Anyway, you sent it to MS, they'll either fix it or they won't ‾_(ツ)_/‾

[Izheil]

I assume VT doesn't use the lastest version of all providers in their analysis, but I can't do much else to fix WD issue at the moment.

Now that I know some Java and C#, I'll probably end up rewritting the installer in either of those languages using GTK once I have the extension ready, since at least a quick search doesn't seem to indicate that binaries created with non-Python languages have these kind of AV issues, and at least GTK will make the window look more native... but until then, I'll just add a note on the releases section again warning about the false positives.