ReadProcessMemory

Feb 3, 2012 at 8:40pm
The size of the value returned is too small, I'm trying to find out why myself using Google but would speed things up if I can get an answer here.
1
2
3
4
5
6
7
8
9
10
void hexWin::HCWrite(HANDLE p, DWORD x, int s, u32 v) {
	u32 a = FlipAddress((u32)x, s, endian);
	WriteProcessMemory(p, (void*)a, &v, s, NULL);
}
wxString hexWin::HCRead(HANDLE p, DWORD x, int s) {
	u32 a = FlipAddress((u32)x, s, endian), v;
	ReadProcessMemory(p, (void*)a, &v, s, NULL);
	wxString t; t.Printf(wxT("%X"), v);
	return t;
}

I've checked all the values going into HCRead() and they're fine, HCWrite() is responding the way it should so I'm a bit confused as to what happened that caused this error. BTW way my test is Vaan's Max HP to his Current HP in Final Fantasy 12 on PCSX2 0.9.7+, fixed address and confirmed to be working on Renegade64/Ex (to which this shall be a sequal tool - I'm not viper BTW, just got his permission to do this).
Feb 3, 2012 at 10:25pm
You say you verified the values, but you don't show the actual values. Please show that. For example, I see that you use variable 's' for the data size. Since you are reading into a u32 (which I presume is a typedef for unsigned int using a compiler where int is 32 bits), I don't see the need to receive this data size via a parameter. So maybe an explanation of the methods and their parameters is in order.

Also note that you are NOT checking the result value of ReadProcessMemory(). It returns zero if it fails, and if it does, you can get an error code with GetLastError() and eventually an error message via FormatMessage().

Oh, and you should take advantage of the last parameter in the Windows API functions. They'll tell you if you got the expected number of bytes.
Last edited on Feb 3, 2012 at 10:26pm
Feb 3, 2012 at 10:42pm
for both functions the values are the same (except for v of course), p is grab once then passed through all functions thereafter, x is a variable address - in this case it is 0x0054E210 appended to RAM start for HCRead() and 0x0054E250 appended to RAM Start for HCWrite() since it is a Infinite HP code which is copying from 1 address to another, s is constantly 4 at the moment because none of my ported codes are smaller than DWORD.

My code analyser strips out other data from a compounded code and splits it into a class that can be used much more easily by the calling function which in this case is a Hook function. At the moment I'm implementing the RAM editor to enable me to see what output HCRead() gives with a hard-coded number (1).

Edit: Responds fine to that, I think that maybe the value I was looking to see copied was Max Field HP and not Max Natural HP, I'll take a look tomorrow after work. Edit: I was right
Last edited on Feb 4, 2012 at 3:10pm
Topic archived. No new replies allowed.