in reply to dumping the memory of a foreign win32 pid from perl

It should work okay on the current process handle. OpenProcess is for attaching to another process. Your problem is that the lowest accessible address within a process is (usually) the process environment block which starts at 0x10000, so using 0 isn't going ot work. For starters, try setting the address to read from to the address of a perl variable. my $var = 'some text'; my $addr = 0+\$var;

From that you should be able to decipher the values in the SV and track through to read back the contents of the variable. Use Perlguts Illustrated and/or Devel::Peek as a guide.

Not sure where you are going with this, but be aware that Win32 processes are not made up of contiguous spaces. There are large gaps between 'sections'. You can use the 'debug' apis, in particular, CreateToolhelp32Snapshot() to iterate the sections and find their extents.

The best information I found for these and related apis is an (horribly formatted) Under the Hood article by Matt Pietrek.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Replies are listed 'Best First'.
Re^2: Win32::API->new( ReadProcessMemory ) not working how I'd expect
by jettero (Monsignor) on Aug 14, 2007 at 20:33 UTC

    ... usually) the process environment block which starts at 0x10000 ... Win32 processes are not made of of contiguous spaces ...

    Oh, I didn't realize any of this... It would seem I'm taking entirely the wrong approach and I'm glad I asked. I wish to dump the memory contents of a pid that is not the current pid. Hopefully CreateToolhelp32Snapshot() is more like what I want.

    Thanks.

    -Paul

[reply]
[d/l]
      I wish to dump the memory contents of a pid that is not the current pid.

      Then you will need to use OpenProcess() to get a handle to the process in question.

      CreateToolhelp32Snapshot() doesn't snapshot the memory. It will give you lists of the modules (DLLs) that are a part of your process image which you can then iterate using Module32First/Next() and obtain the load addresses and extents.

      It will also give you a list of the heaps, runtime allocated memory used by alloc/free and stacks. You then use Heap32ListFirst/Next to iterate those and obtain their start addresses and extents.

      You then use those addresses with ReadProcessMemory() to actually read the ram.

      It's a fairly involved process, but reasonably well documented. Remember you will need appropriate permissons.

      Also, be sure to suspend the target process otherwise things could change the moment after you obtain your information. If the target process contains threads, you have another sets of loops to jump through.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
[select]

        Also, be sure to suspend the target process otherwise things could change

        This is all very fascinating stuff. I'm not accustomed to windows at all. But this statement is somewhat curious, since CreateToolhelp32Snapshot() seems to take a "snapshot," so you don't have to worry about state changes — according to the MSDN pages...

        Do I definitely need to suspend it? I'll re-read that tomorrow. How accurate are those pages? They seem pretty detailed, even if they're a bit tricky to navigate. I've never really read them...

        Lastly, thanks for your help. (It would seem this isn't very perl related.)

        -Paul

[reply]

In Section Seekers of Perl Wisdom