It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
avatar
Kristian: When I run Innounp on Goodbye Deponia's installer(The actual executable, not the data) I DO get some output.
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
Post edited December 23, 2014 by Kristian
avatar
Kristian: Game data? Like I said I ran it on the executable. The game data is in the .bin file.
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.
avatar
vv221: Seeing that there are multiple installers using these password-encrypted RAR archives, I doubt it is done on the developer part. To me it looks more like GOG has changed its way to package InnoSetup installers.
Good point. I'd forgotten about that.

avatar
ssokolow: If that's the case, I think I remember someone saying that InnoUnp.exe unpacks InnoSetup stuff so well that you can use the output to regenerate the installer. Look through the InnoUnp.exe output to see if you can find the password embedded, in the clear, in one of the install control scripts.
avatar
vv221: Sadly, like I said earlier innounp failed to extract these password-encrypted installers.
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.
Post edited December 23, 2014 by ssokolow
OK, downloading the first Deponia now and will take a look. I see the unrar.dll in the first .exe already.
avatar
ssokolow: ...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.
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.
Post edited December 23, 2014 by shmerl
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.
Post edited December 23, 2014 by shmerl
shmerl, did you check out my disassembled files? The include the setup exe file.
avatar
Kristian: shmerl, did you check out my disassembled files? The include the setup exe file.
Ah, sorry, I missed your post. Downloading them.
Not sure exactly how to make sense of them. It doesn't seem to show values for memory in unrar.txt at least for some reason.

May be there is a way to catch in debugger the moment when some functions from unrar.dll are called and analyze the parameters? Dtrace has such functionality I think.

Dtrace on Linux used to be more limited however but it's worth trying. If not, may be FreeBSD with Wine + DTrace can help.

https://github.com/dtrace4linux/linux
http://crtags.blogspot.com
Post edited December 23, 2014 by shmerl
avatar
vv221: Sadly, like I said earlier innounp failed to extract these password-encrypted installers.
avatar
ssokolow: As a later commenter mentioned, it succeeds if you point it at the ,exe... you just don't wind up with the game.
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.
Post edited December 23, 2014 by vv221
avatar
shmerl: May be there is a way to catch in debugger the moment when some functions from unrar.dll are called and analyze the parameters?
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.
avatar
drennan: 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).
Post edited December 23, 2014 by shmerl
avatar
drennan: The unrar.dll bundled with these installers is not the stock unrar.dll but a modified version.
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.
avatar
drennan: The unrar.dll bundled with these installers is not the stock unrar.dll but a modified version.
avatar
vv221: 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.
Post edited December 23, 2014 by shmerl