Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

run.exe as malware #3802

Closed
iD4rksid3 opened this issue Oct 14, 2018 · 8 comments
Closed

run.exe as malware #3802

iD4rksid3 opened this issue Oct 14, 2018 · 8 comments

Comments

@iD4rksid3
Copy link

This issue probably have been discussed, my anti-virus (Mcaffe-Livesafe) quarantined the file:
C:\Program Files\Python37\Lib\site-packages\PyInstaller\bootloader\Windows-32bit\run.exe

My first thought is false positive, but by checking the file in Virus total it is marked in 10 different anti-virus engines:
run

My questions:
1- is this file really a malware?

2- if it is safe, is having it missing affect the application?

@melvyn2
Copy link
Contributor

melvyn2 commented Oct 14, 2018

I don't know what is causing this, but I've ran PyInstaller (and therefore, the bootloader) many times without issue, and without any viruses harming anything.

@geolipark
Copy link

I also get same warning for runw.exe in (Windows-32bit) from AhnLab V3 vaccine. But runw.exe in Windows-64bit is fine.

@crwood
Copy link

crwood commented Oct 16, 2018

I just got bit by this as well and can confirm that the 32-bit runw.exe file is currently flagged as malicious by MalwarePatrol:

screenshot_2018-10-16 virustotal

I have no idea what MalwarePatrol is (nor do I have it installed on my testing machine) but it seems as though Windows Defender (with threat definitions updated to version 1.277.1168.0) relies on its signature db and will not allow PyInstaller to be installed via pip as a result. Frustratingly, neither Windows Defender nor pip provides any user-facing indication as to what is going on -- pip just throws an EnvironmentError.

Anyway, disabling Windows Defender's "real-time protection" "fixes" the issue for now, allowing PyInstaller to be installed normally.

@crwood
Copy link

crwood commented Oct 16, 2018

Related/duplicate: #2501.

@htgoebel
Copy link
Member

Please contact you anti-virus vendor. There is nothing we can do about this false positive.

If your anti-virus vendor considers one of the files included in the PyInstaller distribution or a file generated by PyInstaller to be malicious, there is nothing we can do about this. Even if we'd change our code, they'd change their pattern and the race starts again.

See this mailing-list thread and other tickets for his topic.

@kk-hiraskar
Copy link

kk-hiraskar commented Aug 5, 2021

Until last version 4.2 their was no issue for me, just now updated pyinstaller to v4.5 to tryout splash screen feature.
and this file PyInstaller\bootloader\Windows-64bit\runw.exe got quarantined by Cybereason antivirus :-(

image image

Update1:

PyInstaller\bootloader\Windows-64bit\ when I saw this folder it contains three more exe files,
so just as a try out, I copied runw_d.exe as runw.exe, and it worked out and no issues.
But packaged file got increased by few MegaBytes, may be this _d is debug exe which is putting debug data and increasing package size or may be the newer pyinstaller has increased the package size..

Here splash screen worked, however lot of pink noise in the splash image shown

please see what is difference, why runw_d.exe is not quarantined.
and considering same to runw.exe may solve.

Update2:

I downloaded runw.exe, 2 commits earlier as shown below, and it is not quarantined.. wow..
image
then definitely added codes in last 2 commits might have triggered this issue!

with this older runw.exe, splash screen not shown at all, and final package size remained almost same as with Update1

@bwoodsend
Copy link
Member

bwoodsend commented Aug 5, 2021

You're chasing smoke and mirrors I'm afraid. I haven't written it up yet but we've been monitoring the AV detection situation and the results are that they are hopelessly sporadic. One day there are 10 different flavours of malware detection - within days (or sometimes hours) they'll all have gone again. Carry out your experimentations again in a few days and the results will likely be the opposite of what they are now. Unfortunately, these AV engines all share data via a Global Threat Intelligence network so that if one AV engine generates a bogus rule which mislabels our bootloaders as malicious, then the others all join in making it look like 10 different engines have detected malware when in reality one cocked up and 9 decided to join the party and copy the broken one.

There is virtually no difference between the 4 executables we ship. The windowed variants are compiled with a flag to say no console and the debug variants have a few print statements in them. The reasons some perform so much better than others is not because of the contents but where they're used. Generally, if someone somewhere has written genuine malware with PyInstaller then whichever variant of the bootloader they used will be hunted down by these AV engines. If you get a chance to test new bootloaders before they get on PyPI (which I do) you'll see that they all come out clean then the AV detections start popping up over the course of the week after release. So it's not the contents of the files that are the problem - rather it's that people (and likely including malware authors) are using them.

@kk-hiraskar
Copy link

kk-hiraskar commented Aug 6, 2021

Hi @bwoodsend, Thanks for you detailed reply.
Ya I understand the game of Antivirus detection behind the screen and people misusing pyinstaller.

In this scenario runw_d.exe not quarantined but attacked runw.exe, where the difference between these 2 is just some extra debug statements, that's all..

Hope AV engines understands the issue.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 16, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants