SMBX Memory Map

[Kevsoft]

I recently noticed that nobody really knows where to look when it comes to memory locations, memory offsets and (thanks for Rednaxela) NPC AI States/Timers. That's why I opened the

SMBX Memory Map Wiki Page

at the PGE Wiki.

This Section Contains:

• Global Memory Addresses
• Struct offsets (e.g. NPC struct offset, Player struct offset)
• NPC AI States/Timers

However, this is lots of work and I am inviting everybody to contribute.

This is far from complete and I am thanking everybody who helps with this lists!

[Rednaxela]

Ahh, it's nice to have that in the form of a wiki page. I'll probably be adding some things tonight.

Nice stuff adding to the list of known NPC state/timer information there Kev.

I may even end up searching for new memory regions where SMBX stores certain things that aren't part of the currently known structures... Have some ideas for some specific things I want to look for...

[Rednaxela]

So tonight I decided to have some fun trying out "windbg" for the first time to reverse engineer some previously unknown sections of the SMBX memory map.

In case any folks find this stuff interesting, I've documented the process of how I went about it. Except for the Lua bit at the end, the 'code' sections here are Windbg commands, followed by their output in indented form.

Set "speed=3.241592653589793238" in npc-1.txt
Search for it as double (0xE5 0xF9 0x10 0x21 0xC8 0xEE 0x09 0x40)... no luck.
Search for it as float (0x41 0x76 0x4f 0x40)... found it!

Code: Select all

s -b 0xb25000 0xFFFFFFF 0x41 0x76 0x4f 0x40
	00000000`00cdca3c  41 76 4f 40 00 00 80 3f-00 00 80 3f 00 00 80 3f  AvO@...?...?...?

Checking memory type...

Code: Select all

!address
	+ 0`00be0000   0`00ce0000   0`00100000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE   Heap32 [ID: 0; Handle: 0000000000be0000; Type: Segment]

Yes, it's heap.

Next, find what points to it within the statically allocated region of SMBX (0xb25000 - 0xb47000):

Code: Select all

s -b 0xb25000 0xb47000 0xca 0xcd 0x00
	00000000`00b25c19  ca cd 00 2d 01 00 00 00-00 00 00 0b 00 00 00 01  ...-............
dd 0x00b25c18 L1
	00000000`00b25c18  00cdca38

Got a hit, and puts "speed (float)" for npc-1 at 0x+04...

Add the value to npc-2.txt as well now...

Code: Select all

s -b 0xb25000 0xFFFFFFF 0x41 0x76 0x4f 0x40
	00cdca3c  41 76 4f 40 41 76 4f 40-00 00 80 3f 00 00 80 3f  AvO@AvO@...?...?
	00cdca40  41 76 4f 40 00 00 80 3f-00 00 80 3f 00 00 80 3f  AvO@...?...?...?

Got a hit, and puts "speed (float)" for npc-2 at 0x+08...

Add to npc-102.txt just to be sure...

Code: Select all

s -b 0xb25000 0xFFFFFFF 0x41 0x76 0x4f 0x40
	00000000`00cdca3c  41 76 4f 40 41 76 4f 40-00 00 80 3f 00 00 80 3f  AvO@AvO@...?...?
	00000000`00cdca40  41 76 4f 40 00 00 80 3f-00 00 80 3f 00 00 80 3f  AvO@...?...?...?
	00000000`00cdcbd0  41 76 4f 40 00 00 80 3f-00 00 80 3f 00 00 80 3f  AvO@...?...?...?

Which puts "speed (float)" for npc-102 at 0x+408 from the start of this location

This implies we have an array of NPC speed floats (with no padding or extra structure) stored at the location pointed to by global 0x00b25c18, indexed by NPC id
(EDIT: those "00 00 80 3f" sequences there are float for 1.0, which makes sense as 1.0 is default)

Now to test modifying it from LunaLua...

Code: Select all

function setNpcSpeed(npcid, speed)
	local p = mem(0x00b25c18, FIELD_DWORD) -- Get the pointer to the NPC speed array
	mem(p + (0x4 * npcid), FIELD_FLOAT, speed)
end

setNpcSpeed(1, 10.0) -- Set speed to 10.0 for NPC-1 (Goomba) ...

And it worked! Ta da! Dynamically changing the speed property associated with a NPC id, as if from the npc-1.txt file, but can do it dynamically on-the-fly in the middle of a level :)

I have to sleep now, but tomorrow I'll document this memory region on the wiki there.

EDIT:Moved into spoiler tag to not fill so much vertical scrolling

[Kevsoft]

Hate to say that, but you've done work, which I already did:

Full Source

[Hoeloe]

It would be nice to get as much as possible not just documented on the wiki, but implemented as fields and functions, to minimise the use of "mem" at all. This memory map is certainly a step in the right direction, and it should be possible to add things on as functions in a Lua library at the very least, if not implemented directly in to LunaLua.

[Rednaxela]

Hate to say that, but you've done work, which I already did:

Ahh, I had not seen that specific memory region documented in any of the usual places, nor referenced in the LunaDLL code, so I had assumed it was previously unknown.

[Hoeloe]

Hate to say that, but you've done work, which I already did:

Ahh, I had not seen that specific memory region documented in any of the usual places, nor referenced in the LunaDLL code, so I had assumed it was previously unknown.

That's part of the problem. A lot of the memory locations are known by a few people, but not documented anywhere useful. We need proper documentation for all of this.

[romajiQuadhash]

It would be nice to get as much as possible not just documented on the wiki, but implemented as fields and functions, to minimise the use of "mem" at all. This memory map is certainly a step in the right direction, and it should be possible to add things on as functions in a Lua library at the very least, if not implemented directly in to LunaLua.

Getting rid of mem calls is always a good idea.

[Hoeloe]

It would be nice to get as much as possible not just documented on the wiki, but implemented as fields and functions, to minimise the use of "mem" at all. This memory map is certainly a step in the right direction, and it should be possible to add things on as functions in a Lua library at the very least, if not implemented directly in to LunaLua.

Getting rid of mem calls is always a good idea.

The mem function certainly does allow us to do a lot of stuff (cinematX wouldn't be possible without it, as it actually creates a new field in the NPC structure, in some padding bits), but it's best to at least have named wrappers for it, so code is a bit more readable, and less prone to errors from, for example, reading the wrong data type.

[Kevsoft]

Well my main problem is the work.
Currently I am the main person who:
* Reverse-Engineer Stuff to find new features/addresses
* Writing up a wrapper for that stuff
* Test it to be sure that everything is working fine
* Writing up a "fairly" good documentation

And you know that I can't do that on the same time.

[Hoeloe]

And you know that I can't do that on the same time.

Yeah, there is a lot of work to do. I can't manage finding new memory locations, for various reasons, but I may be able to handle writing Lua libraries that handle the actual wrappers once the memory offsets have been found. Apparently there are ways to define properties (getter and setter functions that act like variables), which would be a good way to do that without having to patch LunaLua itself (though looking through these examples, I'm not convinced they will work...)

[Kevsoft]

I don't mind if you write the wrapper.
About the getter and setter: I used a technique with metatables to make getter and setter. (See the library uservar.lua)

[FrozenQuills]

Does anyone know the memory mappings to the NPC config attributes "Hurt player on stomp" and "NPC can't hurt player"? (Documentation for NPC config file manipulations would be very helpful anyway)

[Kevsoft]

This will help you: http://engine.wohlnet.ru/pgewiki/Npcconfig.lua