Yeah, that’s the most plausible hypothesis in my opinion.

I don’t know either, but I know what this means for me: not buying any Windows-only title anymore until we get this sorted out.
Let’s hope we will hear from GOG staff soon about it.

I think we should give GOG some time to digest and answer this question. If there will be no answer we can at least open a community request to stop using encrypted RARs or any other kind of DRM-like methods.

so after throwing a debugger and some time at this problem:
The password is indeed calculated inside unrar.dll, totally unrelated to InnoSetup. Too lazy to trace how exactly it is calculated, but it seems(!) to be derived from the gameID.
Retrieving the password can be done simply enough by placing a breakpoint on CryptProtectMemory. With that password 7zip was able to extract the .bin file without a problem.
You probably could work out some method to unpack these files automatically.

Though now that i'm fully convinced as well that this was done deliberatly by GoG, i rather add my voice to ask why the hell they did this!

Thanks for spending your time on this.

I tried to run one of the setups in winedbg and put a breakpoint on CryptProtectMemory, however it said it couldn't find symbols for it. Because of that the backtrace was all in machine codes and there was no easy way to read the parameters. How exactly did you read them?

Here is what I got:

winedbg setup_deponia_2.2.0.8.exe
WineDbg starting on pid 0023
0x7b85b9c0: subl $8,%esp
Wine-dbg>b CryptProtectMemory
No symbols found for CryptProtectMemory
Unable to add breakpoint, will check again when a new DLL is loaded
Wine-dbg>c
fixme:process:SetProcessDEPPolicy (1): stub
No symbols found for CryptProtectMemory
No symbols found for CryptProtectMemory
No symbols found for CryptProtectMemory
0x7b85b9c0: subl $8,%esp
Wine-dbg>bt
Backtrace:
=>0 0x7b85b9c0 in kernel32 (+0x4b9c0) (0x0033fe98)
1 0x7bc74810 (0x0033feb8)
2 0x7bc7762f (0x0033ffa8)
3 0x7bc747ee (0x0033ffc8)
4 0x7bc4acf7 (0x0033ffe8)
Wine-dbg>disas
0x7b85b9c0: subl $8,%esp
0x7b85b9c3: pushl %edi
0x7b85b9c4: pushl %esi
0x7b85b9c5: call 0x7b85a9b0
0x7b85b9ca: leal 0xfffffff0(%ebp),%esp
0x7b85b9cd: popl %ecx
0x7b85b9ce: popl %ebx
0x7b85b9cf: popl %esi
0x7b85b9d0: popl %edi
0x7b85b9d1: popl %ebp
Wine-dbg>

Not sure if it's the right frame.

Here are others:

Wine-dbg>frame 1
Wine-dbg>bt
Backtrace:
0 0x7b85b9c0 in kernel32 (+0x4b9c0) (0x0033fe98)
=>1 0x7bc74810 (0x0033feb8)
2 0x7bc7762f (0x0033ffa8)
3 0x7bc747ee (0x0033ffc8)
4 0x7bc4acf7 (0x0033ffe8)
Wine-dbg>disas
0x7b85b9d2: leal 0xfffffffc(%ecx),%esp
0x7b85b9d5: ret $0x4
0x7b85b9d8: nop
0x7b85b9d9: leal 0x0(%esi),%esi
0x7b85b9e0: leal 0x1a5e98(%ebx),%eax
0x7b85b9e6: subl $12,%esp
0x7b85b9e9: pushl %eax
0x7b85b9ea: call 0x7b81f010
0x7b85b9ef: addl $16,%esp
0x7b85b9f2: testb $0x8,%al

Wine-dbg>frame 2
Wine-dbg>disas
0x7b85b9f4: jz 0x7b85b9b1
0x7b85b9f6: subl $8,%esp
0x7b85b9f9: pushl $0xff
0x7b85b9fb: movl 0x10(%esi),%eax
0x7b85b9fe: pushl 0x3c(%eax)
0x7b85ba01: call 0x7b81f130
0x7b85ba06: movl %fs:0x00000024,%edx
0x7b85ba0d: pushl %edi
0x7b85ba0e: pushl %eax
0x7b85ba0f: leal 0xfffdd17c(%ebx),%eax

Wine-dbg>frame 3
Wine-dbg>disas
0x7b85ba15: pushl %edx
0x7b85ba16: pushl %eax
0x7b85ba17: call 0x7b81f020
0x7b85ba1c: addl $32,%esp
0x7b85ba1f: jmp 0x7b85b9b1
0x7b85ba21: testb $0x2,0x1a5eb8(%ebx)
0x7b85ba28: jnz 0x7b85ba34
0x7b85ba2a: subl $12,%esp
0x7b85ba2d: pushl $0x1
0x7b85ba2f: call 0x7b872200

Wine-dbg>frame 4
Wine-dbg>disas
0x7b85ba34: pushl %eax
0x7b85ba35: pushl %eax
0x7b85ba36: pushl $0xff
0x7b85ba38: movl 0x10(%esi),%eax
0x7b85ba3b: pushl 0x3c(%eax)
0x7b85ba3e: call 0x7b81f130
0x7b85ba43: movl %eax,0x0(%esp)
0x7b85ba46: leal 0xfffdd144(%ebx),%eax
0x7b85ba4c: pushl %eax
0x7b85ba4d: leal 0xfffde054(%ebx),%eax

