[PATCH 0/8] Fix dumper for x86_64

[Jon Turney]

On 06/07/2020 09:12, Corinna Vinschen wrote:
> On Jul  5 17:49, Jon Turney wrote:
>> On 02/07/2020 08:44, Corinna Vinschen wrote:
>>> On Jul  1 22:29, Jon Turney wrote:
>>>>
>>>> This needs to be aligned with some changes to gdb to consume the dumps it
>>>> produces, so it's probably best to hold off applying this until it's more
>>>> obvious what's going to happen with those.
>>>>
>>>> Random notes:
>>>>
>>>> - objdump identifies the output of dumper on x86_64 as
>>>> 'elf64-x86-64-cloudabi' (perhaps due to some over-eager sniffer).
>>>>
>>>> - regions excluded from the dump aren't rounded up to page size, so we may
>>>> end up writing the excess into the dump.
>>>>
>>>> - looking at the loaded modules and inspecting them to determine what memory
>>>> regions don't need to appear in the dump seems odd.  I'm not sure we don't
>>>> just exclude MEMORY_BASIC_INFORMATION.Type == MEM_IMAGE regions (assuming
>>>> they get converted to MEM_PRIVATE regions if written when copy-on-write).
>>
>> Unfortunately, that doesn't happen, and the region appears to stay
>> MEM_IMAGE, even if it's been modified.
>>
>> I'm inclined to just dump MEM_IMAGE regions if they are writable (although
>> using the current protection isn't 100% correct, because it may have been
>> changed using VirtualProtect())
>>
>> I suspect there's probably some undocumented MemoryInformationClass for
>> NtQueryVirtualMemory() that would let us determine if a region is sharable
>> or not, but ...
> 
> Surprisingly, there's nothing undocumented in NtQueryVirtualMemory and
> the API is fully exposed by VirtualQuery(Ex).

I came across [1], which seems to use some MemoryInformationClass values 
I can't find any MSDN documentation on, but perhaps I'm getting lost.

[1] 
https://github.com/processhacker/processhacker/blob/master/phnt/include/ntmmapi.h#L87

> What about the two protection fields in MEMORY_BASIC_INFORMATION?  If
> something changed, Protect != AllocationProtect.  Is that insufficient
> to handle your case?

Unfortunately that doesn't seem to provide any additional information. 
The Windows loader seems to allocate all regions with EXWC protection, 
then change it to match the section. (Not that there are any guarantees 
about it's behaviour)

I wasn't able to observe a region corresponding to an unmodified .data 
section with WC protection, which is somewhat confusing.