Scanning Memory

[Don Ewald]

Greetings!

I'm looking for some guidance on how to locate a virtual memory address. If I use a memory editing program like MHS, GameShock or such I can easily find the address that I'm looking for. Once I have that address I can successfully read and write to that address with some functions that'll use OpenProcess and ReadProcessMemory/WriteProcessMemory from within a compiled PB program. Unfortunately, this address will sometimes change based on what virtual memory address block is assigned to it's data.

If I use some of the code that I think pertains to my situation; like,

http://www.powerbasic.com/support/pbforums/showthread.php?t=37741.html

...I can see all the modules that make up the program that I'm examining; but, it doesn't include the pertinent section that I'm attempting to examine as it's not a DLL or such. If I use Sysinternal's VMMap program I can easily locate the pertinent data (specifically, starting address and size); but, I'm not sure how VMMap gets the data across the bottom half of the screen. I'm sure that I can walk through all memory addresses using ReadProcessMemory in small chunks so it doesn't fail; but, that seems to be silly. Any ideas on a better way to gather the data that VMMap shows?

[Michael Mattias]

Disclaimer: I have never used "VMMAP" so I could only go by the linked picture.

Looks like the ToolHelp functions can do this for you. The MODULEENTRY32 structure includes base address and size members. Just call Module32First/Next against your hSnapshot to get an array of these structures for the process of interest.

Unfortunately, this address will sometimes change based on what virtual memory address block is assigned to it's data.

Some of us (e.g. moi) consider that a small price to pay for benefits of dynamic link libraries.

[Don Ewald]

Greetings Michael!

You'll have to forgive me as I still don't quite understand. I've read several bits of code that gather the modules of a process and lists them. One of yours has actually been one of my test programs for a while now:

http://www.powerbasic.com/support/pbforums/showthread.php?t=23884

...but what if what I'm looking for is not found in these listings or does not fall within those memory addresses? I've taken the modBaseAddr and the modBaseSize of the MODULEENTRY32 TYPE and the memory address that I want does not fall within any of the listed modules.

Am I supposed to assume that the address I want may be between these modules? Is there a way to enumerate these spaces and what they represent...similar to what VMMap is showing?

[Michael Mattias]

but what if what I'm looking for is not found in these listings or does not fall within those memory addresses

Um, what are looking for? Maybe you don't need to go thru all this memory scanning stuff. "Scan a process' memory" is a HOW.

That's not to say "scan a process' memory" won't be the best (only?) HOW, but until we have the WHAT you have no options.

MCM

[Wayne Diamond]

Don,

This is a simple example of how to enumerate the memory sections within a process (every memory section used by every module/DLL etc within a process, including the main executable) ...

This should basically produce the same result in terms of memory ranges that you'd see in OllyDbg (my fave usermode Win32 debugger - www.ollydbg.de) if you go to View > Memory (or press Alt+M), so fire that up -- attach OllyDbg to your target process, and then you can compare its Memory results with yours

#COMPILE EXE
#INCLUDE "win32api.inc"

'TYPE MEMORY_BASIC_INFORMATION
'  BaseAddress AS DWORD
'  AllocationBase AS DWORD
'  AllocationProtect AS DWORD
'  RegionSize AS LONG
'  State AS DWORD
'  Protect AS DWORD
'  dType AS DWORD
'END TYPE
  
 
SUB MemoryMap(BYVAL hProc AS DWORD)
LOCAL mem AS MEMORY_BASIC_INFORMATION, lAddr AS DWORD, memlen AS DWORD
lAddr = 0: memlen = SIZEOF(mem)
DO
 IF VirtualQueryEx(BYVAL hProc, BYVAL lAddr, mem, BYVAL memlen) = 0 THEN EXIT DO
  SELECT CASE mem.State
     CASE %MEM_COMMIT:  STDOUT "Addr=" & HEX$(mem.BaseAddress,8) & "  Size=" & HEX$(mem.RegionSize) & ", Type=" & STR$(mem.dType)
         WAITKEY$
     CASE %MEM_FREE, %MEM_RESERVE: 'STDOUT " MEM_FREE"
  END SELECT
 lAddr = lAddr + mem.RegionSize
 ZeroMemory BYVAL VARPTR(mem), BYVAL memlen
LOOP
END SUB
 
 
FUNCTION PBMAIN() AS LONG
LOCAL dwPid AS DWORD, hProc AS DWORD