If I'm guessing correctly, at that break point something (a registier?) should contain an address of memory which has that password. But going through them I didn't find anything sensible or something that unrar was able to chew.

Hmmm... Well experience with C and how the stack frames work, arguments are pushed onto the stack in opposite order; Course the stack goes down as you add things to it so it actually ends up kinda how you expect.

After the call the ESP adds off that stack frame, so quite often it's push xxx, call, add esp.

This line seems the most likely one to further investigate:
0x7b85b9e0: leal 0x1a5e98(%ebx),%eax

edit: Although working completely blind it's just a guess...

Well done, and thank you for your help in investigating this matter ;)

@shmerl
Don't have access to my linux machine right now, I checked it under windows with ollydbg. And I don't know winedbg well enough to give you any further tips without trying things out myself.
As rtcvb32 said you will find the arguments to the function on the stack. First argument should be a ptr to the password string.

It seems your wine is not compiled with debugging symbols enabled. iirc if you have those there is even a command which nicely shows you all function parameters and local variables.

uh also the setup process spawns a child process which does the whole unrar thingie. Don't know how that is actually handled in winedbg, ie if your bp is actually in the right process.

when using ollydbg2:
just launch the installer, then launch ollydbg(admin rights!) and attach to the setup-xxxxx.tmp process, set the breakpoint,
continue(F9), then click Install in the in installer, and you should hit the breakpoint. Looking at the stack, the second value from the top is the password.
maybe that helps you to do the same with winedbg ;)

(in case you want try it) the password for neverwinter nights, french edition is: 7387bbd6cc05b8c37e1c21b3061f241c
I would assume it is the same for everyone.

i'm off to join the rest of the family :)
merry christmas everyone (or happy holidays :p)

How do you set the breakpoint in ollydbg2?

Your assumption seems right, the password you posted worked for me.
Let’s hope that GOG will take this as a hint that password protection, as any DRM, is *not* an efficient way to prevent data retrieval. The rational reaction would be to stop using this, especially if they’re still the anti-DRM team they’ve always seem to be.

Something *big* is going on here, and I hope a happy conclusion is coming soon from GOG part.

Agreed. GOG got me back into paying for games after digital distribution replaced CD-ROMs while I was cold-turkey switching from WinXP to Linux.

It'd be a real shame if GOG drove me to piracy just to ensure I could play the hundreds of games I already paid for.

I have libwine-dbg:i386 installed, but that affects only Wine itself, I'm not sure if it help debugging any third party applications.

Strangely, when I try to attach to that second process in winedbg it doesn't even break on CryptMemoryProtect anymore:

-------------
1. Launching the installer (it goes until language selection dialog)

wine setup_deponia_2.2.0.8.exe

----------------
2. Starting the debugger and attaching to the tmp process (after c command, I press OK in the dialog).

winedbg
Wine-dbg>info process
pid threads executable (all id:s are in hex)
00000021 2 'explorer.exe'
0000000e 7 'services.exe'
0000001a 3 \_ 'plugplay.exe'
00000012 4 \_ 'winedevice.exe'
00000008 1 'setup_deponia_2.2.0.8.exe'
00000024 1 \_ 'setup_deponia_2.2.0.8.tmp'
Wine-dbg>attach 0x24
0xf778fd5e: int $0x80
Wine-dbg>break CryptProtectMemory
No symbols found for CryptProtectMemory
Unable to add breakpoint, will check again when a new DLL is loaded
Wine-dbg>c
No symbols found for CryptProtectMemory
No symbols found for CryptProtectMemory
No symbols found for CryptProtectMemory
No symbols found for CryptProtectMemory
No symbols found for CryptProtectMemory
No symbols found for CryptProtectMemory
No symbols found for CryptProtectMemory
No symbols found for CryptProtectMemory
No symbols found for CryptProtectMemory
No symbols found for CryptProtectMemory
No symbols found for CryptProtectMemory
No symbols found for CryptProtectMemory
No symbols found for CryptProtectMemory
No symbols found for CryptProtectMemory
No symbols found for CryptProtectMemory
No symbols found for CryptProtectMemory
No symbols found for CryptProtectMemory
No symbols found for CryptProtectMemory
No symbols found for CryptProtectMemory
No symbols found for CryptProtectMemory
No symbols found for CryptProtectMemory

-----------

And it just continues if you go through install steps and doesn't break...

I'll try looking at systemtap and check if it can squeeze function parameters somehow.

I actually suspect that it didn't even find CryptProtectMemory properly. I'll look more into it.

@Kristian
hit ctrl+g, type in CryptProtectMemory, select CRYPT32.CryptProtectMemory from the list, click follow.
Then hit F2 to set a breakpoint

hm the backtrace you posted earlier was inside kernel32(ie wine code), shouldn't there be more info like function name, line numer, etc?

Also looking at the wine source code it seems that CryptProtectMemory isn't yet implemented, so using that method won't work under wine. Since that API is only available since Windows 7(or Vista?) anyway there are most certainly other codepaths in the installer.