vv221: Any idea about how this could be done? (the debugging part)
shmerl: In theory you'd have to run the whole thing through the debugger and go through the assembly calls until you get to the point of it reading and passing the password somewhere. You'll examine that memory and it can contain the password string. All that is rather theoretical, I didn't do such exercises before. It's not very easy and requires assembly knowledge.
While examining innounp or the InnoSetup source is likely to be the more fruitful route, I get the impression you're overselling the amount of assembly knowledge needed. The most obvious approach would require it, certainly, but I don't think that's the only one.
(Disclaimer: I'm not an expert in this sort of thing)
Both InnoSetup and UnRAR have source available, which opens up a lot of avenues for making a custom build specifically designed to aid in drawing inferences about the layout of the code in another build. (Maybe even generating debugging symbols for the GOG installer, if you can find the right compilers and settings to produce identical code, but with a symbols file alongside.)
Heck, I don't remember how InnoSetup handles things but, if it's using the InstallShield "stub unpacks the installer to temp folder" approach and unrar is handled via unrar.dll, then you should be able to use whatever mechanism is employed by LD_PRELOAD and its Windows equivalent to find the "set extraction password" function.
Once you've got that, GDB supports reverse debugging, which might allow you to follow the password back in time to its source.