dwPid = 1234 '<-- TARGET PROCESS ID

hProc = OpenProcess(BYVAL %PROCESS_QUERY_INFORMATION, BYVAL 0, BYVAL dwPid)
IF hProc = 0 THEN
    STDOUT "OpenProcess failed. (Maybe try elevating to SeDebugPrivilege)"
    WAITKEY$: EXIT FUNCTION
END IF
MemoryMap BYVAL hProc
CloseHandle hProc
STDOUT "Done"
WAITKEY$
END FUNCTION

Cheers,
Wayne

[Michael Mattias]

Wow. VirtualQueryEx() makes this pretty straightforward.

Thank you for posting same.

MCM

[Wayne Diamond]

Greetings Michael!
You'll have to forgive me as I still don't quite understand. I've taken the modBaseAddr and the modBaseSize of the MODULEENTRY32 TYPE and the memory address that I want does not fall within any of the listed modules.

This is because the toolhelp32 functions simply show the range of the module as loaded into memory (for example - the .data, .text, .rsrc etc sections, all of which are loaded between ME32.modBaseAddr to (ME32.modBaseAddr + ME32.modBaseSize)) -- basically how the executable module (exe, dll etc) is mapped into memory from disk.

It DOES NOT include other sections of memory allocated by calls such as VirtualAlloc, as these memory sections do not reside within the range of any particular module - they 'float' outside in empty space.

For this reason you need to use VirtualQueryEx to traverse through each memory section, as my code above demonstrates. It is a 'walk in the park' though. Again simply fire up OllyDbg, attach it to any process and click View > Memory (or press Alt+M) to get a good overall view of this VirtualQueryEx memory map - the addresses and sizes displayed should be the same as that generated by my code. (I actually used Ollydbg to debug ollydbg.exe to figure out how it was doing this ... felt a bit silly when I found out it was simply traversing VirtualQueryEx)

[Don Ewald]

Bravo Wayne!

This is exactly what I needed to sink my teeth into. Much thanks!

[Michael Mattias]

>This is exactly what I needed to sink my teeth into

Oooh-Kaaay...... so, pray, what mischief be thee up to?

[Don Ewald]

Oh, goodness, nothing mischievous. There's an old bit of gaming software, Forgotten Realms Unlimited Adventures, that by writing to its memory I can expand its capabilities.

[Michael Mattias]

Ah. Hacking.

[Wayne Diamond]

Michael, you've never really played a game before until you've patched memory to give you $4,294,967,295 on Level 1

[Michael Mattias]

I don't do stuff like that..

I think that means I am presently between the ages of "too old to be playing games" and "too young to be playing games."

[Don Ewald]

Nothing wrong with that, Michael. To each their own.

[Gösta H. Lovgren-2]

Hmmmm..., For some reason the term "Fuddy-Duddy" comes to mind. Don't know why.

===================================
"In the end, everything is a gag."
Charlie Chaplin (1889-1977)
===================================

[Michael Mattias]

>For some reason the term "Fuddy-Duddy" comes to mind. Don't know why

Are you a "lurking-only" member of the EDI-L group on Yahoo Groups (I know you don't post) ?

Someone called me that same thing there just yesterday!

[Gösta H. Lovgren-2]

>For some reason the term "Fuddy-Duddy" comes to mind. Don't know why

Are you a "lurking-only" member of the EDI-L group on Yahoo Groups (I know you don't post) ?

Someone called me that same thing there just yesterday!

Hmmm... If it quacks like a duck .....

======================================
"The secret of success is
to know something nobody else knows."
Aristotle Onassis (1906-1975)
======================================

[Wayne Diamond]

Michael,
If there weren't any legitimate reasons for patching memory in processes Microsoft wouldn't have bothered creating WriteProcessMemory (or related functions like OpenProcess, DebugActiveProcess, VirtualQueryEx etc etc), and calling them doesn't necessarily make you a black-hat hacker.

[Michael Mattias]

Hmm...

>> .. Fuddy Duddy
> .. if it quacks like a duck...

>>... Hacking....
> .. black-hat hacker


If it quacks like a duck?

[Michael Mattias]

Just for the record: I do not consider 'hacking' to be automatically A Bad Thing.

It can be fun to 'see what happens when I do <something>.'

I just wish when people ask for help they would explain what they are trying to accomplish... absent other information I tend to assume they are 'solving Real World problems' and respond accordingly.

MCM