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.
-
@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
HISE Development for hire.
www.channelrobot.com -
@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.
-
@aaronventure Can you share some instructions for self signing?
-
@aaronventure
Yes, instructions for self signing would be really great! :-) -
@d-healey https://github.com/jfmaes/LazySign
This uses the old makecert. It's a simple bat, you can tweak it indefinitely.
You'll be prompted to create a password for the temporary cert, then to point to the .exe .
You can alternatively use openssl to make a certificate which can stremline the process. Install openssl https://github.com/openssl/openssl from here.
I create my installers in the Deploy folder inside the project directory. I have a batch that creates the temporary cert with openssl for the given name (edit this in the batch script; I plan to eventually have it hook into user_info.xml and automatically pull the Company property value)
This batch will check all the subfolders inside the Deploy directory and sign them with the temporary certificate. It won't prompt for password nor for a target file. Simply drop it in your project root directory and make sure you have .exe files in \Deploy\ or wherever (change the bat to your liking).
Change the company name variable to whatever you want. Make sure you point it at signtool.exe as well. You can get it either from the SDK, but the LazySign repo contains the exe as well.
_sign_with_openssl and signtool.zip
The result is a signed binary with a non-verified signature. Some antivirus software seem to find that's enough. This won't prevent smartscreen (only a high enough score will; enough users going through with the execution anyway, as well as a submission to the Microsoft Defender https://www.microsoft.com/en-us/wdsi/filesubmission though I cannot confirm whether it completely eliminates it as triggering smart screen on all my testing computers in the first place is hit or miss. E.g. HISE installer from the Releases page triggers it on my laptop. The self-signed installer from Inno 6.0.3 signed this way doesn't.
Another way of doing it is signing with your domain using limelighter https://github.com/Tylous/Limelighter
This doesn't time stamp it but what's interesting is that when signed with limelighter, the HISE installer 3.6.2 doesn't trigger the smart screen on my laptop. Signing with a self-made cert from openssl and signtool (the method above) still triggers it.
But this also adds another false positive in VirusTotal
Bkav Pro - W32.AIDetectMalwarealong with the greyware flag from Crowdstrike Falcon.
One of the values for my proposition of a universal installer (glorified unzipper) using HISE Standalone was that it would completely eliminate Smart Screen issues. If it's always the same exe with the same hash that everyone is distributing, then even if it triggers the smart screen in the first few dozen occurrences, it will eventually stop. Btw. I've never encountered a smart screen from any HISE Standalone app I tested, either mine or here from the forum, on any of my machines or VMs. So it looks like it's already "in there", maybe because they all have very similar architecture when compiled (?) and people have been using various HISE Standalone apps for a while now, no?
I'll continue work on it and post a better example soon.
-
@Christoph-Hart said in Inno Setup is Flagged as Trojan?:
Or don't give in to the code sign mafia and raw dog your installers to your customers like a real man!
:face_with_tears_of_joy: :face_with_tears_of_joy: :face_with_tears_of_joy:
-
Who cares about installers, I'm gonna zip this bad boy up, and let the customers figure out the rest.
-
@ThinkTank said in Inno Setup is Flagged as Trojan?:
Who cares about installers, I'm gonna zip this bad boy up, and let the customers figure out the rest.
Good luck :)
-
@aaronventure said in Inno Setup is Flagged as Trojan?:
I'm looking to see if there's a way around having to pay the cartels
Did you find a solution. I'm about to renew my certificate for 3 years, it's $100 more per year than I paid a year ago! I just found a coupon code that gives me $100 which is nice. Oh yeah and I have to get a new dongle each time I renew, and just chuck away the old one, what a waste!
Edit: I just scrolled up and re-discovered your detailed post about self signing :)
-
@aaronventure use Inno Setup 5.2.3 (you'll need to adapt the script to that older version)
-
@d-healey I did turn to JUCE and managed to create a semi working app
You compile this baby ONCE, then you just ship it with any plugin. The delivery is a zip containing:
- Installer.exe
- Plugins.dat (essnetially a zip file renamed to dat, you can automate the creation of this for any project using a simple script
- Config.dat
- Samples.dat
The installer first checks if there is Config.dat and if not, throws an error. The Config.dat contains two things: info.json and optionally, background.png. If it contains background.png, it dynamically sets that as the background for the installer GUI. It's all streamed from the archive files, nothing is ever unzipped.
Info.json is a simple JSON object with Product name, company name and version. It uses the names to set the name of the window as you can see and to set the default path for the installing process. After you select a directory, it always appends the product name to the path.
It only shows the path selection Samples.dat exists.
It then extracts the Samples.dat to the target directory.
This app is meant to achieve several things:
Compile and sign once, then forget about it
For delivering plugins or sample libraries in the standard HISE format, it's all you'll ever need. No need to sign anything anymore. Other than AAX maybe.
I need to implement
xattr -cfor mac so you don't have to sign VST or AU anymore either.After that, no more signing EVER. Ideally I'd have this app signed on Win and Mac and everyone can use that signed .exe.
Super easy delivery
You can fully automate the packaging on a single main system using scripts. If the other OS' build to the same networked directory, then once it's done you just run a packaging script which simply zips up the binaries and all relevant files.
One download for all platforms
Easy management of downloads on your hosting service. Save loads of space for large sample libraries without your delivery looking funky and requesting the user manually unzip the samples somewhere
First time dabbling with JUCE to create a functioning app, so the codebase is a mess, but I'll open it up anyway so others can contribute as well. Ideally I hope to have this ready for the launch of my first HISE plugin.
-
I did turn to JUCE and managed to create a semi working app
NOOOO! Why didn't you wait a few weeks, I'm currently building an installer IDE that you can use to create compiled installers (actually your topic here nudged me into that direction).
How are you distributing the many files on Windows? on macOS you can simply put them all in a DMG and get away with it, but there's no thing like this on Windows (except for zipping it all up and let the user expand it but that's a suboptimal workflow IMO).
-
Haha, well, it was good practice. If nothing, I gained immense respect for your work with HISE, as if I didn't have enough already.
Another good thing about this approach is that it enables a fully manual installation just by unzipping the .dat files. For those who want it.
I mean you can do SFX but that's weird, I think everyone by now learned to expect a zip when not using a dedicated downloader.
From what I can see, either you have a downloader app that the user either downloads and runs or installs which then does what I described here, or you ship a self contained zip file right as an order fulfillment.
I don't think delivering zips is an issue at all.
-
@aaronventure said in Inno Setup is Flagged as Trojan?:
You compile this baby ONCE, then you just ship it with any plugin.
Does this get around the smart screen filter?
-
@aaronventure said in Inno Setup is Flagged as Trojan?:
You compile this baby ONCE, then you just ship it with any plugin. The delivery is a zip containing:
Installer.exe
Plugins.dat (essentially a zip file renamed to dat, you can automate the creation of this for any project using a simple script
Config.dat
Samples.datYour problem here is Samples.dat.
Most sample based applications are carrying many Gb of samples with them, so Samples.dat a renamed zip file) will be many Gb big - and as Dave and I have found out thru experience the HISE unzip process can often balk at anything past about 2Gb.... so you are limiting the utility of this right there.
In the end what we did was bite the bullet, and build an installer that:
- knows where in the interwebs your samples are zipped up - Samples01.dat, Samples02.dat... Samples24.dat etc.
- Knows (from its config data - a manifest for us) where these need to go
- downloads these dat files and puts them in the right place.
So this covers downloading too.
The other nice thing about this was it allowed us to add a whole truck load of additional meta-files etc. used by the plugin , e.g. tagging.json etc. - whatever your plugin uses, as well as installing VST3, AU and AAX -plugins across Windows and OSX
So it installs
- plugins (including letting windows users select their VST3 folder)
- samples
- Audio files
- MIDI files
- User Presets
- meta data
- images
etc etc. basically anything you want anywhere you want to put it.
So if you continue with your installer - my experience tells me plugin.dat, samples.dat and config.dat
are not going to be enough.Something for @Christoph to consider too I guess...
-
@aaronventure I would still recommend to go for the DMG option on macOS - you can hide the data files in the DMG folder view and it becomes a very lean user experience.
If you go down this road, I can recommend DMGCanvas, it costs 20 bucks once but is as smooth as it can get (it even automatically notarizes the DMG for you).
@Lindon the installer system I'm working on should cover all bases
- customizable appearance (not 100% skinnable, but you can change some colours and font to match your company's CI)
- ability to download files or do HTTP requests
- Javascript (not HiseScript!) evaluation for doing some simple logic (like hiding some options depending on previous selections)
- inbuilt extraction of HR1 archives and or zip files
- automatically write the sample link file
- (optional) embedding of assets into the installer binary (if you don't want to ship additional files, for FX plugins this should be fine).
I'm switching the main HISE installers to this system for the next release and I think it can be the default option going forward now (the more people use it the more stable it gets obviously).
-
@d-healey If we all use the same .exe, then in a few hundred runs, yes, forever. You don't have to build reputation from 0 for each new release or update of your plugin - the installer.exe is always the same file.
