VLC x64, ASLR, and stripped relocation info.

[VLCwin7User]

I was tightening security on certain programs. In the registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\vlc.exe there can be a QWORD entry for MitigationOptions. A typical option is to set this value to 10111. But, if it is set to 10311, images without relocation data won't load. So, when VLC didn't load, I wondered why.

Using CFF explorer, it appears that the relocation info was stripped from vlc.exe (64 bit), even though the linker flag indicates ASLR. This is version 2.2.4 on Win 8. The file is signed and the signature is valid. I didn't know if this was by design or done inadvertently, but it is my understanding that ASLR won't work if relocation info is stripped. I checked a handful of .dll files and the relocation info is not stripped. So, it seems to be the vlc.exe only.

So I thought I would bring this to your attention in case the relocation info was stripped inadvertently.

(Right now, I have it set to 10101111111, a win 8 setting. VLC works just fine. I'd like to change that setting to 10101111311)

[VLCwin7User]

I code infrequently and very amateurishly, and I like the Mingw-w64 for 64 bit executables. So, when I looked at some of my stuff, I also found that the relocation info was stripped. Believing that people who live in glass houses shouldn't throw stones, I've always been on the lookout on how to get .reloc information into the binary so that ASLR would work. I'm not the only one.
I ran into this today. https://github.com/OpenVPN/openvpn-gui/pull/123
"we could add a dummy global like __declspec(dllexport) char aslr_workaround; and then -Wl,--dynamicbase will work."
So I did that: __declspec(dllexport) char aslr_workaround; and the relocation data is now present in the .exe file.
It is enough to fake out Mingw-w64. Just thought I'd pass that along.