common/client: Initial MapViewOfFile work

[woodruffw]

Work towards #174.

[woodruffw]

We can work around requests for write requests by changing FILE_MAP_ALL_ACCESS and FILE_MAP_WRITE to FILE_MAP_COPY like @mike-myers-tob suggested, but I ran into another issue: it's pretty common for MapViewOfFile to be called with dwNumberOfBytesToMap=0, which tells Windows to map the entire file. Unfortunately this doesn't tell us how big the resulting view is, and GetFileSize(Ex) doesn't work on the memory-mapped handle that we have access to.

That means our (nonexhaustive) options are:

• Using an undocumented syscall like NtQuerySection + SECTION_BASIC_INFORMATION on the mapping handle, a la this SO solution. This is probably risky under DR's instrumentation.

• Attempting to wrap CreateFileMapping or OpenFileMapping so that we have access to the real file handle. This would require us to associate these calls with individual MapViewOfFile calls, which will probably be a pain.

• Getting the file size in the post hook by stating the filename associated with the memory map. This is nice and simple, but involves a race condition (the size of the file on disk might change).

[woodruffw]

NtQueryVirtualMemory looks like it might do the trick here. Plus, it's documented, so compatibility/breakage probably won't be as big of a concern.

Edit: And it turns out that DynamoRIO exposes dr_virtual_query, which should do exactly what I need it to.

[ehennenfent]

Looks good to me. Haven't gotten a crash out of pe-parse yet, but no breaking changes as far as I can tell.

[woodruffw]

Haven't gotten a crash out of pe-parse yet, but no breaking changes as far as I can tell.

Yeah, my suspicion is that most PEs are too large to mutate in a way that'll meaningfully affect the parser (since we'll be mostly changing data/code segments that won't affect control flow). That's compounded by the fact that memory-mapped IO probably involves fewer basic blocks (since there's fewer IO calls/less offset wrangling/error handling), so changes in code coverage probably don't accurately reflect important mutations.

I'm going to leave SL2 running with a much smaller binary than notepad.exe overnight; hopefully we'll get some results.