While I have been fairly negative on the other thread, I would still like to believe that this here point is neither the fault of gog.com, nor their responsibility to fix. Any help would of course be welcome, but ultimately it is wine that should be improved.

I view it as a separate issue from using encryption to secure the data against the customer who bought it, although of course personally for me it makes it all the more worse.

While not entirely technical in nature, I think this should be stated in order not to invite an easy brush-off with well, wine isn't supported.

The Wine problem is a separate one, because the non-encrypted installers also fail.

From what i can see, its a small group of (seemingly) linux users which are unhappy with new format of GOG WINDOWS installers ...despite the fact change wont affect Windows users at the end of the day. At least what i get from having a look at the OP referred to.

It's not only the "linux guys" who are concerned. The reason you hear more Linux people complain is that they are directly affected by this change right now, so they are obviously more motivated to find a quick solution than others.

Simple use case. Let's say you are a Windows user and want to play your Goblins 3 on Android tablet in ScummVM. You don't want to waste time or clutter your Windows system by installing the game, so you take innounp and unpack the game files for yourself to copy to your tablet. Or let's say you want to play Arx Libertatis on Windows using game data from Arx Fatalis that you bought on GOG and so on.

All that is not limited to Linux users. The reason it was brought in the context of Linux is that it's more common. As others said, let's continue this in the other thread if you need more info.

Exactly. I do this all the time, use innounp for whatever game I download from here.

I'd say it wouldn't affect most Windows users. I imagine there are a few who like to extract the installers for use with source ports or something like that. It's a fringe case, but it exists. I'll admit to doing this on occasion.

1. With the password, they can easily change the algorithm used at any time or even on a per-game basis because it's just a line or two of code in their custom unrar.dll. With the custom header approach, it's more work to do that and less likely to happen carelessly.

2. It's clear to potential tool developers who might be scared away that supporting a customized RAR format is unlikely to be viewed as "illegal circumvention" by laws like the DMCA while getting at an obfuscated password very much is.

...plus, a tool to unpack a RAR with a customized header prefix, complete with safety stuff, is eight lines of Python:

with open(filename, "r+b") as fobj:
____tmp = fobj.read(7)
____fobj.seek(0)
____fobj.write(b"\x52\x61\x72\x21\x1a\x07\x00")
subprocess.call(['unrar', 'x', filename])
with open(filename, "r+b") as fobj:
____fobj.seek(0)
____fobj.write(tmp)

Compare the current approach, where it needs to reliably get the GOG game ID, which greatly complicates things since you either need to poke around in the InnoSetup installer (which means two different unpackers and some ID-finding code) or retrieve it from the website, which is akin to online activation in the fragility it introduces.

Gowor explicitly said that his goal was to prevent sloppy users from unraring the bin files without realizing that it'll leave a broken install and then complaining to support, wasting their time.

...so it's either an archive format that standard archiving tools don't recognize (like the old InnoSetup packing which prevents quick patches to the archive without a full rebuild) or, as I also suggested, bundling a dxdiag-like diagnostic tool with the game and requiring its output before a support ticket can be opened for a Windows installer.

wait, didn't you just made the argument in your post before how easy the custom header approch can be implemented? One line of Python to change the archive and one line inside unrar.dll to change the header detection.
Customizing that custom header on a per-game basis would be just as easy as changing the password generation algorithm.

you might be right here, I'm not familiar enough with the DMCA to object to that interpretation.
However, I think we can agree that ideally we would find a solution where we have the permission from GOG to use our tool to bypass the installer. If we have that permission then we don't need to worry about the DCMA. Right?

sure that's right. But does it really matter if the script has 8 or 50 lines of code? And don't forget the new innoextract release already has some support for this now, so in the end you can get away with just one tool and one command, just as before.

As i mentioned before the real point of discussion imo is, what concept do we want for distributing the games.
a) an installer method which reduces/removes as much options as possible, thereby removing most possibilities to "do anything wrong". But likewise also making it harder to use in a way not supported by GOG.
b))an installer method which openly offers the possibility to get the game date without running the installer and simply accept the fact that there will be users who will shoot themselves in the foot with that.

