Freitag, 26. Juni 2015

[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.

You asking why I write this post? After being a bit unmotivated lately a discussion started by R4zyel inside the OwnedCore Memory Editing section gave me new ideas. Thanks to namreeb by the way for this epic response (+REP!!!!).

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 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)

## slightly offtopic ##

Now this may be a bit offtopic and not interesting for people who dont care about 1.12.1 WoW projects but above paragraph describes exactly why I chose Kronos over Nostalrius.
The log posted here shows the packets being send in the process of logging into an account to entering the world:
I dont believe that a single project double checked every single packet for possible exploits and even if they did none could guarantee that every possible weakness is found. Having "the ultimate anticheat" and detection of every kind of movement hack is impossible and shouldnt be promised. For example even Nostalrius stil got atleast one teleport exploit which I know of (keep in mind I am also very new to packet related stuff).
It is nice to see how easy people believe everything and dont care to look for an opinion from an experienced person (are people to easy to manipulate?)

## slightly offtopic ##

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.

Waiting for code?

Before I go deeper and start to post code I will wait for feedback and correct possible mistakes. I hope everything is clear so far.

Donnerstag, 21. Mai 2015

[C#] A little bit of networking ... and other stuff

A friend got an old printer which doesnt support WLAN. The distance to the router is to big to establish a physical connection. Luckily there is a desktop PC next to the printer which is connected to the LAN!
I wrote a little tool where the server part recieves a XPS file and forwards it to the default printer of the machine it is running on.

To demonstrate it I setup a Virtual Machine which is in a network with my main system. Since the VM doesnt have any printer connected the file is send to the Microsoft XPS writer but watch yourself:

It is one of those typical programs you write in an hour with the intention to just use it yourself. In conclusion there is no error checking or whatsoever but who will use such a tool any way in a time where every printer has WLAN support right? :D
Incase you are interested in the source code you can download it here:,58353234/CS_BlockDruck.rar/
 I feel no need to explain anything here since everything should be understandable easily but if you have a question you can ask any time over IRC / Skype.

Got another idea for a tiny tool? I enjoy writing those tiny programs. Send a request if you like.

More Updates?

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>  
 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);  


 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,  
           //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 :).

Speaking about programming I will also release a little multihack with all hacks I could use on Nostalrius without being catched by Warden or any other mechanic they got in place: All kind of tiny movement hacks which shouldnt be detected even after the tool is released.
Also I updated the link to the Render Disabler (sorry for being that late).

Non-programming stuff

I got a chance to travel around the world a bit. If everything works out well I will get myself a new camera and try to record a few freerunning runs here and there whenever I find a good spot.

Freitag, 24. April 2015

[WoW Emulation] You should really read that!

Somewhere between the last few days I have read a great post of Stoneharry who is a known member on Ownedcore. I think everyone who plays on a private server should definetly read this:

