Freitag, 4. September 2015

[1.12.1] ZzukBot finally released!

While working on the bot all the months I never thought about pushing it that far but seeing the vanilla WoW community coming to live again gave a lot of motivation ... actually enough to spend countless nights working on this little guy.
ZzukBot finally goes live under!

Join the forum and help improving this project aswell building a community!

Montag, 17. August 2015

[1.12.1 WoW] ZzukBot

Look here for development preview videos - a level 60 warrior customclass
Look here for development preview videos

Most people visiting this blog or being active on any WoW hacking related forum should have noticed that I released my tool ClassicFramework a few weeks ago. Purpose of this release was to gather information and new experience when it comes to developing software which is supposed to run stable on any computer using Windows.
At this point I want to say thanks to all users that reported all kind of errors and problems I never experienced myself. A great anmount of the fixes for ClassicFramework also improved this upcoming release.

ZzukBot is a WoW bot designed for the version 1.12.1 also known under Classic or Vanilla WoW:

(Click on the thumbnail at the bottom to load the picture in "big")

A few pearls and features of the bot:
  1. Automatic path generation based on hotspots
  2. Reacts on different notifications: "Target not in line of sight", "You cannot attack that target" etc.
  3. Blacklisting for bugged mobs (fight blacklist and loot blacklist)
  4. Vendoring, Repairing, Restock
  5. CustomClass system
  6. Overrideable Fight, Rest and PreFight routines
  7. A very well designed unstuck system (even tho you will probably never ever get stuck :p)
  8. "Intelligent" resurrect: Will search a possible safespot before resurection
  9. Taking hostile mobs in consideration while searching, pulling and fighting mobs
  10. Fight movement: To close for Auto Shoot? Move back until in proper range again
  11. Relogger
  12. Running stable for countless days on Windows 7, Windows 8 and Windows 10
  13. Chat logger
  14. Item management
  15. User friendly profile creator
  16. Lightweight Interface
  17. Full Warden protection
  18. Ghostwalking

The two "Help" buttons: 


Wondering how the grinding process looks like? Here you have a little preview video:

Sample profile and the most simple CustomClass possible:

I extracted a list of everything provided by our API for those who are interested in CustomClass development. Beside of those functions you can use the full power of C#:

 Virtual Byte DesignedForClass  
 Virtual String CustomClassName  
 Virtual Void Fight()  
 Virtual Void PreFight()  
 Boolean ToCloseForRanged  
 Boolean Backup(Int32 yards)  
 Virtual Void Rest()  
 Virtual Boolean Buff()  
 Int32 Rage  
 Int32 ManaPercent  
 Int32 HealthPercent  
 Int32 Energy  
 Int32 TargetHealth  
 Boolean NeedToEat  
 Boolean NeedToDrink  
 Int32 ComboPoints  
 Boolean CanOverpower  
 Int32 AttackerCount  
 Single TargetHealthPercent  
 Int32 PetHealthPercent  
 Int32 PetManaPercent  
 Boolean IsResting()  
 Void Eat()  
 Void Drink()  
 Void Eat(String parFoodName)  
 Void Drink(String parDrinkName)  
 Single DistanceToTarget  
 Boolean PlayerGotBuff(String parName)  
 Boolean PlayerGotDebuff(String parName)  
 Boolean TargetGotBuff(String parName)  
 Boolean TargetGotDebuff(String parName)  
 Boolean PetGotBuff(String parName)  
 Boolean PetGotDebuff(String parName)  
 Void Attack()  
 Void StartWand()  
 Void StopWand()  
 Boolean CanUse(String parName)  
 Void Cast(String parName)  
 Void DoString(String parLua)  
 String GetText(String parVarName)  
 Int32 GetSpellRank(String parSpell)  
 Boolean IsMainhandEnchanted()  
 Boolean IsOffhandEnchanted()  
 Void EnchantMainhand(String parItemName)  
 Void EnchantOffhand(String parItemName)  
 Boolean IsWandEquipped()  
 Boolean IsTargetCasting()  
 Boolean IsTargetChanneling()  
 Boolean IsPlayerCasting()  
 Boolean IsPlayerChanneling()  
 Boolean IsAoeSafe(Int32 parRange)  
 Void PetAttack()  
 Void PetFollow()  
 Void PetDismiss()  
 Boolean GotPet()  
 Boolean IsPetAlive()  
 Void PetCast(String parPetSpell)  
 Boolean PetCanUse(String parPetSpell)  
 Boolean IsPetHappy()  
 Void FeedPet()  
 Boolean IsPetTanking()  
 Boolean IsPetOnMyTarget()  
 Int32 ItemCount(String parName)  
 Void UseItem(String parName)  
 String GetLastItem(String[] parListOfNames)  
 Void SetCombatDistance(Int32 parDistance)  
 Void SetWaypointModifier(Single parModifier)  

