Cheat Engine

[pedrohh]

Hi everyone! First post here, so apologies if I'm doing something wrong.

I'm new to Cheat Engine.

I'm running Super Smash Bros Ultimate on the Ryujinx emulator and have already found the dynamic address for the player's HP / stocks (it works during the current emulator session). I want to read that value from a Python script, so I need the static base pointer that, combined with offsets, resolves to the dynamic HP address.

Problem: I can't find the base pointer. I tried Pointer Scans, but they take a very long time and return no results, (I think this might be related to the fact that I’m using an emulator). I also manually inspected memory regions and couldn't identify the nex level pointer. I might be doing something wrong here.

Questions:

How can I locate a static address (with the full chain of offsets) that gives me the HP / stocks value?

Are there other approaches that could also lead me to the dynamic address I’m looking for (for example, AOB scans)?

Thanks in advance for any practical tips or suggestions.

[ParkourPenguin]

This isn't something someone new to CE should be doing, but I'll post my thoughts.

You're working with two different architectures. There's your native architecture that the emulator is running on and the emulated architecture that the game is running on. You'll have to find pointer paths in the context of both architectures.
In the emulated architecture, the simplest case is that the value you found is static (in the context of the emulated architecture). This means the value's location in the memory space of the emulated architecture doesn't change. This is common to see in older consoles (e.g. gameshark codes for gameboy / ds games), but I'm not sure if newer consoles use random dynamic memory allocation. If they do, then you'll have to make your own pointer scanner that correctly handles pointers for the emulated architecture (probably just big endian, maybe bit packing).
Regarding the emulator itself, it's easier. Find the base address of the relevant emulated architecture's memory region (debugging can probably lead you to it if you know how to read assembly) and do the usual pointer scan for that address.
Then put those two paths together. In the simple case where the value is static in the emulated architecture, this simply means adding a very big offset as the final offset (could be gigabytes). If it's not static, then resolve the rest of the pointer path through the emulated architecture yourself.

There could be esoteric implementations of the emulator that do weirder things. Maybe the pointer scanner would just work in those cases, or maybe there would still be really big offsets that prevent it from working.


Other approaches:
I'm against making an aobscan for mutable data. Obviously, mutable data can be changed. Finding a pattern that doesn't change is adverse to that. Still, it's a simple method I've seen many people do, so maybe I'm just being unnecessarily antagonistic.

Any emulator for a modern console probably JIT-compiles the emulated architecture's machine code. You can do an AOB injection that copies the address to some memory you control (search "injection copy"), effectively making your own "static pointer". Doing this from python is more annoying: you'll have to know how to assemble instructions correctly (e.g. RIP-relative addressing). Also, finding a unique aob pattern for the code might be challenging too.

Some emulators implement a GDB stub that might be useful for debugging the emulated architecture. I've never played around with that before and haven't put much thought into what can be done with it.

[pedrohh]

Thank you for your reply, it helped me to understand a lot better.

I actually found what I suspect to be the host address for the emulator’s allocated memory. I got the address by looking at the instructions that write some variables, and all of them have the same offset from the same address, which I suspect to be the start of the emulator memory.

Damage Player1
2C8E3782D40

mov [r8+rcx],r9d
R8=000002B74F330000
RCX=0000001194452D40

Damage Player2
2C8E3792680

mov [r8+rcx],r9d
R8=000002B74F330000
RCX=0000001194462680

Coins (menu)
2C8A0A82B9C

mov [rsi+r8],r9d
RSI=000002B74F330000
R8=0000001151752B9C

In this example it would be 0x2B74F330000.

My problem is that I can't find a pointer chain that resolves to 0x2B74F330000; pointer scans don't show any results. When I try to scan for unknown initial values, it gives me an error saying that it is trying to allocate too much memory.

How do I find the base address + offset that leads to 0x2B74F330000? I would prefer to get the pointer chain instead of doing an AOB scan to find the address.

Most values I find are either 8-byte (QWORD) or float.

On the emulator side, the memory also appears to be dynamically allocated, so I'll try a manual multi-level pointer scan.

[ParkourPenguin]

Yes, that common value 0x2B74F330000 looks like the base address of the emulated memory.

A pointer scan for that address is the easiest thing you can do. Try increasing max level (e.g. 7+) and/or max offset (e.g. 8191+). "Max different offsets per node" can speed up scans significantly, but might cause you to miss valid results.

See this video for more information on how to use the pointer scanner:
https://www.youtube.com/watch?v=3dyIrcx8Z8g

If you really need to, you can try to track the pointer path down via debugging. i.e. find out where the register holding the address gets its value from, then repeat with the next value until you get to something static. This requires basic knowledge of reverse engineering- e.g. calling conventions.

I see the primary language ryujinx was written in is C#. A few years ago, I couldn't find a pointer path for a value in a game that was written in a similar way (unity game, I think). I was curious enough that I spent the time to track it down manually through debugging, and I found that the real "base address" was some immediate in an instruction that got JIT compiled. The pointer scanner can't find that- nothing about it is static.

CE has some mono and dotnet features that might help (look at the Lua files in the autorun folder), but that'll be even tougher to replicate in a Python script. If you don't want to bother learning that mess and the pointer scanner can't find any incidental or ancillary paths, you'll have to do an aobscan. If you can find the real "base address" as an immediate, you won't have to inject code; otherwise, do an aob injection on some instruction that accesses the address you want and copy it ("injection copy").

[pedrohh]

I actually found an instruction in the memory viewer that looks like this:
mov eax, 0x2B74F330000

I think that implies the memory address is immediate, so pointer scans probably won’t work. But I’ll try it a few more times anyway.
I’m also willing to learn how to use the debugger, so I’ll give that a shot too.