Basic Memory Scanning - Like Cheat Engine

[DarkDragon]

If it doesnt work or retrieve instantly something isn't right. I have to have unicode checked on compile options, make sure that is on.

Also debug mode slows it down a bit but should still be instant on notepad, is for me at least. Try calculator, the val is in string on xp num on win 7

Unicode is turned on, but it doesn't work.

[epidemicz]

If it doesnt work or retrieve instantly something isn't right. I have to have unicode checked on compile options, make sure that is on.

Also debug mode slows it down a bit but should still be instant on notepad, is for me at least. Try calculator, the val is in string on xp num on win 7

Unicode is turned on, but it doesn't work.

is it retrieving the pid? try hardcoding the pid in there, maybe not getting it from findwindow properly

[Thorium]

is it retrieving the pid? try hardcoding the pid in there, maybe not getting it from findwindow properly

Thats not the problem. It does open the process, it does enumerate the memory regions.

[C64]

But it does not find anything. Must take a better look tomorrow.

Are you searching for "LOL123LOL456", or did you type random text like the intro asked?

[Thorium]

But it does not find anything. Must take a better look tomorrow.

Are you searching for "LOL123LOL456", or did you type random text like the intro asked?

Dosnt matters.
The code does not work on x64. And i dont know why.

I debugged some more and on x64 it fails to enumerate the regions. GetLastError gives ERROR_NOACCESS, strange.

[Thorium]

Finaly, solved the problem.
It actualy seems to be a compiler bug/problem.

It does not work if the mbi structure is defined inside the API call on x64. However, if i define it as a pointer and allocate the memory befor the call, it works.

So here is the version, that works on x64 and includes a faster string compare.

Code: Select all

;Epidemicz - 12/30/2010 PB 4.51 x86
;====================================
;Basic Memory Scanner Test Proof
;====================================
;Compile in unicode to test on notepad

;Find Window
HWND = FindWindow_(NULL, "Untitled - Notepad")

;Get ProcessID
GetWindowThreadProcessId_(HWND, @pid)

address=0

; findNumber=0  - uncomment to use with number method
findString$="LOL123LOL456"
len=Len(findString$)
CompilerIf #PB_Compiler_Unicode = #True
  len * 2
CompilerEndIf

