SolarStrike Software

I've been working on a "Quest" class and wanted to be able to find the info through memory scans. I already found the quest log, or rather the region of memory containing the quest IDs of the quests in the quest log.

I was hoping to get more info so I've been scanning and found a database containing all the quests. It's prefixed by "v0.20 locke1110 2011/05/11 9:24:13 QuestDetailObjectDB". I can't really tell when I'm looking at with a hex editor so I wanted to extract the DB from memory and examine it with different DB programs to figure out the format and devise a scanning method.

Any suggestions as to how I would get the memory region into a blank file to do this?

I really doubt there would be any software out there that would be useful. It is just going to be an array of structs. You'll have to just try to figure out the size of each data and what it represents. The only way to do that is trial and error as well as just comparing differences between them.

Edit: Nevermind, I'll just use Olydbg to look at it.

I don't suppose you'd know how to get OllyDBG to show all of the memory locations like CE does? In-questlog id's but it won't let me search all of the memory for the string I was using.

Right-click the CPU window, search for, all referenced text strings. You can then search within that to find what you need.

Be aware that this is only going to give you what is in the client, not stuff that will later be dynamically loaded from a database.

Administrator wrote:Right-click the CPU window, search for, all referenced text strings. You can then search within that to find what you need.

Be aware that this is only going to give you what is in the client, not stuff that will later be dynamically loaded from a database.

I actually like this tool, though it's not as geared for finding pointers as CE is. I'd already figured out how to execute the client to get that dynamically allocated stuffs, but unfortunately it crashes.

I then attached to a running client and looked at it. That's what I'm looking at when I say I can't find all the memory. I'll try what you said above but it seemed like nothing I did would effect a change.

To be honest, I'm not really sure. I think that would be because those text strings don't have a reference inside the client. That is, they are not compiled into the executable.

Then you can be sure of it. For each section listed you would simply page down through the memory browser and start to see (set to 4-byte decimal) ID numbers, one after another that are of the type listed in the text above.

I would also like to point out that this makes total sense.

I'm only just now taking a database course so I wouldn't have been able to associate it if it had been just a few months ago.

ID numbers are what databases use to store and reference data. It's clear that the primary key being used are these ID numbers that are unique to all objects. Since this compiled text exists are the top of each table in the database (I can't really find an intellgent reason for why they stored them as seperate databases - it might have something to do with the type of database) but it's easy enough to find. Now, just to figure out how to read them...

Edit: Oh, the reason you'd want to figure out how to read them is to remove the need for all those requests for data we send to the bot. Almost all of the lua functions that return data will be accessing these databases. If we can cut out the middle man by pulling up the query info and using it to find the data ourselves, we can remove the extra slow middle man.

Also, once the data is readable, it won't be necessary to use those akward queries, instead using the data directly from the fields.

About that, I guess the first clue I got was this. I noticed it was long before the memory table thing was discovered and worked on. Though I was fairly new to lua and thought this was a part of it that I just didn't know I was looking at.

In game, type this in chat: You'll see something hauntingly familiar.