40d Talk:Memory hacking

New Release Updates

I'm just updating the main page as I figure new things out. Someone else will probably have to redo the formatting, since I don't really know the wiki formatting. --Zhentar 23:30, 29 October 2007 (EDT)

Creature Structure

I have a feeling that offset 0x00 is really a "next" pointer, forming a linked list. The reason being is that I was able to take the 4 byte value and go to that address, and it would be another creature. It progressed for a handful of creatures. Seems logical to assume it does it for all creatures. --AzureLightning 00:24, 3 November 2007 (EDT)

I would assume this is true as well, since earlier versions did not have vtables for creatures, only items did. --Rick 18:07, 4 November 2007 (EST)

Memory Locations

Does anyone know the memory location for the current unit focus? --AzureLightning 14:05, 3 November 2007 (EDT)

My automated tool says it's at current_unit_focus_loc == 00C36540 in .33c, verified by two search patterns, but not manually verified. You probably should have asked this in the .33c subpage.
—0x517A5D 16:49, 30 November 2007 (EST)

Questions

1. Has anyone attempted to decode the memory for the "Choose Fortress Location" screen? Being able to generate a list of all local areas with magma vents would be useful. Palin88 20:09, 29 November 2007 (EST)

This is a great idea. I suggest going one step further : Give the user a list of options (say : magma, flux, thick forest, chasm, underground river, pit, etc), and logically AND all parts of the map that have those features. That would save people hours of looking for their perfect start location. Runspotrun 19:25, 8 December 2007 (EST)

1. It could be important to some people, but the formats are only correct assuming that the dwarf fortress binary is built using release config. Under debug config, std::string structure gains some more fat and the existing offset will be wrong. Not a prob now, but I think it is good to know. Sphr

Version Identity

Thought that the wiki should include some info on how to identify known versions. For lack of a better choice atm, I'm using the version text block that is displayed on main menu. The version string itself is the string to be expected at the offset.

("v0.27.169.33a", 0x01BA29B0)
("v0.27.169.33b", 0x01B99FF0)
("v0.27.169.33c", 0x01BA29B0)
("v0.27.169.33d", 0x01B78670)

Sphr 2007 Dec 9

Have you verified that these offsets are always valid? I ask because they are past the end of the static memory area, up in heap space. I can easily see the allocator placing the memory block at different offsets on different computers, or even between different runs on the same computer. I agree that we need a version ID, but at first glance, this doesn't look like a good way to me.
—0x517A5D 17:53, 8 December 2007 (EST)

I personally use the "Dwarf Fortress" string, with the address shifts I doubt there will be an issue with that. --Rick 18:33, 8 December 2007 (EST)

I just looked at that and I disagree. I don't think it's random enough. So far it's been at:

• .32a: 0089238C
• .33a: 0089338C delta +1000
• .33b: 0089438C delta +1000
• .33c: 008993A4 delta +5018
• .33d: 0089A3A4 delta +1000
  

You're depending on that to be unique. Or at least that if the string offset is the same, then the variable offsets are the same as well. To me it feels like asking for trouble.

I don't have a good answer, but I feel that both of these proposals aren't reliable.
—0x517A5D 22:37, 8 December 2007 (EST)

I agree, I just went with the "best" solution for now. --Rick 00:47, 9 December 2007 (EST)

Ok, It seems that they are heap allocated. which becomes invalid the moment it gets dumped. This method is not working. Are there any other working ways that people are already using? forum thread mentioned fingerprinting using arbitrary chunks, would suffice too. Anybody can post down the chunks they check for? The other more evil way I see could be to use OS to take the size of the file + the CRC hash value. Sphr 2007 Dec 9

Actually, the CRC value in the PE header would probably be a pretty good value to match against now that you mention it, since I doubt Toady fudges with it. --Rick 04:45, 9 December 2007 (EST)

The .CheckSum field of the .EXE's PE header is 0 in all released versions of DF. Won't work.
The .TimeDateStamp field has always been unique and probably always will be.
That's at 004000F8 and is a DWORD. It might be the best option.
—0x517A5D 17:50, 9 December 2007 (EST)

Agreed, new versions of my tools (.33f, or whatever the next version is) will switch to this method. --Rick 12:56, 10 December 2007 (EST)

I don't use the PE header which can be messed with. I tried using a fast asm based crc32 checksum function. Seems to work, but I'll wait and see first. thread is here[1]. Sphr 2007 Dec 10

I don't understand the threat model this implies. I wouldn't think the PE header is more susceptible to manipulation than the rest of the executable. Less, actually. The game is not packed, so the program text is exposed to anyone who wishes to do a permanent hexedit. In comparison, PE header manipulation is both exotic and fragile, difficult to get right.
—0x517A5D 17:41, 10 December 2007 (EST)