(06-30-2011, 09:24 PM)Dimitri Wrote: [ -> ]Thus, if I poke data from one pointer using MHS's Hex Editor, these changes should also be visible on the other memory map (other pointer)...
(be careful when it comes to hacking Wii games, as there's another (bigger) MEM2 allocation that's 0x04000000 bytes long! The data to poke/hack may sometimes be inside in this allocation, like in Harry Potter HBP)
From here, if I want to find a static pointer (valid for a specific build only), I perform a Pointer Search which targets the found address/pointer, then I pick the first result that appears in green in MHS (which I assume is static in Dolphin.exe). Finally, the [Dolphin.exe + 0x???????] combination is the static pointer for this build -- personally, I note that down in MHS scripts.
Anyway, the downside of MHS is that it apparently isn't able to read 16bit/32bit data in "big endian" byte order instead of "little endian" ; this makes "greater/lower than" data searches inefficient, and requires byte-swapping all 16bit/32bit data to be read or written (for "equal/not equal to" data searches)
First, thanks for the reply!
Second...I think these parts are where you lose me...or rather, I lose you
. I'm a bit of a newbie when it comes to pointers, so forgive me for being a bit clueless. I follow you up to finding the address of the pointer through an ASCII string search of the game ID, I get 4~5 addresses and only one ending in 0000, which I add to the address list/main window. Am I supposed to be able to right click it and open it in the hex editor window? That's just causing the MHS program to lock up. I can attach the debugger to Dolphin and find what writes to/accesses the pointer just fine though. I'm editing Wii games if it makes any difference.
As for the static pointer I assume that's just a quality of life thing so I wouldn't have to search for the game ID to get the pointer each time I wanted to edit the game's memory (so long as I use the same SVN of Dolphin)? Again, kind of a newbie here so sorry if my question is a bit obvious, I just want to make sure I've got the right idea. It seems easy enough to find by just doing a Pointer Search->Exact Value->the address that I found with the game ID. That gave me two pointer address results with the value equal to the address of the game ID's string address, and I added the first one in green to the address list. Address. So say I get 0x0432A1F0. How do I use that to launch [Dolphin.exe + 0x0432A1F0]? I assume it's moreso that I do something to make MHS apply that pointer when it attaches to the program, but then what?
Basically it's just that I really don't "get" pointers, like what they mean/are or what to do with them after finding their address in the memory. My understanding of a pointer is that it is a more static approach to editing values (i.e. if you don't know the pointer then any time you re-open the program and want to edit a value in a game or some such you will have to rescan the memory and find the new address), so I think I'm missing how that translates to allowing the editing of the memory of games in Dolphin. Are there any sort of tutorials you would recommend to get some experience working with pointers and finding values from that? I'm not looking to do anything particularly difficult, just a simple money value edit that I didn't have any luck editing with the in-app cheat search tool. Thanks again for your help so far, hopefully I'll be able to learn a thing or two from you.
e: On second notice, Cheat Engine does have the option to search the MEM_MAPPED region. I'm a bit red in the face for not having noticed that, and that's probably why I've had no such luck using Cheat Engine to search for values. However narrowing values down is a bit odd. I was able to find 10 values that all consistently changed with the amount of money shown on screen, so there's definitely progress made from...scanning the right region of the memory. Changing them all at once to a different number caused them to change to something else entirely ingame, and for some reason they were stored as a byte but if I remember correctly that typically can only go up to 256 which seems a bit odd considering money can well exceed that value. You mentioned byte-swapping the number to get a proper value to search. Could that be my problem? If so do you have a particular program/calculator page you would recommend to swap the byte order? And how exactly should I go about swapping the byte order (for example if the ingame money amount is 2700, do I convert that to hexadecimal, then reverse it)? I seem to recall one user mentioning that he had to search for the remainder of the value (i.e. if he had 2700 he had to search for mod(2700,256) = 140).
e2: Success...almost. I was able to edit a low number, but it looks like I can only search for values stored as bytes this way. Through that method I'm able to flawlessly find any value as long as it's below 255. Problem is, changing the value to 2 or 4 byte makes it act erratically (changing the value type to something else like 2 byte or 4 byte still ends up capping at 255 i.e. changing it to 600 gives 88 because mod(600,256) = 88). Is this where I will need to do the byte swapping? Editing the regular byte type was simple and changed in an expected manner.
e3: Better. So I kinda figured it out again. Like you said I had to do some byte swapping to figure out how to get it to work with numbers larger than 255. Basically here's what I did for anyone curious:
1) Used a Big Endian<->Little Endian converter.
http://darkfader.net/toolbox/convert/ is an online version you can use that is very useful.
2) Found the address for my money in byte form. This is somewhat optional.
3) Plug the amount of money I had in to the Big Endian decimal value box.
4) Searched for the Little Endian decimal equivalent under Unsigned Long. Having found the amount through step 2 helped in determining this number because I could just change it there, but changing it by buying/selling something isn't really that inconvenient.
5) Get the address for money in Unsigned Long form. It only took me one sub-search.
6) Plug desired amount of money in to Big Endian decimal value, change value of Unsigned Long money address to the Little Endian decimal value.
7) Profit!
One thing I noticed is that the byte value and Unsigned Long values were very very close to one another. The byte address was 0ECD058B whereas the Unsigned Long one was 0ECD0588. I'm sure browsing the memory region might have led to a faster search but it really didn't take all that long. I used MHS in the end but I'm sure that the Unsigned Long type correlates to one of the types Cheat Engine can search for (looks like it's 4 byte, just don't forget to search with the Little Endian number, not the Big Endian/display one). I suppose it all makes sense how I could only search for byte values with the properly displayed number because a byte flipped from Big to Little Endian is still the exact same. Thanks again for the helpful post, I'm glad someone was able to help me figure this out.