WoW 2.4.3 -> 8.1

[nemesis2578]

Hi there,

It's been ~2 yeas since I tried(with more or less success) to write my own private bot for 2.4.3. I had there all important things like reading various things from ObjectManager, hooking EndScene(DX9), ClickToMove, navigation using Cast&Detour, Execution of lua code and getting back results(mainly strings - I was using this for reading and processing quests). Wast majority of that code was found here and there on this forum, so I glued them together and did some polishing, but most importantly I understood them, what they do, how it woks. I was quite happy about that. It was my "project" to understand a bit more WoW internals and reversing.

Now I started to play on retail once again and I'm thinking to re-write my bot for latest version of WoW, so it can help me a bit with most annoying tasks and I can improve further in memory editing/reverse engineering. Ideally I would like to make it into the state, where it can run through map and pick all herbs it can find. Before I will jump into it, I would like to do some assessment of things I will need to get working:

- WoW is now only 64b - I guess this by itself will not be an issue.
- WoW is now equipped with anti-debug features, so I can't simply attach there debugger. But I was able to find here on forum post how to use x64dbg + ScyllaHide + Owerwatch DumpFix to at least do dump. It worked like a charm!
- WoW is now runs by using DX11, I would like to go with this one, so instead of hooking EndScene, I will hook Present. Brief googling on this reveled multiple howtos, so I guess this should be also quite OK.
- I can still see in-game option to use CTM(Click To Move), so I guess instead of sending keystrokes to the WoW window, I will use this feature to move my toon around.
- For navigation(What points I need to go through in order to get from A to B and not get stuck) I will try to use Recast&Detour. Or is there something better(=more easy to use)? I guess here only tricky task will be to extract and convert maps/terrain from Blizz format to format understood by R&D. I have to admit I was not doing any research on this one yet, is there anyone with some hints/links that might be of use?
- I will use C# as programming language. In bot for WoW 2.4.3 I was using BlackMagic liblary to read/write WoW memory. Do you have any other libraries to do memory operations or is BM still doing fine in 8.1?

Do you see there any other things(on high level) that I have missed and might be quite a problem? I will be very happy for all your reactions that will navigate me to interesting reading.

[counted]

I use QuickGraph for my navigation. In prior wow expansions I had recast detour working but I found it took a lot of time to maintain.

With QuickGraph you can easily map out areas or paths that you want to take and then get paths to points in your know space.

I also converted my bot to Out Of Process so I can not help you on the in process stuff anymore.

Basically I do not know windows system internals very well and to actively debug the current wow executable i think you need to hook and defeat the system api calls that wow makes to detect and defeat active debugging. Some users, whom i assume are skilled at windows system internals, have said it if fairly easy to do.

One of these days when i have some spare time I am going to look into that.

I have been able to figure out how to do everything I want to do out of process so not really motivated to get inside again.

I found the in-process bot writing was actually easier ( as long and you are pretty good with assembly language) to do because all you needed to figure out was the subroutine calling protocol and return format.

When you are out of process you need to figure out what the routine is actually doing and replicate it out side.

As for language selection, my personal experience was that C++ was easier to use for in-process and C# was for out of process. When i was in process my injector was written in C# and it returned and address space that the C# external program could write too, thus sending config commands essentially being the UI of the in process C++ engine.

[nemesis2578]

Hi counted,

Thanks for your reply. I will make a note of QuickGraph and once I will get into a stage where I will need to move my character around, I will give it a try.
In/out process: I guess this is yet another example where each has some pros and cons and it is not possible to say what is better as there are many viewpoints. In my old bot I went for in-process as I had(and hopefully still have) some assembly knowledge, so it was not a big deal to get things working. But as I will be starting from scratch now, I will see if out-of-process approach suits me better.

Maybe very last question: With current retail WoW, I can see patches are pushed much more frequently as I was used to see in past. Do you see those patches more like small bugfixes that usually don't break your bot or do tehy change quite a lot? Now I'm talking about those patches, where usually only build number changes, not version number.

[counted]

Hi counted,

Maybe very last question: With current retail WoW, I can see patches are pushed much more frequently as I was used to see in past. Do you see those patches more like small bugfixes that usually don't break your bot or do tehy change quite a lot? Now I'm talking about those patches, where usually only build number changes, not version number.

