https://bugs.winehq.org/show_bug.cgi?id=38949
--- Comment #4 from Anastasius Focht focht@gmx.net --- Hello folks,
--- quote --- Validating if the SecurityCookie is inside of the module should fix this, however I wonder if this is really a complete fix. Do we theoretically also need relocation of the SecurityCookie pointer? --- quote ---
I think that should be taken care by the PE compressor code itself. Whoever messes with load config directory has to emit/keep relocation entries for:
* LockPrefixTable (VA) * EditList (VA) * SecurityCookie (VA) * SEHandlerTable (VA)
I would assume the PE compressors generate metadata about the original file sections, which includes relocations. When the compressor creates the final PE, those relocation entries get stripped and are instead stored in internal table. The uncompressor stub has to implement OS loader behaviour by processing those internally stored relocation entries on its own, which should also include load config VAs before passing control to the real application entry point.
Of course the security cookie can't be randomized by OS loader this way (retaining the original value as emitted by VC++ compiler /GS) but that's a minor drawback. The app will do a "once" randomization of the security cookie on its own as part of CRT startup.
Regards