Inno Setup is Flagged as Trojan?
-
Can you release JUCE/HISE code under the MIT license without paying a license fee?
You can of course publish your code (the installer code you write) under the MIT license, but it doesn't change the GPL license of HISE / JUCE, so the entire installer is still required to be licensed under the GPL license (or the proprietary one). Shouldn't make a big difference though because it mirrors exactly the licensing scheme that you're about to use for your plugins.
I'm thinking of having a very generic installer that works for all. Server interfacing, if necessary, is then up to each individual project to be done from inside the plugin.
But guys, Occam's razor anyone? If the problem is that InnoSetup is throwing false positive virus warnings, then you should either address that or ignore it (Just threw the last UNSIGNED installer I built over to VirusTotal and it flagged it with 6 / 77 with the 6 idiots probably complaining about unsigned state. If I rename it to setup.exe then it already gets flagged by 7/77 so there is one virus scanner that really does
if(name == setup.exe) then return true
).Making a custom installer will just shift the problem to you (and I don't see any reason why a custom installer would go through the detection while an InnoSetup installer doesn't). Plus you get the additional workload of ensuring a seemless installation procedure covering all use cases.
Now if you want to streamline the customer experience, then it's another thing. I've recently built a content installer app with JUCE that I'm packaging with a macOS .dmg image because Packages completely failed to detect the LinkOSX file and use that as default installation directory (which is important if you want to ship expansions). I'm happy to generalize that app and put it in the repository, but I'm pretty confident it won't solve the initial problem of this post.
-
@Christoph-Hart said in Inno Setup is Flagged as Trojan?:
I don't see any reason why a custom installer would go through the detection while an InnoSetup installer doesn't
In the case of Rhapsody it's already codesigned on Windows and installed on a 1000+ systems. But yeah I think a generic exe is going to have issues.
-
@Christoph-Hart said in Inno Setup is Flagged as Trojan?:
probably complaining about unsigned state.
Yeah, that's the thing, I'm looking to see if there's a way around having to pay the cartels for everyone looking to deliver a good install experience for their HISE project on Windows, no matter how small.
To my knowledge there's no way around it on Mac. DAWs won't even load an unsigned VST3/AU, right?
Here's a zip as it would be delivered to the end user. This is a mock product for Windows, the setup doesn't actually work yet, it can only create folders in the target directory after you click Install. I haven't figured out how to script a .exe directory-relative file lookup.
https://www.mediafire.com/file/gjds9ezo27ia323/HISE_Plugin.zip/file
HISE Project:
HiseSnippet 2550.3ocyZ80aabbD+njOGS13zjfTf9RA1RTDPUqRSJ+u.K3Z8OJa1p+PHRE6TmTgU2sjbqOdKwc6IY1B+sneJ7S8iPQepeS5q449R5L6dGu8NdTVV0xxBFgbmclY+syL6LyxMcBDNrvPQfUox8lLlYU5Ss6NwWNbygTtuU6srJsncWqMlLlFFxbsJUZwmfSTp70rT+8iOdCpG02gkRxx5aEbG1N7QbYJ0Nq8G4ddaScY83iL39tq01Q3uovSDEfKVCqwTmWRGv1ihrsfsUoq2xkKEAckTIKzpj8FB2IcGJN0Wy+2xC4G6wvAMs5BJRSdagmKhXj59mvBNgyNMkVCKqMGx8b6jX.Bs.M2I0brn1b7U16xc4SomZV9b0DjTILsQkVHKjWLCjaZB4FFPt.HUx.RWSCouvtqS.erLcFDO+L619RVPeJ3JLghlWqE9O+B6J291O5p5uJU7A+YH3aYjCaW4uUoL30Ckjm0dqdOk7HRyFMZrZBwm1p8SdZOf58TDSHu89606nts+SsNZS3aGr+Nnb2c0Ymty58dpgbcasSqM6czFG1q296cTxJtKUNrdfHx2s1gsqqo9aIMp+MKsZwB97rBkJ0uC1Q0KXQV51qLOc8cy.f38Lhf6MOo1Y8MZsyQ6u81caorNygsCvuO0FdmFygsobLeou0YAfaMqCwvn2dut8VemcNuV8lo64bRd1l8hVlL18bLblF9GLWwlqkOGey0zmiuKWaOrT8NrarDuMK+8Mh1Lky3PXwL7VNOLCFxdbvb5bNkYbY2ZNluacVtIXsdckJaJfrh9x5inujsc.LXZVxo3cYxzn.Plq1jjmPCHhPvbzxe.2mUe.Ste2Z.rvIFGH9KLGYlY6no01uu.YSwmjF.yrEO.lPDLQsmHxg7PReO5.B7YHSRDPQafJiDExBHNCo9CXgJBtr9zHOIgCNJpmGwMQSnd.tcIRAPLbrGchR.GwnwT+IDLEOHkh1wzPFYL3TQgngjSYflfOAQcBXPYQfKpjzGqHGP38mtZH7fcfDVlS4xghHoFbb+AZzwCT6RmnPoXzzcIXU5S8BY5cKc7XluKIL533E.VVtOWxodIHuBrl0Pa8iHUeV68ptDVTJmoCT51bOV2IgR1HzbqZfHnlAw0GO1i6PkbHrVGxckF.A6croinPxNziYdUzm1P6UnhrhJrsRNWPccUjpU0X9pKOyI3mOKouC1tIpITEINlEH4rP3b1n+P282KuNQCbUI6UxpOjTs5xvfgL9fg3v75VebDY4TtqbXAbnO5BL.wLhS2D9uGC8MFhpdcHJJkvxUd8U9wZzqv7vyt5.HxFQRov2z6nlNd1LtmNTek6wfgX+S1tSJf14wCkUsYbQaNTHBYIGLUg3o4BfStADZjKWPBoiF6wBe3rtzB52HuOc11ldGbplnG2g6JfzSIbUqejuCB5ZrS.Kf57MdlWMp9Hj0CGS95ulnILg76IXMgY6x7VyBzLEZVpRYP0kMRJbbf3zP11hfoYRpkKyxxjonCLofFTpPgOd3Vr9P5cW0LH.gOqCTmpKbEiEn7roAkAQPVPbtYylAZROUFKW.aLbsFY6QiXtbH0rGrDqBLgb9Z0Gn0t7qK1n2Ak8.HOMf4Ta9.k8FCsov59Br7Cl.sV0WUcokIoCmXN7YXfQMCBOUEMUaoeXUstFA6Hn.yiHqnuXv.D.aCg30ptd.jbWexXFW3RJlw5Btt4pV0m3KjwESTrbLygBgFPgNrhitVUpITOVWmj5Hif5IwUXfCGXEFTiNPDHT9BJugrkT2Iu2.thFef+HH1Su2vhkckA3p9n7LWWJzSUq51Qddc.VqtDDXV86+9pvG0xGE7XHAK4gIcLTeS8VdpDvmISE2.AdaakQJKRTND.NCPmgAoZorrTpiPeK9ZMdU+9T0e3bCp6FPOccOXuxb6AoVpk57UYZ.28KZrLA9G8Eq7CE6.AxUc.KU.ysZwJMEPf5zgIEqp21wYCXL2lyQ33w5KMvxAfQrFtOtDWS7RReTTLqcbuZyTFKoIthpfEOm9HZ9K4UDwyQ4qTcd1MWT38GxUJpnqR9NTKJFJWxkgNqK7DWGBUd9zGCogOKfKYq6f+jQ5BHSK37qyk8XIxrENxqvb4EqkOSypphGWb8XjVZIUEKiVIQSbbtC3bX2H0dpOjVbRR7Gyst5nITxpbYFbq.Rx9ctpo2voc5.Iy8YLW3NKnICRyi5W0uClNWuCRaDxXklVhzHV3CU0wOBRAWMN3rpVaWnfXCDL+eZkhgx4HC76gENNGbhmDJ6umPx12ulxiB2+ijep98KbNLyVf.i1JbZ7WIO3rDrlezniYAKC4c8hXSYzpz0Nqet7ly6mK2Qmn0fQgeanyk8gKRqGO6uNsUb1Y3aG1dKpjh+f0wzRyVCz1hcB2go+4qKauEK7kRwXPqX1BgOpgR2Ppl8lI+31XMCKtqUoOy1rgSqWA6nRtvJNA+x+E9R17yVk941YxOaoRwiLSVzxRWT.Pw0aF+XE3A.qRqX+tdaGb2OOzqxunP+MsMx3nA++NA7+8RIq9B1on74KXhxULPYxijT95u4Mu4mTjOOFvx1w6I8x+uJEu7+4BWdzzNqQ5sYisl8YJ9b6cEtQfgL6qlfOeT7DfENySUf+zb9gb4DymW581Sobdg3WX2gKcFVLFWn.LBA8WFXL9Antocq98gfvT.dM6se9kyqMYt7+J8x+k1PS0L5Hnu5tp.e8qMUwNdTy2GuM33y8aC1If4Intc4+UC19mqsQDXiBxR8erlZoVG5vxOyZEi7CXigVO.2rgL2XsCN3IAhnw4k5GerJnnW.DsClByI12mA1Zo4dby.AzPBrcT5JzbpNQP2CtlTN.56KHLKs8hFA9ae3DLl.uTILAaHC8ubmcovsbdkI2pUoQOpxGCmkUiala7J4Fembiuatw2K236ma7CRGqMn6RGiQFeh98imoLzmb9JCAZQk4xfyM3CltBZJYygXv5TCuBbFuQbAur50urdr2qc9N9Y99zW7rUWgITy71zkSvXWN5pZ4eBbPEnfX7KgJ9pWTHgZ1jF6J7EiGJ74NYOV.g4CFvBLwdgan0kR3TYJkuZsCfFFngFmq+MqsCz9MMH6o82IaQy242ouP+0uzVCWBloi7+ie6CZX1YVTbwyUQw2638hWf7Cpo6yhKUhuKSf7ib+7mZqRtSvZwWUPUeY4AI04rghgcgF.bXlkDW.KypG2.Gi.pKy2UM3mf+hmrYR8SbxlISZ4jnJXuE+c08WJsHyGKcn50yCpL6YFRGBsYfPBp48AAkinNAhibz22Cw5MTT.T5q9eNpx16hiIMsT2AzDpif5UG43jUUyH3JWTAuyEUv6dQE7dWTAu+EUvGbQE7ad6BhsSrdjTLRmL0xZ2NszAfkZMM.bQq+GPpwbEu
The plugin is the exact same app with an added sampler that plays samples in the C4 octave, then exported as VSTi instead of Standalone.
This is supposed to demonstrate the user flow for an individual plugin delivery that isn't part of an ecosystem, doesn't require additional downloaders etc. It's buy, download, unzip, install.
This is how the whole zip scans:
https://www.virustotal.com/gui/file-analysis/YWZiOWI2ODZkODVjZTZiMzY3MjAzMDFmNjY0ZjQ0ZTg6MTcwNDMwNTUxNw==I renamed the file to setup_win64.exe. This is how it scans.
https://www.virustotal.com/gui/file-analysis/MjBkOWJhMDRiMmY1ZDNlZmY1NTk1YjlkNGJhM2UyZTc6MTcwNDMwNTYxMg== -
@Lindon said in Inno Setup is Flagged as Trojan?:
@Oli-Ullmann said in Inno Setup is Flagged as Trojan?:
@Lindon
Many thanks for the information! Can you tell me where I can do this? In the HISE Preferences?if I remember correctly its in projuicer
All right, thanks to you. I'll see if I can find it. Normally I never touch Projucer as I compile the plug-ins directly from HISE.
-
Yeah, that's the thing, I'm looking to see if there's a way around having to pay the cartels for everyone looking to deliver a good install experience for their HISE project on Windows, no matter how small.
To my knowledge there's no way around it on Mac. DAWs won't even load an unsigned VST3/AU, right?
So you want to have one installer app that is basically a glorified WinRAR with the additional bonus that it writes the LinkOSX file and then have this compiled and codesigned once?
That still leaves the standalones unsigned and having the installer to point to an archive that will be extracted might be too complicated for the end user who can't be trusted for more than double clicking on the installer and clicking Next until the problem goes away.
And yes, on macOS you need to codesign and notarize (urgh) the plugins, but this is just what it takes on the platform, so there's absolutely no alternative except for sucking it up and spending 1-2 miserable days learning that process. At least on Windows you have the option of not giving any f***s and tell your customers to just ignore that defender popup.
-
@Christoph-Hart Well pretty much, yes. I think even winrar is too fancy. Plugins are pretty simple. What I need could be done with a .bat file.
This would extract the Plugins.zip to the VST3 folderinstall_plugins.zip
Samples would then be packaged into a self-extracting archive, and after extraction is done, another batch, residing with them, would run, and register its current directory into LinkWindows.
register_sample_directory.zipExcept that's not very pretty and unfortunately "pretty" is all the rage these days.
I'm proposing a simple, not-scary-looking (no console windows popping) installation experience on Windows where small devs don't get strong armed into paying money to certification cartels just so their glorified win-rar installers don't get flagged as viruses. A self-contained, preservable software release, like any GOG game if you ever purchased it there.
Smart screen isn't much of an issue. It has a score for each app and after enough users go through with the installation, it will whitelist the .exe. I have never seen a smart screen from HISE standalones.
My worry that started this thread is the virus flags even on empty installers.
I've installed a bunch of software, especially distributed releases from github, that weren't signed. But none of them popped up as viruses on VirusTotal, nevermind MS Defender. Also, you can always self-sign the thing. Take the pre-built HISE release from GitHub, for example. The file itself triggers the smart screen for me, but not if I self-sign it. Self-signing an inno setup.exe still flags it as virus for 7 vendors, one of them microsoft. It won't even let me COMPILE THE INSTALLER on my w10 laptop.As we've seen in the scans above, HISE Standalone output scans fine. If we have a generic installer that's the exact same app that each dev can ship with their release, then the smart screen won't be an issue either. For it to work that way, there needs to be an agreed upon way of distributing and handling strings.
I've proposed a settings.config file (probably JSON, right? I haven't yet gotten to importing data from external files into a HISE app at runtime) where the developer could enter the company name and product name which would be used to set the default path and folder names in the installer itself.
The installer would then do its work on the Plugins.zip, just like the batch above (I haven't written anything for aax or dll but that's a given). It would also do its work on the Samples.zip.
So no pointing to the samples folder. That's why I'm asking about how to get the "current .exe directory" to save to a File object, so I can use that relative path to run .extractZipFile on the Samples.zip which is by default in the same folder as the setup.exe.
Again, this is Windows only, as macOS needs signing anyway and as such you can use the installers there.
-
@aaronventure said in Inno Setup is Flagged as Trojan?:
I've proposed a settings.config file (probably JSON, right? I haven't yet gotten to importing data from external files into a HISE app at runtime) where the developer could enter the company name and product name which would be used to set the default path and folder names in the installer itself.
Ok so as you may have seen at least two of us (Dave and me) have built this sort of thing, and my experience is:
- yes an exe tends to do better early on with the virus protection programs
- if you are looking to get past "the cartels" for the signing - then the exe (as Christoph pointed out) doesnt solved your problem
- your settings.config is too simplistic: there's a range of files that may need to be downloaded and installed in a range of places, fixing the Samples install and LinkFile set up is not the end of what will be required in a generic one-installer-for-all-apps installer. In fact an external settings.config file breaks your model immediately - as the user now needs to download the installer AND the config file...and make sure the config.file is in the correct location. I resolved this by using a config.js include file in the source code that uses the manifest I posted yesterday. Now its all in the installer, but your developer friends will need the source code and will need to edit it for their product.
- your massive re-startable zip download is too big, as pointed out here and elsewhere the File.extractZipFile() gets unreliable for zips over 2GB
- windows only is a bit pointless once you've gone to all this extra effort to then ignore it on the mac platform is a bit of a waste...and all the dmg/packages systems I've tried are "not great" at doing dynamic installs (i.e. where to put the samples).
The installer would then do its work on the Plugins.zip, just like the batch above (I haven't written anything for aax or dll but that's a given). It would also do its work on the Samples.zip.
So no pointing to the samples folder. That's why I'm asking about how to get the "current .exe directory" to save to a File object, so I can use that relative path to run .extractZipFile on the Samples.zip which is by default in the same folder as the setup.exe.
Again, this is Windows only, as macOS needs signing anyway and as such you can use the installers there.
So to be clear the next version of the stand-alone installer, its already added into the "install from inside the plugin" version, will work like this;
- user downloads the installer zip
- user unzips this and runs MyProductInstaller.exe
- The installer does what ever authentication and validation at this point if you want it
- User agrees to the EULA
- The installer downloads a number of archives(actually just zip files) to the users download folder
- The installer asks where the user wants to put the samples
- The installer goes through each archive, checks the internal manifest for where these need to be placed, and unzips them, and adds/modifies the LinkFile
- Installer cleans up the download folder(if the user wants)
Note: this does not overcome any certification issue you might have on windows, and it might not pass every virus scanning software in the world.
Feel free to adapt/change use this workflow if you like.
-
@Lindon said in Inno Setup is Flagged as Trojan?:
yes an exe tends to do better early on with the virus protection programs
if you are looking to get past "the cartels" for the signing - then the exe (as Christoph pointed out) doesnt solved your problem
your settings.config is too simplistic: there's a range of files that may need to be downloaded and installed in a range of places, fixing the Samples install and LinkFile set up is not the end of what will be required in a generic one-installer-for-all-apps installer. In fact an external settings.config file breaks your model immediately - as the user now needs to download the installer AND the config file...and make sure the config.file is in the correct location. I resolved this by using a config.js include file in the source code that uses the manifest I posted yesterday. Now its all in the installer, but your developer friends will need the source code and will need to edit it for their product.
your massive re-startable zip download is too big, as pointed out here and elsewhere the File.extractZipFile() gets unreliable for zips over 2GB
windows only is a bit pointless once you've gone to all this extra effort to then ignore it on the mac platform is a bit of a waste...and all the dmg/packages systems I've tried are "not great" at doing dynamic installs (i.e. where to put the samples).I wouldn't have any downloading from the plugin. The idea is to allow distribution of complete products in a single (or split up) zip. I doubt small devs will want to go through the trouble of setting all that up. You can then simply distribute it via the built-in order fulfillment on gumroad etc whatever.
I linked an example how a delivered zip looks like above, here it is: https://www.mediafire.com/file/gjds9ezo27ia323/HISE_Plugin.zip/file
It just doesn't extract anything because I can't point it to "the folder it resides in" in order to do any extraction, there's no constant for that in HISE, but the concept is there.
No worries about putting things in the right place, everything is in the right place from the start, you just unzip the thing manually (or the browser does it for you, like David pointed out).
If the settings file is a problem, the script can then be plugged into an existing project (just create a new .xml save within the project, it will simply read project data and use the correct company name, project name and version) and exported immediatelly. It's the same app, albeit with a different name and hash, so I don't know how much of a difference it'll make for smart screen.
@Lindon said in Inno Setup is Flagged as Trojan?:
File.extractZipFile() gets unreliable for zips over 2GB
This would just be for the Samples.zip included in the downloaded zip. I wrote a batch script that reads the Samples folder and keeps adding .chx files to a zip called Samples1.zip until it reaches 2GB, then moves onto Samples2.zip etc.
The installer would then simply find all the zip files containing the string
Samples
like you said and loop through them one by one.@Lindon said in Inno Setup is Flagged as Trojan?:
windows only is a bit pointless once you've gone to all this extra effort to then ignore it on the mac platform is a bit of a waste...and all the dmg/packages systems I've tried are "not great" at doing dynamic installs (i.e. where to put the samples).
That's a good point, if I'm signing on mac, might as well use the installer that I already have.
-
@aaronventure said in Inno Setup is Flagged as Trojan?:
It just doesn't extract anything because I can't point it to "the folder it resides in" in order to do any extraction, there's no constant for that in HISE, but the concept is there.
If you really want to go ahead with this, I recommend bypassing HISE completely and write a little JUCE app for that. There's no point compiling a standalone app that renders audio and blocks the audio device just for extracting files and the task at hand is so borderline trivial that I can crank this out within 1-2 hours (as I said, I already did something remarkably similar and it was trivially easy to pull off). The resulting file size will also be much smaller (last time I checked a vanilla HISE app has 20MB while you can get down to 2-3 MB for a lean JUCE app.
You can literally call
File::getSpecialLocation(File::currentExecutable)
there plus other nice QOL things that might be possible to pull off within HISE but involves bending its feature set to be able to almost send emails. So here's my suggestion:- Keep developing the prototype within HISE but don't try for the 100% perfect UX (like hacking around to the get the current executable)
- Ideally gather feedback from other devs about features and generalization
- If that's done and the resulting prototype is considered useful, I'll get on board and rewrite the logic as a C++ JUCE app that I'll put into the HISE codebase for everyone to use. It still leaves the requirement of compiling and code signing the installer build but that should be possible somehow.
-
BTW, just downloaded your zip from media fire and it got blocked by Chrome as suspicious download here :)
-
@Christoph-Hart yeah, I tried as well, same thing. Maybe putting the password on the zip is the ultimate solution
I'm gonna give WiX and NSIS a try as well.
@Christoph-Hart said in Inno Setup is Flagged as Trojan?:
Keep developing the prototype within HISE but don't try for the 100% perfect UX (like hacking around to the get the current executable)
Ideally gather feedback from other devs about features and generalization
If that's done and the resulting prototype is considered useful, I'll get on board and rewrite the logic as a C++ JUCE app that I'll put into the HISE codebase for everyone to use. It still leaves the requirement of compiling and code signing the installer build but that should be possible somehow.The compiled HISE standalone already comes with a bunch of certs as seen in the VirusTotal scan
so I guess that's part of the reason why it's passing Smart Screen and virus scans.
Alright, there's sample location, vst3 location (is changing aax location a thing even?), au location on mac, what else? Where do audiofiles go if you have a bunch of them? It is always %appdata%/company/product ? User presets too, right?
-
@aaronventure said in Inno Setup is Flagged as Trojan?:
vst3 location
This shouldn't be changed by the user, Steinberg specify where it should go on the system.
AU location shouldn't be changed either.
@aaronventure said in Inno Setup is Flagged as Trojan?:
Where do audiofiles go if you have a bunch of them? It is always %appdata%/company/product ? User presets too, right?
Audio files go in the app data folder as a .dat file.
-
@d-healey said in Inno Setup is Flagged as Trojan?:
Audio files go in the app data folder as a .dat file.
er... not for me at least unless I'm doing something wrong..
they go in %AppData%/companyname/productName/AudioFiles
as do any hwt files,
Presets go here:
%AppData%/companyname/productName/UserPresets
Images go here:
%AppData%/companyname/productName/Imagesmeta data goes wherever the developer wants it to go...
the list goes on..
-
@Lindon I just put the .dat file directly in the app data folder.
As per the docs - https://docs.hise.audio/working-with-hise/settings/project.html#embed-audio-files
-
the list goes on..
Yeah but anything I can think of either goes into the samples folder or some subfolder of the app data folder, so you can just use a zip file with the correct folder hierarchy for the entire app data payload.
I think 99% of all cases can be covered by having three payloads:
- Plugins.zip which contains every plugin that is put to the default location (with an option to change it if appropriate, eg. VST2 on Windows)
- Samples.zip which use either the existing location (if the Linkfile already exists) or a default that can be picked by the developer. The first option is important for shipping updates / expansions.
- AppData.zip which contains any payload that should be put into the app data directory. AudioFiles.dat, Wavetable stuff, additional DLLs (currently there is none, but I remember that I had to ship the rLottie.dll for PercX). Even Expansions could be put there.
On macOS you can simply bundle all that up into a nice .dmg file (you can even hide the zip archives so the end user only sees the installer app which is about as nice as it can get. But on Windows you'll have a zip file that contains other zip files AND the installer which is a bit weird.
-
@Christoph-Hart oh and if we‘re at it: the sample payload can then be just an hr1 archive (this would be optional if your sample data is HLAC monoliths). This way you get automatic split archives and the compression is way better than ZIP.
-
@Christoph-Hart said in Inno Setup is Flagged as Trojan?:
@Christoph-Hart oh and if we‘re at it: the sample payload can then be just an hr1 archive (this would be optional if your sample data is HLAC monoliths). This way you get automatic split archives and the compression is way better than ZIP.
I thought the compression was in the ch1 files? Didnt you say that once? not in the HR1 files
-
@Lindon said in Inno Setup is Flagged as Trojan?:
I thought the compression was in the ch1 files?
Both. The HR1 format uses the FLAC format which yields a better compression ratio (about 30-40% more) so I chose that for the file distribution format where performance doesn't matter at all.
-
@Christoph-Hart There are some issues with exporting monoliths to HR1 that I kept running into so I gave up on that kind of deployment. I've narrowed it down to my sample map, but even after recreating it from scratch (re-importing all the samples and setting everything up) it's still happening. HISE freezes and needs to be terminated, and the result is only a temp.dat file with ~75% of the target size.
-
More findings on this recently:
I've discovered that using Inno Setup 6.0.3 results in the least number of false positives on VirusTotal, and most important of all, doesn't falsely trigger the Windows Defender.
Further, adding product name to the setup and creating a custom type [Types] in the script knocks that down to 3. Now, self-signing via openssl and signtool drops it down to 1, with the only report being the Crowdstrike Falcon saying it's greyware, and they a dedicated email for false positives on their website.