Mainly bug fixes and content change or enabling.

[34D]

I use QuickGraph for my navigation. In prior wow expansions I had recast detour working but I found it took a lot of time to maintain.

With QuickGraph you can easily map out areas or paths that you want to take and then get paths to points in your know space.

I also converted my bot to Out Of Process so I can not help you on the in process stuff anymore.

Basically I do not know windows system internals very well and to actively debug the current wow executable i think you need to hook and defeat the system api calls that wow makes to detect and defeat active debugging. Some users, whom i assume are skilled at windows system internals, have said it if fairly easy to do.

One of these days when i have some spare time I am going to look into that.

I have been able to figure out how to do everything I want to do out of process so not really motivated to get inside again.

I found the in-process bot writing was actually easier ( as long and you are pretty good with assembly language) to do because all you needed to figure out was the subroutine calling protocol and return format.

When you are out of process you need to figure out what the routine is actually doing and replicate it out side.

As for language selection, my personal experience was that C++ was easier to use for in-process and C# was for out of process. When i was in process my injector was written in C# and it returned and address space that the C# external program could write too, thus sending config commands essentially being the UI of the in process C++ engine.

Emmm I searched for new features and found your suggestion hah
At present, the way I move is to click the postmessage button, but it is not convenient to calculate the facing direction and the target.
So I am going to rewrite the move method

At present, the search forum has found that there is world2screen cooperated to open ctm to simulate mouse click

Another is the CTM method seems to be the simplest, But the CTM seems to be encrypted after 8.1.
I tried in ida I can't seem to get the mac binary file.
The cheat engine does not get the real value when searching for ctm type.

SO world2screen maybe the best way in RETAIL.?

Do you have any suggestions for this? Looking forward to your reply. It is very important to me. Thanks

[xalcon]

One alternative would be to not rely on CTM at all. I mean, who uses CTM anyway? Multiboxers, Botters and maybe some handycapped people. One option I'm toying around with is to just simulate actual keyboard and mouse input via an arduino pro micro and the arduino mouse + keyboard apis. The arduino shows itself as an generic usb HID to the operating system as well as a COM device which I use to send the arduino commands. Sure, this has the downside of not being able to be run in the background - but I'm focusing more on simulating humanlike behavior rather than bot efficiency.

[Jadd]

One alternative would be to not rely on CTM at all. I mean, who uses CTM anyway? Multiboxers, Botters and maybe some handycapped people. One option I'm toying around with is to just simulate actual keyboard and mouse input via an arduino pro micro and the arduino mouse + keyboard apis. The arduino shows itself as an generic usb HID to the operating system as well as a COM device which I use to send the arduino commands. Sure, this has the downside of not being able to be run in the background - but I'm focusing more on simulating humanlike behavior rather than bot efficiency.

GitHub - everdox/HIDInput: HIDInput is a device driver that emulates mouse and/or keyboard input, and has been supplemented with easy to use functions that aid in the decision making process of when or how to synthesize such input.

[xalcon]

I've seen HIDInput as well and considered using it, but my arduino idea came from a fully passive scenario - as in: nothing runs on the client machine. A secondary PC grabs the HDMI signal using capture card and sends keyboard and mouse inputs via the arduino. I've only implemented a simple fishing bot using this system, but the bot itself was able to run on a raspberry pi and nothing had to be installed on the wow client machine.

Nevertheless, HIDInput is a great alternative and it will probably be part of some future experimental projects of mine.

[SailorMars]

. ....Sure, this has the downside of not being able to be run in the background - but I'm focusing more on simulating humanlike behavior rather than bot efficiency.

You may run a multiboxer in the PC and have the multiboxer interprets foreground keystrokes and generates keypresses to your wow running in background. This is perfectly legal and human like. A lot of players are playing wow with multiboxers.

[Jadd]

You may run a multiboxer in the PC and have the multiboxer interprets foreground keystrokes and generates keypresses to your wow running in background. This is perfectly legal and human like. A lot of players are playing wow with multiboxers.

Also true, and with the typical usermode detection method for "injected" inputs (a low-level keyboard hook) there is no information to suggest which process the input originated from - only the fact that was a simulated input.