[C++] (WoWX) Patterns

[BlizzhackerD]

If a mod could add the tag [Question] to the topic, it would appreciated. I seemed to have forgotten it. =(

I've come across the WoWX source code like many people have I'm sure. I can't speak to having any released software on MMOwned, but I've been a long time learner, firstly in programming in general, then attempting to learn more about injection and emulation.

I've seen that these "patterns" for finding function offsets is the new requirement for creating anything of value. I've researched enough to know that this is due to WoW now making use of ASLR (Address space layout randomization, if my googling and common-sense serve me correctly.)

Normally I'm pretty good about being able to make sense of the code that I'm looking at, and that's how I've learned thus far, but I've either miss out on a very large portion of the C++ syntax, or finding and using these patterns and the pointers to the functions they refer to is just something very new and thus difficult.

I'm mainly unsure of what I should be googling for to learn more about this system, a search for "c++ patterns", "c++ offset patterns", and "c++ function pointer patterns" all yielded results for design concepts such as singletons and the like.

If someone could point me in the right direction as to where I might learn more about this methodology, it would be greatly appreciated, as I'd much prefer to understand and learn than just use.

[ddebug]

If a mod could add the tag [Question] to the topic, it would appreciated. I seemed to have forgotten it. =(

I've come across the WoWX source code like many people have I'm sure. I can't speak to having any released software on MMOwned, but I've been a long time learner, firstly in programming in general, then attempting to learn more about injection and emulation.

I've seen that these "patterns" for finding function offsets is the new requirement for creating anything of value. I've researched enough to know that this is due to WoW now making use of ASLR (Address space layout randomization, if my googling and common-sense serve me correctly.)

Normally I'm pretty good about being able to make sense of the code that I'm looking at, and that's how I've learned thus far, but I've either miss out on a very large portion of the C++ syntax, or finding and using these patterns and the pointers to the functions they refer to is just something very new and thus difficult.

I'm mainly unsure of what I should be googling for to learn more about this system, a search for "c++ patterns", "c++ offset patterns", and "c++ function pointer patterns" all yielded results for design concepts such as singletons and the like.

If someone could point me in the right direction as to where I might learn more about this methodology, it would be greatly appreciated, as I'd much prefer to understand and learn than just use.

The new ASLR has nothing to do with finding patterns. ASLR is during dynamic runtime analysis. Finding patterns is mostly static (though, I guess you can do it dynamic).

ASLR just means that you need to add all relative addresses in memory to the base address of the current running WoW process in order to get the actual address of the function in memory.

Patterns are useful during patch time. You run the "find patterns" script to locate the relative addresses and offsets you want (as these will change each patch). You then use these relative offsets and the base address to manipulate the actual address in memory.

I would re-read the Wikipedia article on address space layout randomization: http://en.wikipedia.org/wiki/Address..._randomization
Then, I would take a look at a working pattern for this patch (or a previous patch), open the WoW binary [corresponding to that patch] in IDA and click "Search > Sequence of bytes". Paste your pattern in there (including the "?"'s - unknown values which may have changed) and it will take you to the location on disk where that region is.

Don't get me wrong, you can "find patterns" during runtime analysis and locate memory addresses like that. I wouldn't recommend this as you don't know if the "pattern" has changed or not. Additionally, it's significantly slower than actually going directly to the address in memory. Therefore, "find patterns" should be used to just find the relative addresses you need. Then you should just go to that offset in memory [BaseAddress + relative_address].

[BlizzhackerD]

So my understanding of why WoWX does what it does is flawed then?

Or does WoWX not do it at all?

I'm familiar with using pointers to offsets in memory, I had just misunderstood the ASLR system to mean that the location in memory was completely dynamic as opposed to still being static from a random base address. The WoWX method of invoking those calls to code just seems more sophisticated that the approach I'm used to, but perhaps that's because it's a library as opposed to the application using it?

[ddebug]

So my understanding of why WoWX does what it does is flawed then?

Or does WoWX not do it at all?

I'm familiar with using pointers to offsets in memory, I had just misunderstood the ASLR system to mean that the location in memory was completely dynamic as opposed to still being static from a random base address. The WoWX method of invoking those calls to code just seems more sophisticated that the approach I'm used to, but perhaps that's because it's a library as opposed to the application using it?

First of all, WoWX was developed before WoW went ASLR. WoW became ASLR this patch. Before then it was not.

It would make sense that bobbysing used FindPattern to spicen up the library. He probably did this to not have to update it from patch to patch. It's a perfectly fine method of locating addresses. It just isn't as quick as going directly to them in memory.

[BlizzhackerD]

Okay, so I'm not as confused as I thought I was then. Still definitely something I should invest in learning though.

Thanks for the help. =)

[ostapus]

First of all, WoWX was developed before WoW went ASLR. WoW became ASLR this patch. Before then it was not.

It would make sense that bobbysing used FindPattern to spicen up the library. He probably did this to not have to update it from patch to patch. It's a perfectly fine method of locating addresses. It just isn't as quick as going directly to them in memory.

no one is using findpattern whenever you need address, you doing it just once on the start and cache found addresses.

[ddebug]

no one is using findpattern whenever you need address, you doing it just once on the start and cache found addresses.

Alright. I haven't looked at the WoWX library in-depth. I just assumed what BlizzhackerD said was true.

It is very inefficient, as mentioned previously, to search by pattern each time (you have to navigate through the entire memory space of the program to find the bytes you are comparing against [or at least until you find them first]). That's why it is best to do it once and then use the addresses you found in your program. I already mentioned this in my first reply, but just in case.

[Seifer]

It is very inefficient, as mentioned previously, to search by pattern each time.

It'll cost nothing compared to everything you could save, if done properly. (Few milliseconds for FindPattern to find 100 offsets vs. dumping 100, and then implementing?)

As for the patterns, it's commonly known as "FindPattern", and a Google search for that comes up with quite a few results. Also, BlackMagic implements FindPattern functionality: #1232210 - Pastie

[ramey]

It'll cost nothing compared to everything you could save, if done properly. (Few milliseconds for FindPattern to find 100 offsets vs. dumping 100, and then implementing?)

As for the patterns, it's commonly known as "FindPattern", and a Google search for that comes up with quite a few results. Also, BlackMagic implements FindPattern functionality: #1232210 - Pastie

Why would you want to waste time initializing when you can easily create a tool that does that for you and then outputs a header file with the found addresses? It isn't a few milliseconds, it works out to be a few seconds if you have a lot of patterns.

[Sychotix]

Ramey, that would likely depend on the language it was written in, the computer, and how you are doing it.

edit: oh, and implementing a FindPattern like function into a program will prevent you from needing to constantly recompile after updates, unless one of the sigs change of course.

[Cypher]

Ramey, that would likely depend on the language it was written in, the computer, and how you are doing it.

edit: oh, and implementing a FindPattern like function into a program will prevent you from needing to constantly recompile after updates, unless one of the sigs change of course.

^ This.

Being able to modify an external file and not have to recompile every time you need to update your offsets/patterns is a big plus.

The only overhead introduced by a pattern scanner is a one-time scan at startup, where performance is not an issue anyway. At any rate though, if it takes you several seconds to do a pattern scan you probably haven't optimized the implementation properly.

The time saved by avoiding unnecessary recompiles greatly outweighs the time introduced by the pattern scanner. (At least in my experience)

[Seifer]

At any rate though, if it takes you several seconds to do a pattern scan you probably haven't optimized the implementation properly.

The time saved by avoiding unnecessary recompiles greatly outweighs the time introduced by the pattern scanner. (At least in my experience)

Exactly, if it takes more than several seconds to do a pattern scan you're either doing it wrong or running thousands of patterns on a Tulip 386.

In my opinion and experience, using a FindPattern implementation is a severe plus, granted that it is implemented properly and not called every ~60 ms or something stupid like that.

[ramey]

Ramey, that would likely depend on the language it was written in, the computer, and how you are doing it.

edit: oh, and implementing a FindPattern like function into a program will prevent you from needing to constantly recompile after updates, unless one of the sigs change of course.

Yeah, I know that. Most programs don't update that often to warrant having all the pattern finding done on startup. I think it's a waste of time, and if you have many patterns (100+) there's a chance that a pattern broke on an update. So instead of checking a log file to verify each offset (or a similar logging facility) after a patch, would you rather not have an external program verify it for you and generate a header file so you just replace the old header file and recompile?

^ This.

Being able to modify an external file and not have to recompile every time you need to update your offsets/patterns is a big plus.

The only overhead introduced by a pattern scanner is a one-time scan at startup, where performance is not an issue anyway. At any rate though, if it takes you several seconds to do a pattern scan you probably haven't optimized the implementation properly.

The time saved by avoiding unnecessary recompiles greatly outweighs the time introduced by the pattern scanner. (At least in my experience)

Sure, you can optimize your FindPattern function pretty easily, and there's actually a few threads over at GD about doing that, but as I said above chances are a pattern may break and then what do you do anyway? Recompile to integrate the pattern into your program. It's still pretty fast, and the overhead is minimal, but it is a second or two to do a lot of patterns. It's even slower if you're doing it from C#, unless you make use of threading which can speed it up greatly.

Don't make me get the meme out!

Exactly, if it takes more than several seconds to do a pattern scan you're either doing it wrong or running thousands of patterns on a Tulip 386.

In my opinion and experience, using a FindPattern implementation is a severe plus, granted that it is implemented properly and not called every ~60 ms or something stupid like that.

Of course it wouldn't be called more than once in any implementation, but just because of the reasons I listed above I don't see why you wouldn't move the pattern scanning to an external program. Chances are you will have to recompile on a patch anyway to fix something or to update a pattern or to change some implementation.


Edit: Generally, I don't really understand why you can't see the small benefits. You can test patterns faster, create them faster and easier, and update them easier by moving them to an external program which takes care of it for you (along with ASLR for example), and then generates a nice header file. You can also get this external program to compare builds of different patches. I think you're kinda holding onto something just because you have it implemented already and don't really agree that there's always something that suits a bit better.

Edit 2: Cypher just pointed out using an XML file for the patterns obviously which I didn't think of because I wasn't using an XML file in my injected portion before.

[Cypher]

Apparently Ramey forgot that you can implement your pattern scanner to use an external file so that no recompilation is necessary on a pattern update. Rifk.

[ramey]

Apparently Ramey forgot that you can implement your pattern scanner to use an external file so that no recompilation is necessary on a pattern update. Rifk.

Joshua says:
*i'm gonna go watch TV and cut off the calluses on my hand, lol


Rifk.