Touhou Game Memory Locations/ Cheat Table Question

[Zarakava]

So I've been working on my own version of a Touhou (Windows Era) Utility that's basically a Score Run tracker. It does a +- track of your score at each point so you can see if you're on track to beat your old score. It's kinda meh right now, so I've got a few quick questions.

I don't do a ton of memory stuff, but I know the locations are always like the .exe + some value. Does the .exe always attempt to load in the same place? On the four computers I've tested on, it did, but that's not really a big sample.

The other real question is if there's a memory flag or something to tell what stage the player is on. Right now I've been ticking the counter with a press of the "tilde" key. But doing that basically requires using a "keylogger", and for security concerns, I don't want to distribute a keylogger if I get this to a point where I want the community to take a look at it.

So yeah, that's basically what I've got for now.

EDIT: Attaching some screenshots just because.

[EthanSilver]

I don't do a ton of memory stuff, but I know the locations are always like the .exe + some value. Does the .exe always attempt to load in the same place? On the four computers I've tested on, it did, but that's not really a big sample.

Are you attempting to get those by hand? Don't do that. I'm assuming you're coding this on windows, so look into GetModuleHandle. This will give you the starting offset of the game's module (check in the task manager for the name to use).

The other real question is if there's a memory flag or something to tell what stage the player is on. Right now I've been ticking the counter with a press of the "tilde" key. But doing that basically requires using a "keylogger", and for security concerns, I don't want to distribute a keylogger if I get this to a point where I want the community to take a look at it.

I'm not sure I understand your question. Are you looking for the offset that stores the ID of the current stage? If so, this differs from game to game. What do you mean by "counter" ("ticking the counter"), then...?

As far as "keyloggers" go, this is not a keylogger. Trapping keyboard input is done by myriad programs. A keylogger does so without the user's knowledge, generally with malicious intent. I'm sure nobody would mind something like this the least bit.

[Necrotek]

I'm not sure I understand your question. Are you looking for the offset that stores the ID of the current stage? If so, this differs from game to game. What do you mean by "counter" ("ticking the counter"), then...?

I think by "counter" he was talking about a trigger button which increases the "current stage" value in his accounting program so his program has to listen to the whole player keyboard input to know when the specified button was pressed. And I'm pretty much sure that he understands that the memory variable offsets (or something that can let you know the stage number) differ from game to game; he was talking about the situation that in some games offset for variables isn't constant - it can be different depending on the OS (for example, native windows or using wine under linux), computer, or even different each time you run the game on the very same computer.

[EthanSilver]

he was talking about the situation that in some games offset for variables isn't constant - it can be different depending on the OS (for example, native windows or using wine under linux), computer, or even different each time you run the game on the very same computer.

This case refers to when a game needs to allocate memory dynamically (eg, the C "malloc" function or the C++ "new" operator, for instance). The OS has to allocate memory but there's no guarantee that a favored memory location won't already be in use, so the offset is unlikely to ever be the same. For instance, the games before PoFV all allocate the game object dynamically. The ones after use static offsets for it, making tracking down values with, say, Cheat Engine much easier. Imperishable Night, for instance, stores a pointer to the game object at 0160F508, so it's never the same.

In regards to stages, the player object (within the game object) generally contains this info. In UFO for instance, it's 004B0CB0. The player object starts at 004B0C40 and the entry is 0x70 bytes in. The player object having a static offset, this means the stage is ALWAYS at 004B0CB0. On the other hand, Imperishable Night's game object is pointed to at 0160F508 and the player object, 0160F510. The offsets containing these two pointers are static, but the pointers themself obviously are not. You would have to read the offset at 0160F508 or 0160F510, follow it to the game or player object (whichever holds the stage ID), and then add 'n' to it to get the offset of the stage ID (sorry, I haven't mapped out enough of IN yet to give you its offset ^^; ).

In short, you can use most offsets you'll find in MoF+ safely but games before that, you'll have to find the pointer to whatever structure you're looking into (lil' bit of searching required; there's no "magic bullet" for this sadly...) and follow it around in order to get to whatever offset you need.

[Necrotek]

Funny. Before I saw your post, I gave it a try to find stage values for IN, UFO and DDC and found them but they started at 0 value and up instead of 1. I tried your values, and the one for UFO worked for me but for IN, just as expected, didn't.
But anyway, stage numbers can be found, and they don't change if you use applocale or different language version.

[EthanSilver]

I tried your values, and the one for UFO worked for me but for IN, just as expected, didn't.

Where'd I provide the offset for IN's stages? Those are pointers to the player/game objects. Please read the post.

[Necrotek]

Yeah, I already noticed that I read it wrong. I just wanted to edit my post and you already pointed at my mistake

Hm, I guess I don't have much experience in how the memory works. If the stage number is really stored in player object and player object starts almost at score value address then... that's strange. Both in IN and PCB stage numbers (starting from 1 for PCB and starting from 0 for IN) are stored in completely different place, a lot earlier than the position of player object in memory. I tried to look for offsets close to those numbers but.. didn't manage. I don't have much of ideas of how to track down necessary offsets.

[Zarakava]

First of all, thanks for the responses. I made a good chunk of progress on stuff yesterday, and I can clarify a lot of what I'm doing.

First of all, I'm working in C#. I started originally in C++, then realized I can't do GUI work for garbage in that, so switched to C# so I could use Visual Studio.

Secondly, I did find the Stage memory location, which I don't know why I couldn't find it on my first look. So now I don't have to worry about the "keylogger" stuff.

But here's where we get tricky again. I'm currently working on EoSD, because that's my favorite one, and I originally intended this just to be an EoSD utility. I have all the relative locations found, in terms of where they load based on the th06.exe location. But from what I can tell, this .exe memory location is not always going to be the same, even though it is/has been the same the four computers I have access to test on.

The code I've been using is basically

Code: [Select]

var array = Process.GetProcessesByName("th06e");
                if (array.Length != 0)
                {
                    EoSD_Process = array[0];
                }
                array = Process.GetProcessesByName("th06");
                if (array.Length != 0)
                {
                    EoSD_Process = array[0];
                }

                processHandle = OpenProcess(PROCESS_ALL_ACCESS, false, EoSD_Process.Id);
                TotalScore.Text = BitConverter.ToInt32(ReadMemory(ScoreLocation, 4, this.processHandle), 0).ToString("D10");


Where as of right now, ScoreLocation is 0x0069BCA0, which it has been consistently on these four computers. This is also the location CheatEngine gives me. As far as I know, this is a static memory location, and is not offset by the EoSD process, unless I'm just flat out wrong, and it works because that is just the offset from the EoSD process, in which case I have the meat of the EoSD utility done, and just have to do some touchups.

Is this sounding about right? If not, how do I find the EoSD process starting point, so at least for that game I can set the offsets relative to that, as I think EoSD always has the same offsets for the score/live/etc fields

[Necrotek]

In case of GUI for C++ program I could recommend Qt. But I guess it's a little bit too late to switch to
What about addresses, I might try to do my research but it seems EthanSilver is a lot more knowledgeable about it so I'd wait for his opinion.

[EthanSilver]

Is this sounding about right? If not, how do I find the EoSD process starting point

A HMODULE or HINSTANCE, or other such types, both contain the same thing (at least in 32bit+ windows): the module's starting offset. Any method you're using that returns one of these (ex, GetModuleHandle, OpenProcess, etc..) is giving you the start offset of the executable. Any method called on a handle will take it into account, eg ReadProcessMemory doesn't just start reading from "0x00000000".

I am unfamiliar with C#, but any win32 API method can be called from it same as with c++ (though the exact means varies; something about using "pinvoke" as far as I could tell). Your code acquires a handle and uses it to invoke ReadMemory - you are already using EoSD's "starting point" (ReadMemory is doing so for you using the handle you get in the previous line) so it should be fine as-is.

[Zarakava]

Excellent then. Hopefully this should work on pretty much everything then.

I've got about one or two things left on EoSD, then I'll start looking at the others