[4ad]

Yes, though in this particular case the author told me cgo wasn't involved. This makes it very very peculiar. Usually when I see system DLLs (not 3rd party) rebasing it's either mallware in other processes that lazily loaded ntdll.dll and that had to be rebased or some legit program or mallware that does user mode hooking by injecting DLLs.

It is NOT a Go problem, but Go could implement a workaround making the address space reservation in teh PE header.

[burgerbrain]

Isn't Go normally statically linked if cgo isn't being used? Would that mean that the DLL's in the virtual address space definitely shouldn't be there?

[4ad]

Statically linked in Linux, in Windows the Go runtime and packages are statically linked into the binary, but the binary itself is dynamically linked to kernel32.dll because issuing syscalls directly is not supported.

Why was kernel32.dll rebased when Go doesn't force the rebase is a very good question indeed. I suspect a 3rd party user mode hook, it doesn't even have to be malware, there are legit "security" and monitoring applications that use this technique.

[mbe]

ASLR I would guess.

[4ad]

ASLR support needs to be stamped in the PE header. You can enable it globally, but the randomization space is smaller than it should matter for this.

It's definitely something to investigate though.