Release and other stuff

Right now we are done with the whole bot logic aswell the server part of the authentication system. Website with Forum, Accountmanager and automatic payment system is also ready to welcome new users. Next task is to setup a windows server which will run the auth server and find a way to protect binary.

Speaking of protection I am pretty unsure what to do with nearly every commercial crypter having a price out of my budget. If someone is into this topic I would be very glad for a helping hand to lower the time until release.

Even tho it seems to get old I want to say thanks to every visitor and every user of OwnedCore who helped me learning new stuff. Also thanks to Bitbucket which send 20 hours progress into nirvana :p

Freitag, 17. Juli 2015

[C# / 1.12.1 WoW] Zzuks ClassicFramework

Stop using the tool on Nostalrius for the moment - there seems to be a problem

The Anti-Warden mechanics ensure that no memory change can be detected however it doesnt protect you from servers which implemented server-side mechanics to verify if specific actions or movements are possible or not. To make it short: Use it on your own risk!
Features not affecting the movement are possibly never detected.

Since the interest in 1.12.1, vanilla or whatever you want to call it raised a lot with the release of Nostalrius and Kronos I prepared a little tool with different features which can be acivated over functions added to the WoW Lua api ( /script Function(x) ):
  1. AddToZ(x) - increases the players Z axis by the passed value.
  2. Interact() - interacts with your current target (attack, loot, speak and also walkt to if click-to-move is enabled)
  3. Loot() - loots all corpses in range of the players toon
  4. NoClip1-4() - 4 different NoClip modes which can be toggled on/off separately
  5. SuperFly() - Toon is locked to his Z axis thus walking on air
  6. UseItem("x") - Made for items like grenades. Item passed by name will be used and activated over the current target (player, unit, critter - doesnt matter)
  7. UseSpell("x") - Same as UseItem() just for spells like Blizzard
  8. UseObject("x") - interacts with the closest object matching the passed name (mailbox, warsong flag etc.)
  9. Wallclimb(x) - pass a value between 0 and 0.64 to define the angle your toon can walk
  10. AutoLoot() - Enable or disable autoloot (will remain through restarts obviously)
  11. SaveBars("x") - Save your current action bar profile
  12. LoadBars("x") - Load a previously saved action bar profile
  13. RemoveBars("x") - Remove a previously saved action bar profile

Beside the above features there are a few passive hacks which are always activated:
Understand all languages
View all levels hack - You won't see that "boss icon" on levels anymore (thanks to reliasn for the description I copied lol)
Lua unlock - Use function like Jump() in macros

More infos?

ClassicFramework doesnt have a GUI and is completely controlled over the chat:
Every function is reapplied each login. Every single value altered in memory is hidden from Warden.
Projects like Nostalrius like to claim they invented the perfect anti cheat but to tell the truth you are very limited as a private server developer:
While Blizz can implement anti-cheat-mechanics everywhere in the client private server projects cant extend the client but only relay on server-side-mechanics aswell Warden.
With that being said I only chose features which I personally see as nearly unable to detect without Warden (which I disabled like mentioned before).
Everything has been tested on all public 1.12.1 realms including Nostalrius and Kronos.

Every feature is designed as user-friendly as possible:
About(), Thanks() and Commands() helps the user with everything this little project can do.
Every function is double checked for valid parameters and will also give help if the user enters wrong arguments.

Zzuks ClassicFramework in action


I tested everything as good as possible under different conditions however this doesnt mean you will have the same good experience: Since this tool is intended to work for everyone its important that issues are reported. Just contact me and I will try to solve the problem.

Thanks to ....

Namreeb, Sacred, Culino and the usual people. Without you guys this wouldnt be possible.

Download and Requirements



* Offline for a major upgrade *

Like the tool? Feel free to donate a few bucks


  1. Fixed a bug in the detour for Wardens module enumeration 
Each write to static memory is hidden . Each injected module is hidden. Both are double checked! Enjoy

  1. Extended the ReadMe with more hints which should help incase the hack doesnt work
  2. Switched from fasmdll_managed to Fasm.NET
  3. Lua functions will be unregistered on logout and registered on login instead of just registered
  4. Fixed a bug inside the Anti-Warden module which lead to a detection of NoClip4() and a few other internal things
  5. Several internal tweaks to the Anti-Warden part
  6. Another attempt at fixing the problem described in point 3 of v0.06d
  7. Compatible to Windows 10, 8 and 7

A few users reported recieving a ban on Nostalrius. Since all tools I previously wrote were for private use only I never paid big attention to possible security flaws while developing - something known by nobody wont cause attention any way.

With the above in mind I wrote myself a checklist which every new update need to pass. Also each new update will be tested on Nostalrius for multiple hours before release.
Like always: Never hack on accounts you cant stand loosing. The passive features wont be detected and are safe to use.

  1. Updated ReadMe.txt with better instructions and added a picture
  2. Once again a few crash fixes
  3. One guy reported that the tool didnt work if placed outside the WoW folder. Now this should be fixed to.

  1. Another crash fix

  1. Some users reported that the tool wasnt able to find fasmdll_managed even tho it was in the root folder. This version should finally get rid of all these annoying errors

  1. Moved ClassicFramework.exe to internal folder (to finally get rid of all the "dll not found" errors)
  2. Added ClassicFramework.cmd which will be used from now on to launch the hack

  1. Added a by default activated Anti Afk feature
  2. Added the version (v0.05 in this case) to the welcome message
  3. Fixed a dll not found exception which occured for some people (need testing here)

  1. Added a ReadMe.txt with version identifier and some hints
  2. Further improve for Loot() aswell AutoLoot()

  1. Fixed a conflict between Loot() and AutoLoot()

  1. Updated About(), Commands(), UseItem("x"), UseObject("x") and UseSpell("x") help texts
  2. Fixed crashes if string parameters are passed without quotation marks ("")
  3. Tool will only start if executed as administrator from now on (since it doesnt work otherwise)
  4. Removed "bind on pickup" dialog skip (will be only enabled while Loot() is doing its work)
  5. Added AutoLoot() to enable and disable autoloot (cloned the one which got added in TBC). The state (enabled/disabled) is stored so it doesnt have to be activated each launch.
  6. Changed from debug to release build (no more dll errors). Sorry for that :p
  7. Added additional security checks
  8. Migrated the barsaver into the current project (video:

First Release

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.

Freitag, 12. Juni 2015

Another bot for 1.12.1

When I started this blog I thought I would be one of those bloggers writing a post every second day. Well .... atleast the blog is stil living :)

Since the summer finally arrived at germany I rather spend time working on freerunning instead of programming:

Speaking about programming I have made a few decisions:
The current 1.12.1 bot I work on is getting better everytime I find a minute to work on it and even tho I enjoy playing around with the WoW client this will probably be my last project for WoW since I feel like its time for something new.
The code for the bot will go public but at the moment I am not completely sure how and when. Maybe I will release a closed source version first of all (can be expected within a month).

The custom class used in the video:
Since the video is very short it doesnt show the full potential and all features of the bot but as a first teaser this should be enough.

Also I am open for people who want to help extending the bot. Currently I struggle a lot with path generation between two points with a distance about half of elwynn forest and bigger:

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: