Closed woodruffw closed 5 years ago
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 stat
ing 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).
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.
Looks good to me. Haven't gotten a crash out of pe-parse yet, but no breaking changes as far as I can tell.
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.
Work towards #174.