*shrug* in the end it is just a different archive format.
it probably makes things a lot easier for the GOG packager if they only have to package the games once instead of doing it twice.
would really like to help out in deciphering these, but i'm traveling over the holidays. won't really have a chance to take a closer look until next week.

Exactly what I mean.

Moreover I've got Linux Steam client installed for games supporting Linux and every time I'm starting another Steam instance under Wine it makes some mess in my default settings, loosing tags (never added them again) etc.

That is the reason I liked GOG installers. Or perhaps - it was the reason? :|

If it's true that they are making efforts to obfuscate the files' structure, it means that they have no idea why their customers are here, what's their competitive edge and they may easily lost both.

You're welcome. :)

Sorry, before I was writing from my phone so I didn't bother to add a link or anything... It's not difficult to find the SteamCMD page with a quick Google search, but here it is nonetheless: https://developer.valvesoftware.com/wiki/SteamCMD

It's pretty easy and intuitive to use if you are not afraid of the command line interface. You can prepare an script for downloading lots of games automatically while e.g. you sleep or are out of your home. To choose which OS build to download, one simply has to set the following variable:

@sSteamCmdForcePlatformType windows

(change 'windows' for 'macos' if you want to download the Mac version. By default this variable is set to the OS you're running the steamCMD script from)

Thank you again! Command line is one of the benefits the wife and I like about Linux. (Although I admit she is much more into cmd than I.) :)

that looks promising.
iirc the file chunks are compressed with zlib. the additional numbers probably state the size & hash after decompression. that shouldn't be too hard to verify. note that bigger files are split into several chunks, so that's something to look out for.. (still assuming that this matches the galaxy api)

though if you say that this is from the innosetup install script than we might have the problem how to (easily) get that script.
afaik innoextract cannot extract it (last time I checked)

you know, i am thinking that actually the galaxy API for retrieving the game data would be much better for your scripts, since you only get the actual game data. No wasting bandwidth with downloading useless embedded DirectX or vc runtime installers. no fighting to extract things from innosetup.
since you do all the setup yourself in your scripts (from what I have seen) you could just avoid the installer completely.
have you ever tried the experimental galaxy support from lgogdownloader ?

That seems to be correct. I have not found a way to extract the script.

The other question is: Is the script actually part of the installer or is it only included in an intermediate format?

Das ist doch eine gute Nachricht.

I've tried skimming through the inno setup source code and so far I've not found the part that handles the creation of the exe.

Looks promising:
https://coolaj86.com/articles/how-to-unpackage-and-repackage-an-innosetup-exe.html

I got a reply from Judas, but he doesn't know anything about this & suggested sending a support ticket about it instead.

I'm not sure it would be easier; the way the old installers were setup was a bit messy and inconsistent and I can see why GOG would want to redo them all, but the "old new" installers (the ones just prior to this change) were a lot simpler & easier and made a lot more sense.

The new approach is more complicated & means there's a lot more that the installer needs to do (which in turn means there's more scope for things to go wrong)... the install script for the new installer is over twice the size of the install script for the old installer

Yes - I had to use innounp via Wine to extract it.

The standalone installers are convenient because they're largely self-contained and there's very little that my scripts need to download, and up to now they could effectively be treated as simple archives with little additional processing required. As for size... I'm not entirely sure about that; at least in the case of Freedom Force the new installer is about 40MB larger than the old one

FYI: The install script is not included in it's original form. innounp recreates the file.

It's easy to get innoextract to output the necessary information: In src/cli/extract.cpp is the function print_filter_info(). It can be used to display item.check, item.before_install and item.after_install.

Those three strings contain everything that is needed to deobfuscate the game.

Some observations:

- GOG making new installers that can't be extracted by innoextract for some time now. For example, "Capitalism 2" was updated at March 14 ("updated internal installer structure").
- Looks like silent installation doesn't work as well (wine "<INSTALLER_NAME>.exe" /VERYSILENT /SUPPRESSMSGBOXES /DIR=C:\\<GAME_NAME>)

So there is a chance we have to deal with this situation ourselves.

I find that 'install_script.iss' contain following information about compressed files (example):

1. Source: "{tmp}\49\36\4936740c8b92cbc03ce7020f5e571b4e";
2. DestDir: "{tmp}\49\36";
3. Check: "check_if_install('en-US#','32#64#','')";
4. BeforeInstall: "before_install('23a4883b94f4217bf7e2412ddde86632', 'arcanum1.dat', 42)";
5. AfterInstall: "after_install('266330fdecfc96972ced46b93b3beaeb', 10488947, 10485760)";
6. MinVersion: 0.0,5.0;

line 1:
"{tmp}\49\36\4936740c8b92cbc03ce7020f5e571b4e" - full path to the compressed file inside installer

line 5:
'266330fdecfc96972ced46b93b3beaeb' - hash of the decompressed file
10488947 - size of the compressed file
10485760 - size of the decompressed file

line 4:
'arcanum1.dat' - name of the decompressed file
42 - number of the file parts(?)
'23a4883b94f4217bf7e2412ddde86632' - hash of the WHOLE file; same as in line 5 if file consist of 1 part

If file consist of 1 part it's easy to decompress it (and I successfully made it using python), but that's not always the case. In the example above '266330fdecfc96972ced46b93b3beaeb' is hash of the first 10MB-part (out of 42) of the whole file ('arcanum1.dat').

I'm not an expert at that stuff, so I don't know what to do next, can someone help? How to get the next part hash?

Can you upload the iss file somewhere?

I would assume that 23a4883b94f4217bf7e2412ddde86632 is the hash of the complete file and 266330fdecfc96972ced46b93b3beaeb is the hash of the part. Are there more chunks of the same file? I would try to concatenate them in the order that they are mentioned in the iss file after decompress()ing each chunk individually…