;Opens Process With full access
hProcess = OpenProcess_(#PROCESS_ALL_ACCESS, #False, pid)

*mbi.MEMORY_BASIC_INFORMATION = AllocateMemory(SizeOf(MEMORY_BASIC_INFORMATION))

Repeat
  result=VirtualQueryEx_(hProcess, address, *mbi, SizeOf(MEMORY_BASIC_INFORMATION))
  
  If *mbi\State = #MEM_COMMIT And *mbi\Protect <> #PAGE_READONLY And *mbi\Protect <> #PAGE_EXECUTE_READ And *mbi\Protect <> #PAGE_GUARD And *mbi\Protect <> #PAGE_NOACCESS
    sBuffer=AllocateMemory(*mbi\RegionSize)
    res=ReadProcessMemory_(hProcess, address, sBuffer, *mbi\RegionSize, @written)
   
    written - len
    If written > 0
      For x = 0 To written
          ;string method - use to find text
          ;================
          
           ;tmp$=PeekS(sBuffer+x, len) ;string length ! important
           ;If FindString(tmp$, findString$, 1)
           ;  Debug "FOUND MATCH - " + Hex(*mbi\BaseAddress+x) + "=" + tmp$
           ;EndIf

          If CompareMemory(sBuffer + x, @findString$, len)
             Debug "FOUND MATCH - " + Hex(*mbi\BaseAddress+x) + "=" + PeekS(sBuffer + x, len)
          EndIf

          ;number method - use to find number value
          ;==============
;           tmp=PeekL(sBuffer+x)
;           If tmp=findNumber
;             Debug "FOUND MATCH - " + Hex(mbi\BaseAddress + x) + "=" + Str(tmp)
;           EndIf
      Next
    EndIf 
    FreeMemory(sBuffer)
  EndIf
  
  address=*mbi\BaseAddress+*mbi\RegionSize
  
Until result=0
End

[SFSxOI]

Finaly, solved the problem.
It actualy seems to be a compiler bug/problem.

It does not work if the mbi structure is defined inside the API call on x64. However, if i define it as a pointer and allocate the memory befor the call, it works.

So here is the version, that works on x64 and includes a faster string compare.

Code: Select all

;Epidemicz - 12/30/2010 PB 4.51 x86
;====================================
;Basic Memory Scanner Test Proof
;====================================
;Compile in unicode to test on notepad

;Find Window
HWND = FindWindow_(NULL, "Untitled - Notepad")

;Get ProcessID
GetWindowThreadProcessId_(HWND, @pid)

address=0

; findNumber=0  - uncomment to use with number method
findString$="LOL123LOL456"
len=Len(findString$)
CompilerIf #PB_Compiler_Unicode = #True
  len * 2
CompilerEndIf

;Opens Process With full access
hProcess = OpenProcess_(#PROCESS_ALL_ACCESS, #False, pid)

*mbi.MEMORY_BASIC_INFORMATION = AllocateMemory(SizeOf(MEMORY_BASIC_INFORMATION))

Repeat
  result=VirtualQueryEx_(hProcess, address, *mbi, SizeOf(MEMORY_BASIC_INFORMATION))
  
  If *mbi\State = #MEM_COMMIT And *mbi\Protect <> #PAGE_READONLY And *mbi\Protect <> #PAGE_EXECUTE_READ And *mbi\Protect <> #PAGE_GUARD And *mbi\Protect <> #PAGE_NOACCESS
    sBuffer=AllocateMemory(*mbi\RegionSize)
    res=ReadProcessMemory_(hProcess, address, sBuffer, *mbi\RegionSize, @written)
   
    written - len
    If written > 0
      For x = 0 To written
          ;string method - use to find text
          ;================
          
           ;tmp$=PeekS(sBuffer+x, len) ;string length ! important
           ;If FindString(tmp$, findString$, 1)
           ;  Debug "FOUND MATCH - " + Hex(*mbi\BaseAddress+x) + "=" + tmp$
           ;EndIf

          If CompareMemory(sBuffer + x, @findString$, len)
             Debug "FOUND MATCH - " + Hex(*mbi\BaseAddress+x) + "=" + PeekS(sBuffer + x, len)
          EndIf

          ;number method - use to find number value
          ;==============
;           tmp=PeekL(sBuffer+x)
;           If tmp=findNumber
;             Debug "FOUND MATCH - " + Hex(mbi\BaseAddress + x) + "=" + Str(tmp)
;           EndIf
      Next
    EndIf 
    FreeMemory(sBuffer)
  EndIf
  
  address=*mbi\BaseAddress+*mbi\RegionSize
  
Until result=0
End

Hmmmm, Thorium, I think something is possibly wrong here. When I use your version the output is this:

Code: Select all

FOUND MATCH - 1C9280=LOL123LOL456
FOUND MATCH - 1CB3B0=LOL123LOL456

Two different memory locations from yours, for the same thing. The actual memory location at the time is 1CEEA0 (correct memory location).

[Thorium]

Two different memory locations from yours, for the same thing. The actual memory location at the time is 1CEEA0 (correct memory location).

It's correct. The string is in fact in 2 locations.

Just check it with this code:

Code: Select all

;Find Window
HWND = FindWindow_(NULL, "Untitled - Notepad")

;Get ProcessID
GetWindowThreadProcessId_(HWND, @pid)

hProcess = OpenProcess_(#PROCESS_ALL_ACCESS, #False, pid)

sBuffer=AllocateMemory(26)
res=ReadProcessMemory_(hProcess, $2E43E0, sBuffer, 24, @written)

Debug PeekS(sBuffer)

Dont forget to change the address.

[DarkDragon]

But it does not find anything. Must take a better look tomorrow.

Are you searching for "LOL123LOL456", or did you type random text like the intro asked?

I typed in "LOL123LOL456" in notepad. The PID is correct and hProcess is correct but result is 0. Thorium's code works like a charm. The two locations are right.

[SFSxOI]

How do you know both locations are correct? Are you sure? How can that be? If I use a memory editor and look at the location that appears for what i posted I do not see it in either of the two locations, however I do see it at the memory location that reported from the original code. How odd.

[Thorium]

How do you know both locations are correct? Are you sure? How can that be? If I use a memory editor and look at the location that appears for what i posted I do not see it in either of the two locations, however I do see it at the memory location that reported from the original code. How odd.

Do you use a x64 system?
And just check it with the code, i posted. It just reads out the string from the address.

The original code may show you wrong results on a x64 system. If executed as x86.

[SFSxOI]

How do you know both locations are correct? Are you sure? How can that be? If I use a memory editor and look at the location that appears for what i posted I do not see it in either of the two locations, however I do see it at the memory location that reported from the original code. How odd.

Do you use a x64 system?
And just check it with the code, i posted. It just reads out the string from the address.

The original code may show you wrong results on a x64 system. If executed as x86.

LoL

Thats it then. I'm using x86. So your code is only 64 bit then.

So then, for 64 bit, if for some reason one wanted to edit the memory at those locations, your saying that both locations from the "64 bit" version would need to be edited?

[Thorium]

LoL

Thats it then. I'm using x86. So your code is only 64 bit then.

So then, for 64 bit, if for some reason one wanted to edit the memory at those locations, your saying that both locations from the "64 bit" version would need to be edited?

Thats strange. It should work work on x86 as well. Did you tested the other code i posted, to read out the adresses?

Actualy there is nothing different about the search for the adress, only a different way to compare the strings and removed the max address.

[SFSxOI]

LoL

Thats it then. I'm using x86. So your code is only 64 bit then.

So then, for 64 bit, if for some reason one wanted to edit the memory at those locations, your saying that both locations from the "64 bit" version would need to be edited?

Thats strange. It should work work on x86 as well. Did you tested the other code i posted, to read out the adresses?

Actualy there is nothing different about the search for the adress, only a different way to compare the strings and removed the max address.

got it working ok now. a stupid copy and paste screwup.

But there is another odd thing I just noticed. If I add something to the .txt file so it now looks like this:

Code: Select all

LOL123LOL456

this is a test

The output is like this:

Code: Select all

FOUND MATCH - 289280=LOL123LOL456this is 
FOUND MATCH - 28B3B0=LOL123LOL456

should not both memory locations contain the same thing ? (the addition of the "this is" part)

If I remove the "this is a test" part from the .txt file, I get this:

Code: Select all

FOUND MATCH - 289280=LOL123LOL456this is 

Notice there is only one memory location given this time and the "this is" is still there.

It looks like its grabbing memory beyond the length of the string being searched for.

The original version by epidemicz doesn't do this.

[Thorium]

should not both memory locations contain the same thing ? (the addition of the "this is" part)

I dont know, for what notepad holds a additional copy of the string. Could be for the undo feature.