About a month ago, I used PyInstaller and Inno Setup to produce an installer for my Python 3 script. My AVG Business Edition AntiVirus just started complaining with today's update that the program has an SCGeneric Trojan Horse in the main .exe file used to start the program (in the folder created by PyInstaller that has all of the Python "guts"). At first I just thought it was a false positive in AVG, but submitting the .exe file to VirusTotal I get this analysis:
https://virustotal.com/en/file/9b0c24a5a90d8e3a12d2e07e3f5e5224869c01732b2c79fd88a8986b8cf30406/analysis/1493881088/
Which shows that 11 out of 61 scanners detect a problem:
TheHacker Trojan/Agent.am
NANO-Antivirus Trojan.Win32.Agent.elyxeb
DrWeb Trojan.Starter.7246
Yandex Trojan.Crypren!52N9f3NgRrY
Jiangmin Trojan.Agent.asnd
SentinelOne (Static ML) static engine - malicious
AVG SCGeneric.KTO
Rising Malware.Generic.5!tfe (thunder:5:ujHAaqkyw6C)
CrowdStrike Falcon (ML) malicious_confidence_93% (D)
Endgame malicious (high confidence) 20170503
Zillya Dropper.Sysn.Win32.5954
Now I can't say that these other scanners are ones that I have heard of before... but still I'm concerned that it is not just AVG giving a false positive.
I have submitted the .exe file in question to AVG for their analysis. Hopefully they will back off on whatever it is that they thought they were trying to detect.
Is there anything else I can do with PyInstaller to make it so that the .exe launcher that it created won't be considered a Trojan?
I was always getting some false positives with PyInstaller from VirusTotal. This is how I fixed it:
PyInstaller comes with pre-compiled bootloader binaries for different OSs. I suggest compile them by yourself on your machine. Make sure everything is consistent on your machine. For Windows 64-bit, install Python 64-bit. Download PyInstaller 64-bit for Windows. Make sure Visual Studio (VS) corresponding to your Python is installed, check below:
https://wiki.python.org/moin/WindowsCompilers
Compile the bootloader of PyInstaller on your machine with VS. It automatically updates the run.exe, runw.exe, run_d.exe, runw_d.exe in DownloadedPyinstallerFolder\PyInstaller\bootloader\Windows-64bit. Check below for more info on how to compile the bootloader:
https://pyinstaller.readthedocs.io/en/stable/bootloader-building.html
At the end, install PyInstaller. Within the PyInstaller directory, run
python setup.py install
I was able to submit the file in question to AVG's "Report a false detection" page, at https://secure.avg.com/submit-sample. I received a response back fairly quickly (I can't remember exactly how long, but it was less than a day) that they had analyzed my file and determined that it did not have a virus. They said that they had adjusted their virus definitions so that it would not trigger a false positive anymore. I updated my definitions and it was still triggering, so I contacted them again with my virus definition version, and I heard back that the version I had wasn't high enough - I think there was some delay on my definitions because I get them from a local server. But within a day I had the right version of the definitions and the false positive didn't trigger anymore.
So if you have a false positive with AVG, I would recommend this solution - fairly quick and easy to get a resolution to the problem.
I puzzled over this question for two days and finally found a problem with my application. The issue was with the application's icon.
Example for tkinter:
root.iconbitmap('./icon.ico')
When I removed this line of code, the false-positive Trojan was gone.
Also, make sure not to use --icon dependency when you are converting your .py file into .exe. Otherwise, this will cause the same false-positive Trojan detection.
I faced same issue for my small document register project code.
My temporary solution was to allow the app in windows defender and
other solution was to use the command pyinstaller filename.py instead of pyinstaller --onefile filename.py.
I dont know if it is correct. But it worked for me.
I searched many blogs for weeks. But I found nothing..
Today I found a way to convert py to exe without any virus errors.
Virus Total Report
So in this method you do not need to send any reports.. Actually It is very simple.
You need to install a module named Nuitka.
python -m pip install nuitka
Then you need to open command from from the file path. And use the command;
python -m nuitka --mingw64 filename.py
And that's all.
You can use the command
nuitka --help
You can find more at - Nuitka Guide
I had this same problem using python 3.8.5 and pyinstaller 4.5.1
In my case the first exe build was accepted by the antivirus (Windows Defender) but subsequent builds were flagged as having a trojan.
I solved it by using the pyinstaller --clean option every time I built the executable
Reverting back to PyInstaller 3.1.1 from 3.4 resolved similar issues on my end (at least temporarily).
As #boogie_bullfrog told, reverting to a previous version could be a solution. However I used *.spec file to store some data (like pictures and icons). I had the latest 3.5 version (August, 2019) and moving to 3.1.1 caused error when app was compiled (probably due to supporting Python 3.7).
So right now the easiest solution is to downgrade to 3.4
It supports specs from pyinstaller 3.5 and the onefile-app wasn't detected by Windows 10 built-in firewall
What I did was to solve this(make exe files non detectable as virus) was to downgrade pyinstaller by typing in cmd: pip install pyinstaller==4.1.0
And by the way it didn't work on 3.4.0 so I just randomly picked that version(4.1) and its pretty good looking so far :>
I'm pretty sure that it works on more than only that one version but that i experienced personally
Recompile and then reinstall your Pyinstaller bootloader manually.
This was a problem I had for a while, and my friend and I figured out this resolution with the help of many others. It almost always works to resolve the issue.
I posted the specific steps on my medium blog. Shared the link below, but the basic steps are as follows
Purge Pyinstaller Files within your Project and Rebuild
Uninstall Pyinstaller
Build a Pyinstaller Bootloader with your Compiler
Install the newly compiled Pyinstaller
Re-build your EXE with Pyinstaller, and make sure it’s not being be flagged as a virus
How to Resolve the Python Pyinstaller False Positive Trojan Virus
Part 1. Manually Compile your Pyinstaller Bootloader
Part 2. Working with Anti-Virus Developer(s)
I had a similar problem with a pyinstaller exe under Windows. Avira put that file into quarantine since it was considered potentially dangerous (due to heuristics, which means that some segments look typical for a virus, but no virus is actually found).
Keep in mind that the exe files you generate yourself are unique (as a consequence, the Avast scanner usually returns a message "you have found a rare file, we are doing a quick test", and delays execution for 15 seconds to perform a more thorough test).
My solution consists of some steps:
I have uploaded the exe to https://www.virustotal.com/gui/home/upload to check it with many scanners. If just one or two are detecting a virus, you should be on the safe side.
In order to make your local virus scanner accept the file, you can manually accept it for your computer, but this does not solve the underlying problem, so on other computers it would still be flagged as a virus.
Therefore I reported the file as false positive to Avira, which can simply be done by sending it by email. Other scanners have similar feedback lines. I got a feedback by email within one day that it is ok, and the scanner on my pc agrees with this now. Hope that this helps with the next iterations of my exe so that it stays clean.
Had the same problem today. Win8.1 would keep flagging .exe as virus. Updated to pyinstaller 5.7.0 but the issue persisted. Uninstalled pyinstaller 5.7.0 and did a fresh install. Strangely, Win8.1 isn't complaining anymore!
I have a simple application using
QT += core gui network webkitwidgets
I've used windeployqt.exe to generate the 32 bits release on my win-10 64 bit computer. When I put the folder on a win-7 64 Bit desktop and double-click the app.exe, it never starts.
I can see it in the task manager, but I can't kill it, and if I try I cannot close the explorer folder in which I double clicked anymore.
I've checked the usual platform, ICU, qwindows.dll, and so on.
http://doc.qt.io/qt-5/windows-deployment.html
EDIT Precisions:
I've compiled with default 32 Bit kit: "build-Test-Desktop_Qt_5_5_1_MinGW_32bit-Release" with "mingw492_32"
I have a package "release" generated by windeployqt.exe using the --webkit switch. I start a command prompt:
> set path=
> set mingw=
Then I make sure that no Qt/Mingw things exists anymore in my environment variables.
I also rename "c:\Qt" into "c:\ __Qt".
I move my release folder on my desktop.
I start release\test.exe ( from the clean path shell )
Everything runs fine! So The release/test.exe has everything it needs without the path/mingw variable.
But as soon as I put the folder on another windows machine ( 7 instead of 10 ) it never starts.
I tried dependency walker. It shows a lot of "API-MS-WIN*.dll" missing...
It even shows much more missing dlls on the "good" machine than on the bad one !!!
Every single "missing dll" on the "bad" target machine is actually in system32 on this machine.
Thanks for advice, every advice is welcome, I'm a bit desperate... :)
Edit
It seems to be related to the machine itself. I have successfully deployed this (very small) app to 2 non developer machine on win7 and win8 respectively. But the above "bad machine" still resits running it...
Edit
The problem seems not to be general but related to this one particular machine. Hence, feel free to close or move to the appropriate forum as it is not related to Qt/windeplyqt. If I figure out a solution, and question is closed, I'll simply add a last edit. Safe Boot and malwarebyte are my next actions.
After a long investigation.
Do not believe dependency walker, it used to be a top notch tool but it is now outdated.
If there is a missing dll, the system will prompt you with "cannot load dll xxx.dll" anyway.
Your best shot in case a soft runs on machine X but not on Machine Y is:
start in safe mode ( run: msconfig --> diagnostic startup )
turn off any antivirus or non microsoft/driver software,
"run as administrator".
If you can run with step 3. Then proceed by elimination:
run without admin rights,
Start anti spyware, etc...
Add appropriate exception to your antivirus if it is the root cause.
If the antivirus is not the root cause, run process monitor on both machines. Then compare, what Failed on one machine and not the other ? Read the windows event log and compare any error messages on both machines.
run sfc /scannow to check disk
run a complete anti spyware scan/ pc-repair tool ( malwarebytes, combofix, ... )
Make sure you really have the very same package on both machines, make sure you are not trying to run an exe on mac OS, make sure your computer is on.
Call the oracle, you are in the matrix...
In my case the problem was Avast and it was solved by adding appropriate exception.
JWrapper support now redirects to StackOverflow, so I'm posting here.
The Windows shortcuts created by JWrapper don't work; they point to a location which doesn't exist; I can verify this by navigating to the directory pointed to in the properties of the shortcut:
C:\Users\jchrist\AppData\Roaming\JWrapper-SampleApp
and seeing that the expected SampleAppWinLauncher.exe isn't there.
I can reproduce this simply with a slight modification of the SampleApp. Open the jwrapper-sampleapp.xml file and copy main virtual app, but give it a different name:
<App>
<Name>SampleApp2</Name>
<LogoPNG>sampleapp/logo.png</LogoPNG>
<MainClass>jwrapper.SampleApp</MainClass>
<Param>one</Param>
<Param>two</Param>
</App>
If you do this, and then run the 32-bit offline installer, you'll get a dialog which allows you to select which of the two virtual apps you want to launch.
After selecting one of the (identical) virtual apps and quiting it, the shortcuts provided in the start menu in the SampleApp folder do not work. If you dig into the properties of the shortcuts, you can see they point to an executable which doesn't exist. (It did exist, but it deletes itself after the first run).
I'm using the latest JWrapper (jwrapper-00036138363.jar, although this problem existed with jwrapper-00035090611.jar) as well.
I've tested this on Windows 7 today and it works OK. I haven't tested this on server 2008 but Windows 7 is treated basically the same as Server 2008 by JWrapper. Also the executable disappearing after the first run is not normal behaviour.
My guess would be that this is antivirus software that is detecting the run as a false positive and deleting the executable. Do you have any AV software installed? can you turn it off to test?
Unfortunately some AV software will delete files etc without any warning.
I am not able to set breakpoint in my program when debugging with CDB while the process is running. When I made a click on the left of the source line to set the break point, I got a red breakpoint with a busy status indicator on top of it. The busy indicator never goes away as expected. If I set a breakpoint prior to starting debugging, they will be applied successfully.
If I select Debug->interrupt from the menu while the process is running, QT Creator is not able to pause the process either. Therefore, I believe the cause of the problem is that QTC is not able to pause the process and apply the breakpoint.
If I use GDB, everything is fine. But I don't like to use GDB due to its much slower compiling speed.
Please check if you have the debugging tools for windows installed on your machine.
http://msdn.microsoft.com/en-us/windows/hardware/gg463009
Check if CDB finds the microsoft symbols.
Go to Tools >> Options >> Debugger
Check if the following path is present in Symbol Paths Text field:
C:\Program Files\Debugging Tools for Windows (x64)
symsrv*symsrv.dll*C:\Users\vish6025\AppData\Local\Temp\symbolcache*http://msdl.microsoft.com/download/symbols
If it's your operating system is 32 bit, You point it to
C:\Program Files\Debugging Tools for Windows
I have developed a Java swing application, then I have deployed it through a .jar package.
I run my application on my PC double-clicking over the .jar file and everything goes fine, everything goes fine from command line (dos prompt) too.
Here my problem.
I have tried to run my app on another PC:
same OS (Windows XP)
same JRE (1.6.0_U13)
but Oracle JInitiator 1.3.1.18 installed (this is the only difference with my PC)
The app works fine only from command line, but not from gui!
Double-clicking over the .jar file I get this error:
`Could not find the main class. program will exit!`
Can this error be due to some conflict between JRE and JInitiator?
Does anybody had the same trouble?
Thanks
edit:
executing .jar files from gui is associated to the "javaw" command
It is probably a conflict with JInit, which changes the association between jar files and the java command used to launch them.
See this thread.
Re-installed java and the problem has gone away.
A quick description might be - jinitiator installs as a fully implemented JRE with some additional features for cached downloads when dealing with applets.
As all the JRE installers I've seen lately do, regardless of if they are new or old, they replace several entries in the registry to become the active JRE. Whatever you installed last will be run unless you provide a full path to java.exe or change the registry to re point at a different JRE.
examine:
HKEY_CLASSES_ROOT\jarfile\shell\open\command
and see if the path to javaw.exe is correct. (or even included)
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App
Paths\java.exe and javaw.exe and javaws.exe to check the path there also.
Have you checked your PATH/CLASSPATH/JAVA_PATH variables. It is possible that Jinitiator has installed the wrong version at the front.
Possibly check your manifest entries. See if the MANIFEST.MF in the jar contains the Main-Class attribute set correctly to the class that is supposed to be invoked, if not try setting it.