get value from adress

Posts 31–43 of 43 · Page 3 of 3

no no no. i can write getmodulehandleA and add offset. but how to add offset and getmodulehandleA to readprocessmemory.

I was trying something similar this is the code I currently have but it doesnt generate the correct value

for this this example my address I am trying to access in the 9A8C90

Code:

		 
						 DWORD ptr = 0x09A8C90; //this is the memory address we are reading from
						 int value;

						 ReadProcessMemory(pHandle, (LPCVOID)ptr, &value, 4, 0);

						 textBox1->Text = System::Convert::ToString(value);

I also would like direction please toward using pointers better with this? and how easy would it be to modify this for writing and not just reading?

Originally Posted by namek303

I was trying something similar this is the code I currently have but it doesnt generate the correct value

for this this example my address I am trying to access in the 9A8C90

Code:

		 
						 DWORD ptr = 0x09A8C90; //this is the memory address we are reading from
						 int value;

						 ReadProcessMemory(pHandle, (LPCVOID)ptr, &value, 4, 0);

						 textBox1->Text = System::Convert::ToString(value);

I also would like direction please toward using pointers better with this? and how easy would it be to modify this for writing and not just reading?

ReadProcessMemory() returns a boolean for success/fail. Check it. If it's downright failing: that's a big problem.

Code:

// (I recommend you initialize 'value'  so it's not filled with junk data if/when rpm() fails)

if (!ReadProcessMemory(pHandle, (LPCVOID)ptr, &value, 4, 0))
textBox1->Text = "RPM() Failed"; // BP HERE
else
textBox1->Text = System::Convert::ToString(value); // BP HERE

If it's not failing, set a breakpoint and see if 'value' is getting the correct value. Set a breakpoint on both the calls to textBox->Text and see what value 'value' has. Have CheatEngine open to verify the value at 0x9A8C90!

-------
edit:
Writing is as easy as calling WriteProcessMemory() instead of Read. Still passing in the 'address', but this time instead of passing in a variable that will be filled with data, you pass in a variable which is used as the data source and copied to memory. The opposite of Read.
**Some memory is marked as READ_ONLY (or other types that are non-writable). Use VirtualQueryEx() and VirtualProtectEx() as needed.

well on the bright side it does not fail yet it does not carry the correct value. I tried several data types in cheat engine to make sure it wasn't converting it somehow. (its not)

my question is now when I add the address in cheat engine I input it like this

Code:

nfsw.exe+9A8C90

I was wondering if I am referencing it wrong in c++ for example? I can upload my code if you would like to glance at it

Are you getting nfsw.exe+9ABC90 from CheatEngine?

if so, nfsw.exe doesn't mean anything special to the C++ compiler. For CE it means "the main module's base address" + 9ABC90

I'm not sure how to find "mainmodule.base" in C++ or I'd help more, sorry. GetModuleHandle()?? I'm sure someone has posted code that does it somewhere in the C++ code section.

So really my code might have worked, you're just not reading the correct address.? I think cheatengine will show the addresses as module + offset or simply as raw address; one of the menu options at the top when you're on the 'memory view' page.
View-->Show module addresses

edit: Found a post with code.
h t t p : / / forum . cheat engine . org / viewtopic . php ? t = 545149
Last post. Bottom of the thread. Glancing at the code it looks correct. Has a couple pointer-dereferences that you don't need right at the end, but shows you how to get the module.base. GL. Start a new thread if you need.

code snippet from url above

credits to "Pasukaru" from url above

Code:

DWORD dwGetModuleBaseAddress(DWORD dwProcessIdentifier, TCHAR *lpszModuleName)
{
   HANDLE hSnapshot = CreateToolhelp32Snapshot(TH32CS_SNAPMODULE, dwProcessIdentifier);
   DWORD dwModuleBaseAddress = 0;
   if(hSnapshot != INVALID_HANDLE_VALUE)
   {
      MODULEENTRY32 ModuleEntry32 = {0};
      ModuleEntry32.dwSize = sizeof(MODULEENTRY32);
      if(Module32First(hSnapshot, &ModuleEntry32))
      {
         do
         {
            if(_tcscmp(ModuleEntry32.szModule, lpszModuleName) == 0)
            {
               dwModuleBaseAddress = (DWORD)ModuleEntry32.modBaseAddr;
               break;
            }
         }
         while(Module32Next(hSnapshot, &ModuleEntry32));
      }
      CloseHandle(hSnapshot);
   }
   return dwModuleBaseAddress;
}

