Posted: Sun Dec 09, 2012 6:13 pm Post subject: Cheat Engine to Nintendo 64 Emulator
I'm wondering if its possible for cheat engine to resolve addresses to align with Big Endian systems such as the N64. I wrote an app that uses an offset to resolve the internal address of the N64 based on Cheat Engine address. The problem I'm running into is that the N64 is Big Endian, and x86 is Little.
With that being said here is an example of the problem:
Code:
We get an offset of the entry point in N64 for the game (Nemu64 provides the address) minus the equivalent we find in x86 memory with an array of byte scan for the value at the N64 entry point in reverse.
Lets say N64 is (8004B400) and CE is 5344B400 and offset between is 2CC00000.
Now, say we have an address range 800500FC - FF in N64 memory where the value 01000000 is stored. The value 01 would represent my ammo.
So in the game we see 01 and use cheat engine to search for that value as byte.
We resolve an address like 534500FF due to it being Little Endian we are reading from x86 and CE sees the value as 00000001.
When using an offset to resolve the difference it gives the address 800500FF which is incorrect due to it being stored in reverse.
It should be 800500FC in N64 to mod the value of 01.
Is there any way around this? The best I can do is to provide addresses for all 4 bytes and have the user guess which one it is without accurately being able to adjust the offset based on the underlying value size. Is there any way to make cheat engine resolve Big Endian instead of Little? Any help is appreciated.
That is a very cool feature (being able to add like that on the fly), but unfortunately did not resolve my problem as the address itself still resolved as the FF instead of FC like it should. I am starting to wonder if this is even possible due to the reverse storage in Big Endian. Any other suggestions? Should I just let it go? lol... I may do a video about it to show exactly my steps, and what I hope to accomplish (quite a few steps to this process).
Joined: 09 May 2003 Posts: 25785 Location: The netherlands
Posted: Mon Dec 10, 2012 3:17 am Post subject:
I just read it again and i think you're doing something wrong. (Different version of the game,or math error, like wrong base)
One byte values are not affected by endian
If address 534500FF contains the 1 byte value 1 then 534500ff- 2CC00000 is the address on the n64 _________________
Do not ask me about online cheats. I don't know any and wont help finding them.
Like my help? Join me on Patreon so i can keep helping
I just read it again and i think you're doing something wrong. (Different version of the game,or math error, like wrong base)
One byte values are not affected by endian
If address 534500FF contains the 1 byte value 1 then 534500ff- 2CC00000 is the address on the n64
I recorded a video of me performing the routine in glorious 1080p for you . Let me know if you spot my error. Btw, the video depicts me going from Nemu64 to PJ 64, but I get the same result just sticking with Nemu64 as well. I did not show it within the video, but I also resolved the same address with a 2 byte search. Also, using the new types I added via your suggestion resolve the same address. I have tried this in both 32/64 bit OS versions with the same result.
Also, using the new types I added via your suggestion resolve the same address.
That's the abnormal part. Unless you disabled the fast scan option, using the "2 Byte Big Endian" type should yield NO result (or bogus results like display value).
Try disabling fast scan (because the good address is an odd number) and using the "2 Byte Big Endian" in your scans.
Otherwise your ammo seems to be a 2 byte integer, cheat engine found the least significant byte and it seems your cheat editor wants the address of the most significant byte so you have to subtract data_size-1 to the address found by cheat engine.
memory map:
802a5a01 = 00 <-this is the address of your BIG ENDIAN 2 byte ammo. The cheat editor wants this address.
802a5a02 = 55 <- cheat engine found this address with single byte searches
802a5a03 = ??
If ammo were a 4 byte variable it would be:
802a5a01 = 00 <- the cheat editor this = cheat engine address-(4-1)
802a5a02 = 00
802a5a03 = 00
802a5a04 = 55 <- cheat engine would find this address when doing single byte searches
802a5a05 = ??
(In both examples I didn't take virtual base conversion into account)
Also, using the new types I added via your suggestion resolve the same address.
That's the abnormal part. Unless you disabled the fast scan option, using the "2 Byte Big Endian" type should yield NO result (or bogus results like display value).
Try disabling fast scan (because the good address is an odd number) and using the "2 Byte Big Endian" in your scans.
Otherwise your ammo seems to be a 2 byte integer, cheat engine found the least significant byte and it seems your cheat editor wants the address of the most significant byte so you have to subtract data_size-1 to the address found by cheat engine.
memory map:
802a5a01 = 00 <-this is the address of your BIG ENDIAN 2 byte ammo. The cheat editor wants this address.
802a5a02 = 55 <- cheat engine found this address with single byte searches
802a5a03 = ??
If ammo were a 4 byte variable it would be:
802a5a01 = 00 <- the cheat editor this = cheat engine address-(4-1)
802a5a02 = 00
802a5a03 = 00
802a5a04 = 55 <- cheat engine would find this address when doing single byte searches
802a5a05 = ??
(In both examples I didn't take virtual base conversion into account)
Nice work Gniarf!
Looks like fast scan has been trolling me all along. I never really looked into what it did:
Code:
Fast scan on as default: You can check this box to make all of your memory searches aligned, unless you state otherwise in the main interface. This will cause all memory scans to only return addresses aligned to a 32-bit boundary (or ending in 0,4,8,C / divisible by 4). This will dramatically speed up memory scans, and is good for 99% of cases. Rarely though, you may miss key addresses with this turned on.
Looks like I fell into the 1 % with that odd address. Is it safe to assume that based on the biggest search type (2 or 4 byte) that returns a value is the one to use in the calculation? Also, will cheat engine always return the correct address in every situation (as pictured above) with fast scan disabled?
With this one I found that it matched a 4 byte Big Endian match, but only with hex selected:
The actual N64 address is 802D39FC that controls the option screen menu selection. Does this mean that since it resolved on a 4 byte Big Endian search that it is correct? I also found the same value on a 2 byte search with the same address. I guess my question is do I use the biggest resolved search type to subtract from my address? I wish I could automate this, but without knowing the underlying data type I'm not sure it is possible.
Is it safe to assume that based on the biggest search type (2 or 4 byte) that returns a value is the one to use in the calculation?
No it's unsafe. For example if cheat engine finds 1 on a 4byte BE, it means 00 0000 01 in memory, but it could be a 2byte BE coincidentally preceded by another 2 byte BE that is equal to 0. Or same reasoning with single bytes.
Abystus wrote:
Also, will cheat engine always return the correct address in every situation (as pictured above) with fast scan disabled?
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Reputation: 1
Reputation: 470
. Let me know if you spot my error. Btw, the video depicts me going from Nemu64 to PJ 64, but I get the same result just sticking with Nemu64 as well. I did not show it within the video, but I also resolved the same address with a 2 byte search. Also, using the new types I added via your suggestion resolve the same address. I have tried this in both 32/64 bit OS versions with the same result.
.
