Do you get the 'tmp' dir and a nearly empty 'app' dir, or do you get everything you should (all the game data under the 'app' dir)?

Game data? Like I said I ran it on the executable. The game data is in the .bin file.

The output from Innounp: https://drive.google.com/file/d/0B2M5u0V1WGSROXlDWDFOZ3k4WlE/view?usp=sharing

The output from running the "Borg" disassembler on "setup_goodbye_deponia_2.1.0.10.exe" : https://drive.google.com/file/d/0B2M5u0V1WGSRcWpYYVlBVHFJVjA/view?usp=sharing

Edit:

All of the files I disassembled using "Borg": https://drive.google.com/file/d/0B2M5u0V1WGSRcG9BME1QcGFJbVU/view?usp=sharing

The intended behaviour of innounp is to extract the data from the .exe and the eventual .bin file(s) (you don’t need to give it the .bin file as an argument, it "guesses" its presence from the .exe file). If you didn’t get the game data, it means it failed to open the .bin.

Good point. I'd forgotten about that.

As a later commenter mentioned, it succeeds if you point it at the ,exe... you just don't wind up with the game.

What I'm suggesting is that maybe, from InnoSetup's perspective, the BIN is NOT part of the installer and, instead, is just a file the custom install scripts happen to access via the unrar.dll that gets extracted from the EXE.

(Sort of the reverse of how, in the early days of InstallShield, some programs were distributed as an InstallShield EXE+CAB set wrapped up in a scripted WinZip self-extractor to make it a single-file download.)

...which might also explain the new design. If the BIN contains everything needed to install the game except the password, then Galaxy could retrieve the password from GOG's database, download only the BIN, and unpack it. Then the EXE would just be a stub which takes the place of Galaxy and GOG's database.

OK, downloading the first Deponia now and will take a look. I see the unrar.dll in the first .exe already.
The question is, why such mess is needed? There is no need to use any password to check authenticity of the data. Password is used for only one purpose - preventing the unpacking. This smells DRM all way through.

OK, I see now. Second file for Deponia is indeed an encrypted RAR archive setup_deponia_2.2.0.8.bin and it's not a part of package made by innosetup. So the explanation above seems right - innosetup package calls unrar.dll and passes a password to it somehow.

Is there some way to disassemble the innosetup package to extract the scripts from it? I suspect those scripts are embedded in the executable and aren't part of what is extracted in the app directory. Or may be they are embedded in one of the extracted DLLs.

shmerl, did you check out my disassembled files? The include the setup exe file.

I might have been unclear previously: when I said it fails to extract the archive, I was seeing the same behaviour than Kristian is reporting. Files included in the .exe are extracted, but not the ones from the .bin.

EDIT: Your hypothesis about the .bin not being part of the InnoSetup installer would explain why innounp/innoextract don’t fail with an error.

The unrar.dll bundled with these installers is not the stock unrar.dll but a modified version. At a quick glance, my impression was that it would still be reasonably simple to retrieve a working password, but at this point it is probably wiser to wait for an official answer from GOG.

If we ever get one :) So far the only answer was "contact support" which is really a non answer. See here. I asked if it's possible to route this issue to the packaging team but got no further answer since.

Please add your voice to that thread and quote GOG staff to notify them about your posts (I'm not sure if they read everything).

The unrar.dll file is identical between the several GOG installers I tested.
If the password is actually in it, it would mean it’s the same for every GOG installer.

I suspect the password isn't in it, but is passed from the installer when it calls some unpacking functions from unrar.dll. And that password can as well be dynamically constructed based on the title or other parameters. The function for constructing it is fixed, but the actual string isn't stored anywhere. It's not a major protection against debugging, but can hide the password. I'm still not sure why would GOG use anything of this sort.