So I tried what you said and got the raw address. I used that in the program and it gives me a value of 598504 but it still doesnt match my cheat engine for it regardless of what type i use in cheat engine. here is a screenshot of what I am looking at to better help

Originally Posted by namek303

...

erm.. I see 1150 in the "search" box, but the only address down in the list has the value "1149115102" (or whatever).

Are you successfully finding the location where the ammo value is stored? What data type is it?

--------
edit:
Now you're using 0x00B38C90 as the address? And 'value' is getting set to 598504 ? Not 1149115102

ah the value of the search bar is just the same value of the game. if u check above the search you will see 1150-nfsw.exe
I didnt use that to search more copy paste. and the value is actually float and its for my x coord in game. it should shift everytime i drive. but in my c++ it doesnt change when i drive (yep im updating the value everytime i try moving to make sure its grabbing the most current value for the address)

the data type is supposed to be float but it the value my c++ tool is giving me should match atleast one of the data types in cheat engine. from there i would just convert it. no biggie there. sadly I just cant lock on to the correct address in the tool

No. You used address 0x007 ** ???. And it DID read the correct value.

E8 21 09 00 = 598504

^^ the bytes are in reverse-order in ram (image 1)

E8210900 == 00 09 21 E8 == 598504(decimal)

---Read from address 0x00B38C90, not 0x0070DCAF ?? I'm a little confused.

Hmm I see what you mean. I ended up trying that method posted on another forum you gave the link to and it actually gives me the same value as cheat engine under 4 bytes now i need to figure out how to turn it to float which i suspect would be some type of casting.

INCASE someone else has this issue here is the code I used. you just need to add the function provided by abuckau907

Code:

						  DWORD addy = dwGetModuleBaseAddress(pid, _T("nfsw.exe")); 
						  DWORD valueAtAddress =  0x09A8C90;
						 int value=0;

						


						 if (!ReadProcessMemory(pHandle, (LPCVOID)(addy+valueAtAddress), &value, 4, 0))
							 textBox1->Text = "RPM() Failed";
						 else
							 textBox1->Text = System::Convert::ToString(value);

hope this helps someone in the future.

edit: 0x0070DCAF was the address i was pointed to when I clicked on the address in my cheat table and I clicked browse this memory region.

re-edit: converting to float was as simple as changing how I initialized it. it gave me no issues when I initialized the value to this

Code:

FLOAT value=0;

are you saying you didn't try to read 0070DCAF ? Why then did 'value' get set to 598504..the value stored at 0070DCAF?

Code:

		 DWORD addy = 0x00B38C90;

		 int value=0;

						
		 if (!ReadProcessMemory(pHandle, (LPCVOID)(addy), &value, 4, 0))
		 textBox1->Text = "RPM() Failed";
		 else
		   textBox1->Text = System::Convert::ToString(value);

Does this work? Should give the value 1149115102, like CE. ???

Actually in my previous post I show in the code box exactly what worked for me. I already turned it into a nice function. now i'm just reading how to write to the address aswell. You have been very helpful! thanks!

Originally Posted by namek303

So I tried what you said and got the raw address. I used that in the program and it gives me a value of 598504 but it still doesnt match my cheat engine for it regardless of what type i use in cheat engine. here is a screenshot of what I am looking at to better help

You didn't say what the 'raw address' was that you tested with. Based on the value you said you got, 598504, you you read 0x0070DCAF.

You should have used 0x00B38C90. (?)

Your solution (?) is better because it's based relative to a module, so it's less likely to change (on program restart and patches).

Glad it's all working now. I didn't realize. Later.