Going down to where a emulator begins:
Everything sent and received between the client and a server is a packets. A packet is a message sent over the Internet that contains a header saying it's ID, and then some contents (usually some numbers, maybe a string, etc). Based on the packet ID and the contents the server or client will perform some verification to make sure it is valid and allowed, then carry out this command.
The emulator needs to read all the packets sent from the client. This part can be hard as you need to reverse engineer each packets structure, what data is in it, what does it actually mean, and so on. Then you need to reply with the EXACT data the client expects: if you don't, then the client will either crash or not listen to that data. You can begin to see the troubles we have.
However, assuming you know all the packet structures, then you are just coding what to read and what to write back and when. We now do know all the packet structures due to several leaks from Blizzard, one for almost every expansion including WoD. But knowing the structure is not enough, you also need to know the Id's and offsets. More reverse engineering, and as of Cataclysm this changes every single patch rather than on just major patches.
So you have to code the entire emulator with this data once you have figured it out, encode some sort of database system to store and load everything, work out what all the flags and enums mean (there are thousands), and code it all up. To put it in perspective, the current 3.3.5a TrinityCore emulator counts at about 300,000 lines of code if you run a line counter on all C++ files. And this isn't just simple programming: you are concurrently writing to handle thousands of connections at the same time all actively requesting and consuming content.
Okay, so this achievement has been done over many years of development. Why aren't we completely bug free yet? Why aren't the last things easy to clean up? Because the emulators are shit. Literally. You have to appreciate that these have been put together with little organisation over many years as an open source project where hundreds of amateur developers have contributed. Many classes are over 10,000 lines each! Coding practices are not used. It is hard to debug. Memory leaks.
This has been improved drastically as people go back and rewrite entire implementations and start to use proper computer science standards, but it is a mammoth task.
Then on top of all this emulator stuff, you have to do the server side content. Get all the creatures, items, etc, get all there spawns, waypoints, and spawn it all out and produce that content. A lot of this task can be automated by writing programs that listen to what is happening on retail and writing it out into your database, but it is hard to get it accurate and you will have to touch it all up.
After this huge task is done you then need to code it: tedious, boring, and LONG. Very very long. It takes so long to code the Blizzlike content, all the quests, dungeons, and so on. And think how much bug fixing Blizzard does on the PTR's? You have to somehow do that as a developer, without the player base testing it usually because you often work solo in the emulation scene. Yeah, it's not easy, and nobody wants to take on that task usually.
All of these issues and more are why we don't have perfect emulators. Especially as these are often not paid professional developers but rather amateurs learning and having fun.
TrinityCore 3.3.5a is a masterpiece considering all the effort and time that has been put into it and how well it runs now. Anyone can pick it up and run a 3.3.5a server mostly bug free and stable. This code base is being used to work on other emulators, but you begin with all the same issues described earlier in this post.
TrinityCore was created from the Mangos code base. Mangos is one of the oldest code bases. One emulator I forget the name of branched into Mangos and Antrix. Antrix became Ascent, then OpenAscent, Hearthstone, and ArcEmu. The Antrix side progressed much more quickly but employed much worse programming standards and thus while it was the most popular emulator in 2.4.3 and before, it was always buggy, unstable, and now is dead.
Mangos has continuously been worked on and was becoming the best emulator even in late TBC. TrinityCore branched from and has become even better.
Nobody appreciates the developers behind these emulators. We have put in tens of thousands of hours into this. And what do we get out of it? Thousands of people bitching about stuff not working. Servers using our base and then making millions of dollars profit from it. And often not even giving credit to us.
People have worked on it as a hobby. Others have taken that and turned it into a business. This has always been the case and always will be. But I digress from the original topic. All the big servers use TrinityCore, whatever they call it, "EpicMythicalCore", is just a rename of Trinity with a few changes for their specific needs, often with bug fixes they have found and managed themselves and they do not contribute it back.
I always focussed on custom content, as can be seen from my YouTube channel:
I have been in emulation since 2006 and participated actively. If you have any questions feel free to ask.

Thanks to people like Stoneharry newcomers have the chance to get into emulation and programming very fast. Since the date I registered to mmowned which was around 2009 I am amazed about this guys dedication.

Link to the original topic:

Mittwoch, 15. April 2015

[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.


Donnerstag, 5. März 2015

[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 (
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 my 1.12.1 bots source code:

Lately a lot changed and I just dont find time to be the same no lifer I used to be back then so I might be a bit inactive and since I wont continue this project I am happy if someone can take advantage of it. I hope the bot will be a help to players aswell the administration of most 1.12.1 servers.

Samstag, 14. Februar 2015

[Tools] Whatsapp for your Computer

With, a smartphone and the latest Chrome browser people can finally start using Whatsapp on the PC. The problem is that the webclient communicates with the whatsapp servers using your smartphone resulting that your phone needs to be connected with the internet all the time.

Another approach is offering a plugin to use whatsapp without depending on a smartphone. Since whatsapp is limited to one device per account at the same time you cant however use it on your smartphone simultaneous.
This tutorial is rather dedicated to people who refuse to jump on this smartphone trend and stil want to use whatsapp.

What we need?

  1. WhatsApp for PC - Whatsapple Client
  2. WhatsApp Registration Tool
  3. A number not registered to a whatsapp account

Lets do it

1. Download the WhatsApp Registration Tool and Execute WART- Enter your phone number and leave the Password (optinal) field empty. The zero of your number have to be replaced with your country code (e.g: 0XXXXXXXX -> 49XXXXXXXX for Germany).

2. Hit "Request Code". A popup will alert you that a SMS has been send to the number containing a code.

3. Enter the code at Step 2 and click "Confirm Code". Another popup will appear stating the secret you recieved from WhatsApp. Note it down and proceed with step 4.

4. Install "Whatsapple - Whatsapp for PC" and launch "PidginPortable" inside its root folder. Afterwards do the following:
  • Close the popup and navigate to the window with the title "Buddy List"
  • Hit "Accounts" followed by "Manage Accounts"
  • In the new window hit "Add..."
  • Select "WhatsApp" as protocol
  • Enter your phone number (once again with country code instead of 0) as Username and the secret you got via WART as Password
  • Tick "Remember password" and hit "Save"
The result:

5. Add contacts hitting "Buddies" followed by "Add Buddy...". Buddy's Username is the phone number (country code instead of zero) and the Alias the name which will be used to display the contact (leaving it empty will result in only seeing the number):

Final words

I dislike WhatsApp for many facts however convincing all the people you deal with to switch to a better client is just not possible. Telegram for example offers great security and a desktop aswell smartphone client which are both independent from each other.