At 400500 there is indeed a hole in memory, it is not mapped to anything. If you request data from this address, you won't get nothing for sure.
The same happens if you request from 400000 to 40FFFF (for instance) in one go, since the memory is not accessible - not all of it anyway.
Even if you keep below the 4K limit that Sarge mentioned, say 400000-400FFF, i'd say you still get an error, since there is valid data only from 400000 to 4003FF. That's what I meant by "hole" - unmapped memory from 400400 to 400FFF.

I must state that I haven't used this API in a long long time, these are all suppositions on my part :)

total suppositions, its not a hole, the sections will be aligned by section alignment in memory
so 400000->401000 is DEFINATELY available
hole in memory in the exe maybe, but not when mapped into memory.. try it..

suppositions help noone reading the thread...

all the memory is available in the exe, typically from the image base->image base + size of image, the sections are all linear, and padded until section alignment, unless the sections have attributes like PAGE_GUARD etc, which can be set from virtualprotect..

however on a normal exe, you can do the straight dump no problems
4k limit is bullshit too.. 4k is just the size of 1 memory page (alignment) - 4096 bytes
readprocessmemory/writeprocessmemory are definately capable of writing more than 4k in 1 go...

i ve read this thread several times earlier and mostly refrained from posting anything because im not that much comfortable with the language visual basic

in genearal Readprocessmemeory does not have any limits on reading only 4k and increments

if you simply want to check how big readprocessmemory can go
load ollydbg on ollydbg set a conditional breakpoint on ReadProcessmemory and log all function arguments you can see it reading
i have attached an excel sheet that contains the log of all readprocessmemory address
and you can see ollydbg accessing address at ox400200 with sizes as big as ollydbg .txt section etc etc

I checked the memory map in OllyDbg and you are right. Indeed the whole 0x1000 page of the header is available. Also, since the next section starts immediately after (at 401000) there is no hole contrary to what I assumed. :o
Maybe if the header was 500 long, and the .text started at 402000, there would still be a whole - not from 400500 to 401FFF as I thought, but from 401000 to 401FFF, since the header takes up an entire page and not just 500.

I took a look at a couple of windows executables and all of them have the sections contiguous to each other, so the memory from the start of the first section to the end of the last one should all be available - excluding any page in/out issues.

there wont be a hole, the executable format, is section based, of an entire chunk
if the data does not reach the boundary, the 'hole' is zero filled, this is handled by the pe loader, the entire executable image should be entirely accessible (section characteristics of course setting r/w/e flags) when loaded into memory..
the holes you're talking about are typically in the exe file image, thats totally different compared to the memory layout when the exe is actually loaded..
i've yet to see an exe with a 'hole' in the section range, it would probably be against the pe file specifications, as for the 'maybe if the header was 500 long', the data in the elfanew will contain the pointer to the pe portion, mz->pe portion will be mapped into memory for sure and pe->start of first section too, header size changing will not change the results in any way..

Once again you are correct. I tried editing the sections of notepad.exe so that the RVA of the last section did not start immediately after the end of the previous one, but one page ahead.
I also tried updating the size of data and checksum but the exe always came up invalid.

I guess I must learn to keep my mouth shut when I'm not sure of what I'm saying :o

well, we all live and learn eh :), i didnt really decide to 'attack' your posts, or teach you a lesson, im just trying to help things