Yes, we can mitigate the problem for b) by using the http-header/file suffix solution that has been proposed. Or use your method to make it a bit easier to bypass the installer for a). But honestely, I think that's just cosmetics and only avoids making a real decision for one side or the other.

well, if we are going to just accept what gowor said, we can just live with the status quo, close the thread and go and play some games :p.
The whole point of this discussion was to give some arguments that might possibly make gowor rethink his position.

The password is designed to be easy to change and hard to guess. Changing the identifying prefix IS a simple matter of editing a string equality check... but it's also possible to heuristically identify where the data starts in a file with an identifying prefix of non-standard length, making an automated bypass of even the most variable identifying prefix changes simple to bypass.

To actually have some hope of preventing an extraction by a novice "bypass artist", you need to change the data structures themselves... and when you do that, it's significantly harder because the RAR compressor isn't open and, even if you wrote an obfuscator that copied the file or switched to 7zip which has an open compressor, you're still dealing with a task that exponentially increases the chance of corrupted data or a buggy extractor.

(Trust me. I've written Python parsers for GIF and earlier versions of unencrypted RAR files and, while low-level programming isn't my forté, I have puttered around with C and C++ a bit. I have a pretty good idea of what I'm talking about.)

I'd rather not take the risk. The legal world is full of unanticipated consequences... sometimes years delayed.

I'd certainly prefer an installer that's as easy to unpack as possible... I'm just not sure that option is on the table.

From what Gowor said, it seems that the password was basically an off-the-cuff attempt to bring back what was lost when he switched away from InnoSetup's built-in packing so he could have the option of applying hotfixes to multi-gigabyte installers without having to rebuild the entire fileset.

And I was operating on the assumption that it might very well be impossible to change Gowor's mind on the outcome, so proposals that do an equally good job of minimizing the support burden must be offered.

hmm, i think we lost ourselves in a kind of useless discussion here.
I mean, if we operate under the assumption that GOG will try to make things harder for us, we don't need to try and propose something like your method which makes things easier for us ;) They would simply use another method and _not_ tell us about it.
However, if they just accept that their protection is broken easily and don't intend an "arms race" with our unpacking attempts (which seems the more likely assumption so far), then it doesn't really matter how easy password algorithm or header mutation can be modified.

me neither. Nonetheless, still worth arguing for it, i think. Sometimes people surprise you :)


(btw. love the term "bypass artist". so poetic ;) )

Thanks. I do try.

I have a suggestion concerning packaging of large multi-platform games that doesn't have to do with the issue that spawned this thread. I'm not sure how much extra work it would be, but I thought that it would be worth bringing up in case packaging is being worked on in general. I like to download all the games, both Linux and Windows versions, just to be on the safe side. I have currently no use for the mac versions, but I would download them too if disk space was not an issue. Alas.

Several early Linux ports of games were not distributed physically at all. You would buy the boxed edition of the Windows version of the game and download the Linux installer from the publishers website. The installer would contain all the platform-specific resources - which were typically rather small in comparison - and pull the rest of the game from the installation CDs.

I would like it if in a similar fashion the platform-neutral parts of large games were packaged separately and shared between the platforms. Take for example The Witcher 2 (with which I assume GOG.com will find a contractually easy time to do whatever they wish with). When unpacked, the installers of both the Linux and the Windows versions of the game contain 23G of data, but as much as 19G of this (a total of 1070 files) are shared between the two.

Another thing I noticed; the Linux version tarball is 25% bigger than the Windows installer files combined, because .gz uses a compression algorithm from 1977. For this data, just using .xz instead of .gz with just the default options made the file size fairly comparable.

There may be parameters I didn't consider, such as speed of compression, memory use during decompression, or the cost of documentation. I'm fairly sure xz is supported by the target distros, though.

Anout gz / xz see this wishlist entry: http://www.gog.com/wishlist/site/use_better_compression_for_linux_tarballs_for_example_tarxz