[C# / 1.12.1 WoW] Sending packets

We are writing a program for WoW 1.12.1 which should simply kill and loot NPCs. To accomplish that we need to take care that our tool can interact with the WoW client to do everything from targeting a unit to casting attacks.

There are many ways to achieve that

1. Read the memory and simulate clicks / keypresses 
2. Write bytes representing ASM instructions to the WoW address space either to modify already existing instructions (ex: Jump from an existing function like EndScene to your own Code) or inject new code to unused memory. This method is used by the old bot I previously released.
3. Execute your tool as a part of WoW: Jump from a WoW functions to code written in your desired language which is part of your program. Wonder whats the difference to method 2? Read More Updates from this post.

Method 2 & 3 are offering once again different approaches to make something happen inside the game

1. The easiest: Use DoString to execute Lua functions provided by the WoW api. Most tasks like buff checking can be done with more or less complex scripts.
2. The time intensive (atleast in my opinion): Find the function which triggers the action you want. This can be very annoying aswell complicated. Just imagine what your bot need to be able to do for a moment: Target units, Interact with units, cast spells, check cooldowns to name only 4. For every functionality you need to find a function inside the WoW address space, reverse it (is it thread-safe? Which calling convention is used? Which parameters are passed? How are the parameters used inside the function?) and implement it.
3. The most awesome: Find the function responsible for sending packets to the server. Reverse the packet structure and send your own ones.

First of all let me tell you why I think that sending packets is the best of the 3 previously mentioned: The client has checks for all kind of stuff to decide if an action is valid before it happens. Incase of sending packets you "ignore" every check and just send your bytes to the server. 

Two little example:

• Calling a cast function the packet which tells the server that we are casting is only send when all conditions are met: The spell isnt on cooldown. We arent casting anything else right now. We have enough mana and so on. Sending a packet all previous checks are ignored. That doesnt mean that we can cast thousand spells at once by spaming packets: The emulator / server will also validate packets and check if the requested action is possible.
• Talking about serverside check I have another example: On well known project wow-one.com you could learn more than 2 professions by sending the responsible packets.

So can we also find exploits like this? Indeed! Every packet has a number which tells the server what kind of packet it is. Depending on this number the data attached to the packet is processed by a handler function.

As we send our own packets we dont have to stick to "rules". We can send whatever we want and in conclusion also trigger actions unwanted by the server administration. If only one information inside the packet isnt validated and checked for integrity we may have found a working exploit (example for the profession exploit: The server didnt check if we already had two professions)

How do we build our packet? Basically we have a DataStore struct which holds a pointer to a buffer at byte 4 and some other information which we care about later.

The buffer starts with a integer holding the opcode of the packet followed by information depending on the type of packet. A pointer to the struct is then passed to netclient::send which will process it further.

[C#] Calling functions: ASM vs Unmanaged Delegates

I am stil playing WoW from time to time and I am also stil working on tools here and there. Some time ago I shared my 1.12.1 bot which interacts with WoW using Read/WriteProcessMemory aswell fasm_managed to inject Assembly code at a specific address.Main reason for sharing the bot was fading motivation and a push for me to finally start going injected and using C# code to call functions instead of writing assembly code. Probably one or two months ago I started another attempt at writing a bot for 1.12.1 but this time as a fully injected clr application which means that my program is loaded into WoWs address space instead of running on its own.
As a little example of how easy life can be being injected I got a little snippet for you:

 /// <summary>  
 /// Set the target by guid  
 /// </summary>  
 [UnmanagedFunctionPointer(CallingConvention.StdCall)]  
 private delegate void SetTargetDelegate(ulong guid);  
 private static SetTargetDelegate SetTargetFunction;  
 internal static void SetTarget(ulong parGuid)  
 {  
      if (SetTargetFunction == null)  
           SetTargetFunction = Memory.Reader.RegisterDelegate<SetTargetDelegate>((IntPtr)0x493540);  
      SetTargetFunction(parGuid);  
 }  

VS

 internal static void SetTarget(UInt64 guid)  
 {  
      lock (Call_Lock)  
      {  
           byte[] guidBytes = BitConverter.GetBytes(guid);  
           String[] asm = new String[]   
                {  
                     "push " + BitConverter.ToInt32(guidBytes, 4),  
                     "push " + BitConverter.ToInt32(guidBytes, 0),  
                     "call " + (uint)0x493540,  
                     "retn",    
                };  
           //Console.WriteLine(DateTime.Now.ToString("HH:mm:ss") + " Calling Set Target");  
           Inject.InjectAndExecute(asm, true);  
      }  
 }  

There is no more dealing with calling conventions beside telling your program which one to use. Functions are much easier to detour and in general every aspect of interacting with WoW will be easier and cleaner. For example I run my whole bot logic inside the DirectX Endscene now Instead of injecting new ASM for each function I want to call.
Personally I dodged going injected for a long time because I was to lazy to learn how to do it but afterall I can only advice it to everyone who downloaded my previous bot and started with the same bullshit I did.

Once I find a few days I will start explaining how to be inprocess using C# and also continue a few things like the WoW hacking tutorials I started to write previously but stopped somewhere inbetween. If you want to try your luck I can advice IceFlake by Miceiken from Ownedcore which was a very big help getting started. Thanks to Miceiken at this point :).

[C# / 1.12.1 WoW] Render Disabler

Today I found an old tool I programmed for a friend some time ago. It can disable the rendering of the environment for multiple 1.12.1 WoW processes completely:

Source + binary version will be posted in the evening today.

Update: https://github.com/Zz9uk3/RenderDisabler

[Tools] How to use IRC

If you are also active inside the WoW emulation scene you may already noticed that a lot of the communication is handled over IRC. However most people tend to use some kind of webchat instead of really trying to get into it and possible clients.

There are dozen clients but non as good as Hexchat (https://hexchat.github.io/downloads.html).
Download the for your system suitable file and install it:

Start HexChat.exe and wait for the window to show up.

Incase of HexChat being launched for the first time you will end up seeing the Network List.

In this example we will connect to the Kronos IRC channel which is hosted on the Mibbit network.

Obtaining the connection informations can be a bit annoying for some IRC networks however most of the time you do good hitting google with "XXX connection guide" (XXX is Mibbit in this case):

Now we can proceed adding the connection details in HexChat:

Go to the Network List window

Click Add and change "New Network" to a more fitting name like "Mibbit - Kronos"

Highlight the new network by clicking on it and hit Edit

The server format is domain/port 

If we are using SSL we put a + infront of the port:

 

The Connect Commands offers the possibility to specify commands which will be executed after connecting to the server. Many IRC networks got a registration system in place where you register and auth with a bot user named NickServ. Using this tab you can for example auth yourself everytime you connect to the network.

A little explanation on how to register a nickname on mibbit can be found here.

After setting everything up HexChat should connect properly:

Staying in IRC even after closing HexChat

IRC cant be compared to messengers like Skype where you can for example send messages to someone being offline. You hold your nickname as long as you are online. As soon as you disconnect the nickname will be free again for use  and someone else can connect under that name.

To avoid that someone else use your nickname you can register it. Depending on the network the person connecting with your registered nickname will be force renamed or will keep the name until you auth with your nickname.

Also there are bouncers. Those are programs running on a server keeping your nickname connected to the network 24/7. Imagine a bouncer as a proxy. You give HexChat the details of your bnc and it will connect through it to the network.

Final words

IRC looks complicated to those who never used it before and one may ask why we use such a system incase of Skype but once you made your first steps you will love it.

As someone who is interested in WoW development I can easily stay in touch with all projects I am interested in without adding thousand of contacts to some messenger:

[C#] 1.12.1 Bot source code

I decided to release the source code of an old WoW Bot which is based on injecting Assembly into the WoW process: https://github.com/Zz9uk3/CorthezzWoWBot

Enjoy! :)

[C#] Accessing Form Controls from another thread / class

While working on a new advertising tool I thought a progressbar indicating how many players stil need to be whispered would be pretty cool:

However one will face problems directly accessing the progressbar from another thread since our thread can collide with the thread which created the progressbar (the UI thread).

To avoid those crashes C# offers a method Invoke which requests another thread to execute code through a delegate (read more).

Speaking in code:

First of all we create a delegate which takes an int as parameter:

 private delegate void updatePbDelegate(int percentage);  

Following that step we create a function which will be called by the other thread:

 public void updatePb(int percentage)  
 {  
      if (this.InvokeRequired)  
      {  
           updatePbDelegate set = new updatePbDelegate(updatePb);  
           this.Invoke(set, new object[] { percentage });  
      }  
      else  
      {  
           pbSender.Value = percentage;  
      }  
 }  

InvokeRequired compares the callers thread with the thread that created the GUI (read more).
If the call comes from another thread a delegate instance pointing to updatePb will be created and passed to Invoke which will then proceed and call updatePb from the UI thread. This time InvokeRequired will return false and the value of the progressbar will be adjusted.

Last but not least we need to pass our Form instance to the thread which will look like this:

 public partial class Form1 : Form  
 {  
      public Form1()  
      {  
           InitializeComponent();  
           Sender.Start(this);  
      }  
      private delegate void updatePbDelegate(int percentage);  
      public void updatePb(int percentage)  
      {  
           if (this.InvokeRequired)  
           {  
                updatePbDelegate set = new updatePbDelegate(updatePb);  
                this.Invoke(set, new object[] { percentage });  
           }  
           else  
           {  
                pbSender.Value = percentage;  
           }  
      }  
 }  
 internal static class Sender  
 {  
      private static Thread thrSender;  
      private static Form1 formAccess;  
      internal static void Start(Form1 parForm)  
      {  
           formAccess = parForm;  
           thrSender = new Thread(Pulse);  
           thrSender.IsBackground = true;  
           thrSender.Start();  
      }  
      private static void Pulse()  
      {  
           formAccess.updatePb(100);  
      }  
 }