ReadProcessMemory etc in VB6

Ok, got that. But it appears that, that method expects the debuggee to be exited somehow (more specifically, to be told to exit) by the user. My need is to spawn the debugee, load it into memory, read the memory, then exit/end the debugee, all without the use knowning it has happened. This tells me I should use the "Debug...Stop".

I have had to put that project aside for a few weeks, but I'll be getting back to it soon. At that time, I'll finally look at using the Debug...Stop API.

Thanks, guys...this looks really promising.

Sarge

[evlncrn8]

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...

[Mkz]

Originally Posted by evlncrn8

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..

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.
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.

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

004AF16E  CALL to ReadProcessMemory from OLLYDBG.0046142B
            hProcess = 00000084 (window)
            pBaseAddress = 401000
            Buffer = 02D60020
            BytesToRead = AF000 (716800.)
            pBytesRead = NULL

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

address	data	crap
	pBaseAddress = 400200	
	pBaseAddress = 400200	
	pBaseAddress = 400200	
	pBaseAddress = 400200	
	pBaseAddress = 400200	
	pBaseAddress = 400200	
	pBaseAddress = 400200	
	pBaseAddress = 400200	
	pBaseAddress = 400200	
	pBaseAddress = 400200	
	pBaseAddress = 400200	

address	data	crap
	BytesToRead = 10CB (4299.)

[evlncrn8]

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..

[Mkz]

Originally Posted by evlncrn8

i've yet to see an exe with a 'hole' in the section range, it would probably be against the pe file specifications

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

[evlncrn8]

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