Grey Hat Botting

[Mizoki]

Hello All,

I have been botting for years now in various games purely on an entertainment level. As a hobbyist coder I have found botting to be very intriguing and enjoyable, however the majority of my botting has been at a user level, with minimal scripting done on my own. I recently started playing RoM and of course decided to look around to see what bot software was available which of course brought me here. I have spent the last few weeks playing with the existing MicroMacro/RoM bot and poking through the code with much enthusiasm.

I have decided for a little learning project that I wanted to do some scripting and came up with a few ideas and just wanted some feedback from the pro's thus I am posting this message.

For starters, the current RoM bot is created under MicroMacro v1, (and of course the subsequent addons/scripts/waypoint files, etc). I have been looking at the API's for both version 1 and 2 (1.94 beta), and see some great improvements (yet still somewhat lacking in some functionality that I would like to see, but being that I am no expert, these are merely personal observations and in no way am I suggesting any negative point of view). I am however curious as to the status of any projects moving RoMBot to version 2 thusfar if any? I have been playing around a little with writing some code (and porting some existing code) at an entry level (again mostly just me learning).

My second thought was to start working on a C++/C# project separate from MicroMacro, however the research over the past few years indicates that botting on a generic level is too easily 'detected' with injection/reflection. Without having read through the MicroMacro source, I am curious how the bot interacts with the game client, and how (if any) it handles anti-detection. The reason I ask is that I have also found very few resources in my searches to avoid detection (from a programming aspect, while I do understand it from a user perspective. ie. not botting 24/7, avoiding high traffic areas when botting, etc)

My third thought was to just use the existing RoMBot platform to begin with because it seems solid enough, and start implementing some functionality on top of it. My concern with this path however is that RomBot becomes legacy and highly rewritten for MicroMacro 2 and I would much rather work on more current implementations. One of the major changes that I am considering for a project is to build a dynamic A* pathfinding system that either enhances the current waypoint system or replaces it altogether, so that bots are deciding paths that they want to take making them more 'humanistic' than all following the same waypoint paths.

Again, I am no expert, all the above is more about me wanting to move from a user to more an active developer role. If anyone could provide some information regarding upcoming RoMBot releases for MicroMacro 2, or a general idea of how MicroMacro is interacting with the game client (so i don't have to sift through the code ) or even thoughts and ideas related to this post, I welcome any discussion. I realize I am a new member and this is my first post, I am not looking to bring out the trolls or listen to any ignorance, so please leave that for someone else, I am merely interested and learning.

[Administrator]

No, we're not going to be converting it to MM2 because that would essentially be a complete rewrite on a basically dead project. While I applaud those willing to take up the challenge, I'm far too busy with work and other projects to do it myself.

The RoM bot script works by reading the game's memory to gain awareness of the client, and writes memory or simulates keyboard input sent to the client to control it. Fairly simple, really: Use WASD to move, TAB to target, hotkeys to fight, and so on. Some things are done via in-game macros, which the RoM Bot script will dynamically create and execute within the client.

Also, I must say, I'm glad to see another enthusiast here doing it just for fun & learning. That's great!

[Mizoki]

Thank you for the response. Side note, some may be curious why I titled the thread "Grey Hat Botting". My reason being is because I would consider myself as a Grey Hat botter. I don't bot for profit in any way (which I would consider the Black Hats), and at the same time, I realize and understand that botting is against the rules / terms of service of pretty much any game where I have botted in the past. My goal was never to 'affect' the game, (which on some levels of course it does). I have done a lot of research over the years and found all sorts of reasons why people bot, and I have read lots in regards to why botting is against TOS and the negative impact it does have on the games. I see valid arguments from both sides, and my reasoning falls somewhere in between (hence "grey").

I don't really agree with those who bot for profit, but I am also not going to call them out and bash them either. They have found a way to beat the system and make money, accepting the risks that they do, good for them, their choice. I bot enough to get enough resources so I can enjoy a higher level game than I would normally be able to with sometimes limited amounts of time to play. So I might get a bit of gear with gold, level my character to max to enjoy endgame content, etc, that I would otherwise be unable to fit into my schedule (and possibly even my skill level, I am not a great player of games by any stretch, I can admit it). But what I really enjoy is being able to use (and even script), a tool that will do the stuff for me. I get more of a sense of accomplishment than I do actually playing the game. I wasn't always that way, but over the years games have also gotten more repetitive and require a lot of grinding just to get to certain places and do certain things which in my mind takes the fun out of a game. I mean once you have gone through the quest lines for Vanilla and Burning Crusade a dozen times (without botting), you know the entire storyline and to do it again so you can play a different class or different faction, well, I'd rather just set the bot to go do it, so I can enjoy later content.

As for conversion to MicroMacro 2, you say a rewrite on a basically dead project. I didn't realize it was a basically dead project. Is the bot being detected (easily) now so people are no longer using it? I have only levelled a few characters with the bot through the starter areas both to get an idea of how the bot works as well as the dynamics of the game. (I have never actually played Runes of Magic before). From what I have read Jagex is talking a lot about bot killing and because I have not really done anything too much in game besides the starter areas, is that what was killing the project? I would love to take up a rewrite for MM2 if there was interest (and have already started poking around with it), but if it is essentially dead maybe I could take MM2 and start hammering out something for another game even that is of more interest.

I am not worried in the least about bans or anything, I have had my share in other games Currently under 6 month suspension (this time) which got me poking around other games which is how I came across RoM actually. I've had perma-bans and suspensions in wow, lost my main the first time which hurt a little, but rebuilt each time, created new accounts, and went again. So I'm no stranger to suspensions and bans, nor do they even bother me anymore. I would like to take on a project that is of interest to others as well however, so I am not the only one enjoying my efforts

I would love to talk more about design ideas and development stuff, if you have some time (and don't want to post some publically), feel free to PM me here.

Also to everyone else, I would love to hear how much interest there is for me to port RoMBot to MM2? If I do port it, I would need help with scripting of activities and quests and stuff as most if not all of the MM1/RomBot will not work under the rewrite. If there is not enough interest in RoM, what other games do you feel would benefit from a bot, maybe I can look at other options.

Peace!

[Mizoki]

One other thing I was wondering, has anyone figured out yet if there is a way to detect if a specific quest has been completed yet or not? Or even what quests are currently in the player quest log?

[BlubBlab]

Sry this took some time I was bound to my chair playing B&S ^^

Well most of what you said in your initial post is very much know. MM 1&2 using the windows debug interface so reflection to transmit data between the client and MM.
The nice thing about ROM is that it hasn't any protection and Runewaker are far to lazy to do anything about it on top of it the costs for the effort in compare to kick out 20 botters or so is far to great at that point.

Botting is mostly focused on Asia Grinder f2p MMOs because they are grinder and people don't have so much time or
they want to go around the walls that the f2p put on the game or
they find that part of the game stupid

About the evolution I started to write a new bot for MM2 which use large junks of code from Rombot I didn't finish this but I was nearly finished with the movement part I only needed to put everything together for main routine and test it after that the fight routine and potion would be next.

I wrote it so it would be easy to change and highly adaptable a framework for Mm2 to be precise, the idea was that I can make bot very quickly for a new game. Maybe going even further then this and let it run on real bots like Lego Mindstrom (adapting MM for it would be a challenge).

The huge problem would be that you still need all the addresses out of the game you still need to find them even when the coding is reduced to the absolute possible minimum. Pathfinding is the same you need the know the internal representation admin did something about it and I discriped a way to unstick a bot also with pathfinding when you don't have the internal representation.

The reason I don't do much at the moment is I play Blade and soul and I'm on a job search. Properly the other reason why I'm not super motivated most of the games I want to write a bot MMOViper does it under 3 weeks. The last part has to deal with protection and detection in/of those MMOs Im just not much of an hacker enough to do this.

[beanybabe]

I like what you have done and have always wanted to see it evolve into a real game that encouraged bottling of sorts to start a new generation of programmers learning code much like the raspberry pi is trying to get new programmers working on android devices. I often thought it was silly game company prevent bottling when they should be encouraging it. The future is going to need lots of creative programmers to keep the billions of people entertained.

[Mizoki]

In my younger days (I started back in the days of the old Radio Shack / Apple days with mono screens), I remember a game we had on the Apple computer that forced us to program our tank to go up against a computer tank, each level we got new commands to program in, to turn the tank, turn the turrets, scan for nearby enemies and ultimately kill the enemy tank(s). To this day I can't remember the name of the game, but it was really an intro to botting when I think back. There were no keyboard controls to the game, we had to decide before entering the level how we wanted our tank to react against the enemy tank, and then let the program do what we told it to in hopes to make it win. This was early 1980's.

While I don't necessarily agree that game designers should encourage bots in their game (because as stated, they have very valid reasons to being against botting as it does devalue the gameplay for those who really want to play the game without botting), I do wholeheartedly agree that we should see a new genre of game that does allow botting and pitting your bot up against other bots to both compete against as well as team up to achieve common goals. I have thought this for a long time now, and even considered developing a game specifically for people who were interested in developing bots. Something I may consider for a project in the future. A game like that would somehow have to balance the game so that it is not advantageous for botters and non-botters somehow, or essentially not encourage real gameplay. I would have to think about this further on how to balance it.

For a game based around botting, you would have to somehow base it on the bot programmers skills from basics like movement and simple combat, to advanced combat routines, maybe avoidance of bot detection systems (which would create some kind of disadvantage if they are actually detected) and other things. Maybe a multi-faction system (similar to) horde vs alliance where each faction's bots are competing for dominance (while somehow ensuring that it doesn't become a single bot vs bot scenario, where everyone is actually designing their own bot still).

There are many challenges to creating this genre of game, but the concept is fantastic. Giving those who enjoy botting for fun a place to play legitimately, I think would be fantastic. A huge task for a developer too because the developer would need to 'outbot' the bots. I think would require some very highly skilled botters to even make it work. (which is why I haven't taken on a project like that myself, I have a long way to go just learning all the ins and outs of botting as a user )

[Mizoki]

Oh and further note, game companies like Blizzard/Jagex, etc somewhat do encourage botting (even if unintentionally). Blizzard comes out with new expansions, and while the storyline of the content changes (some storylines better than others ), the actual gameplay doesn't change. Its always interact with this object/npc, or kill this many mobs, or pickup this many items, or some combination of those tasks. Combat is a matter of calculating the best rotation out of your (now) limited custom skillset and with fan sites, the builds become mostly the same "best" skill choices across the class. There seems to be little to no innovation on making the player do anything new. I don't exactly know how they would make things more fresh and new thats something they would have to figure out.

So this kind of repetitive nature really (unintentionally) encourages botting to deal with the monotonous grind. But at very least, they complain about dedicating resources to dealing with botting rather than resources to create new content. How about find a way to combat the botters by creating new and creative ways to challenge the players and deter the botters that way thus making it harder for the botters to keep their bots working. Win/Win I think.

[Administrator]

No, the bot isn't being detected and/or blocked. It would be fairly trivial to block the executable (micromacro.exe), but if they decided to do that it would be incredibly easy to get around (just recompile and/or rename the executable). Things like GameGuard or HackShield can prevent MicroMacro from interfacing with programs (by using a system-level hook to block the interaction), but even those can be gotten around (with some effort). To the best of my knowledge, no form of anti-cheat will block MicroMacro. And realistically, it shouldn't; MM is a legit software, what users decide to do with the scripts is another thing all-together.

The RoMbot project is still functional, but the code group has gotten bored of supporting it all these years or have become too busy. I know I'm quite busy with work (lately, I mostly spend my time writing code for restful APIs) or donating my time to other volunteer projects. Worst yet, I recently broke my arm while getting ready for a date; sure was embarrassing having my partner help me into that dress after that. I still want to continue working on MM2 but honestly I'm not even sure what to improve on or add in at this point.

[Mizoki]

About the evolution I started to write a new bot for MM2 which use large junks of code from Rombot I didn't finish this but I was nearly finished with the movement part I only needed to put everything together for main routine and test it after that the fight routine and potion would be next.

I would be very interested in taking a look at the code you have (if you of course are interested in sharing). I myself have started doing the same, nothing in the way of new code yet, but porting some of the MM1 RoMBot code to MM2. I am not completely convinced yet that completing it as a project would be beneficial, especially if its already largely complete.

I wrote it so it would be easy to change and highly adaptable a framework for Mm2 to be precise, the idea was that I can make bot very quickly for a new game. Maybe going even further then this and let it run on real bots like Lego Mindstrom (adapting MM for it would be a challenge).

A lot of what I have been reading up on is the difficulty of hooking into game clients and using reflection/injection in the sense that it is very easily detected. I suppose injection would be easier to detect because you are attaching to the process (and subsequently modifying the client, making it pretty easy to detect by the client). With reflection you are making a copy of the memory to work with, so it might be harder to detect (still learning so I don't fully understand it all quite yet).

The huge problem would be that you still need all the addresses out of the game you still need to find them even when the coding is reduced to the absolute possible minimum. Pathfinding is the same you need the know the internal representation admin did something about it and I discriped a way to unstick a bot also with pathfinding when you don't have the internal representation.

Yes I have been learning lots in this area and it is quite challenging. I have been playing with the different tools Cheat Engine, OllyDbg, x32dbg/x64dbg, and WinSpy. Finding addresses can be a challenge for sure, but I am starting to get the hang of it. I do need to brush up on my ASM skills though, I haven't done anything with ASM in many many years, and I think the process would be much easier once I re-learn stuff I have long forgotten in that area. As for RoMBot, I think that so far is one of my biggest annoyances is the pathfinding system. Well its not really pathfinding, its a bunch of waypoints that the bot follows to each quest. Having used the (buddy) botbase a quite a bit, I really like the navigation mesh/pathfinding system, better than strictly a waypoint path from point a to point b. Would be a lot more human looking if every bot wasn't following the same waypoints, rather determining their own path based on what they want to do next.

The reason I don't do much at the moment is I play Blade and soul and I'm on a job search. Properly the other reason why I'm not super motivated most of the games I want to write a bot MMOViper does it under 3 weeks. The last part has to deal with protection and detection in/of those MMOs Im just not much of an hacker enough to do this.

I think that's the dilemma of most botters, and something I really want to learn. I believe anyone (at least who enjoys botting and has some programming skills) can learn the skills necessary to become very good at it given they put the effort in to learn. It's not something that's easy by any stretch, but definitely something I myself am interested enough in to learn all I can to become good at it. I am sure there are also many like me who would also feel the same.

[Mizoki]

No, the bot isn't being detected and/or blocked. It would be fairly trivial to block the executable (micromacro.exe), but if they decided to do that it would be incredibly easy to get around (just recompile and/or rename the executable). Things like GameGuard or HackShield can prevent MicroMacro from interfacing with programs (by using a system-level hook to block the interaction), but even those can be gotten around (with some effort). To the best of my knowledge, no form of anti-cheat will block MicroMacro. And realistically, it shouldn't; MM is a legit software, what users decide to do with the scripts is another thing all-together.

I agree, early on when I started looking at this project, I was looking at the API / docs for MM2 and really liked the improvements from MM1. I (had) some ideas when I was playing with porting the code for Rombot to MM2 I could share, I just have to go back and revisit the docs again myself, I have been slightly distracted from doing anything with code the last few days with late night volunteer work, wifes birthday, kids valentines parties, etc. But if you are open to suggestions, I will go back through it and come up with some ideas if you like.

The RoMbot project is still functional, but the code group has gotten bored of supporting it all these years or have become too busy. I know I'm quite busy with work (lately, I mostly spend my time writing code for restful APIs) or donating my time to other volunteer projects. Worst yet, I recently broke my arm while getting ready for a date; sure was embarrassing having my partner help me into that dress after that. I still want to continue working on MM2 but honestly I'm not even sure what to improve on or add in at this point.

Ahh restful API's fun stuff. What language/platform? I have done some work with Apigility (php based/zend stuff), its a nice platform for building quick restful apis. I haven't worked with any other languages besides PHP for web stuff myself (not that I am opposed to other languages, its just what my clients have preferred), so its what I have become most comfortable with.

[Mizoki]

So what I have been reading on as of late with regards to detection mechanisms is that:

- Reading memory is generally not detected
- Actions, movement/combat, interaction should be done through virtual key/mouse actions to avoid detection (IE not modifying memory to do things)
- And doing actions should not be 'bottish' so as to attract attention to you to get you reported.

That's my preliminary understanding from what things I have read. I would love to hear other recommendations (as this list seems too easy to create bots to avoid detection) what other considerations should I be taking into account. Anything I can google and add to my list of research resources is welcomed.

[Administrator]

Ahh restful API's fun stuff. What language/platform?

Mostly PHP stuff, domain-driven design. We're targeting Linux & BSD, using MySQL, and Laravel 5 (dev), some work with Android devices. I may need to do some stuff in C/C++ targeting Windows & Linux later. What I do ends up being a lot of boring financial garbage.

I have done some work with Apigility (php based/zend stuff), its a nice platform for building quick restful apis.

Now that's something I don't have much experience with. I've kind of been pulled into, and stuck with, PHP because that's where the money is. I'm aware of all kinds of niche tools and languages for all kinds of tasks, but PHP just works.

[beanybabe]

I agree bots are good and bad in games to use a bot in siege is bad that is player vs player time and even the battle addons seem a bit unfair in siege. Bots should do what bots do best that is repetitive grinding and very annoying quests. I sort of draw the Grey line between things I do alone and things I do with others

[Mizoki]

Well after some consideration, I think I am going to just start porting MM1 scripts over to Lua, and get comfortable with the process, and maybe move towards either moving the whole infrastructure into a C++ project that enhances MM2 and builds some additional functionality for user scripting to work off of. Some of my ideas include handling path finding, and combat infrastructure to allow people to create their own combat routines.

I suspect that this was left out intentionally to make MicroMacro more generic (and avoidance of making MicroMacro a project that breaches TOS of games in itself). It also makes itself a very good starting point to build of of, and there is some really good information I have learned already as a developer beginner just from information I have found through these forums. While other forums discuss things above my head, I find the information here to be a quite a bit better suited for my development style and skill levels to get going.

Keeping in the open source spirit I will make available much of my work through repositories on github and keep MM2 code licenses intact in the code of course (documenting my changes). I look forward to further discussions here along the way as well, and while I have limited time to work on this, I will try to keep some regular updates going to keep anyone interested informed and discussions open.

I would also like to try to keep things somewhat generic (customizable) in order to maintain some flexibility to be able to build upon for other MMO's as well as we go. So you can feel free to take anything I toss out and build upon it as well.

Thank you to the developers of micromacro for providing this great platform to build upon and sharing it with the public.

[Administrator]

MicroMacro is generic for more than just avoiding legal issues (like WoW's glider bot had been hit with), but because its whole purpose is to just help automate anything. I use it quite often for all kinds of mundane tasks outside of botting games: parsing gigantic databases (for other projects), generating scripts from templates (for work), generating MIP maps (for game development), communicating with web servers (to automate daily tasks across multiple accounts), modding games (used it to edit another game's content files to add in new content), remapping gamepad input to keyboard input for games that don't support standard USB input devices, and lots more. I just find it very easy to prototype some ideas with MicroMacro as well.

With pathfinding, I have wanted to add it into MicroMacro, but then a new problem arises: there's thousands of different algorithms, all with their strengths and weaknesses. At this point, doesn't it make more sense to implement it in Lua as part of the user's project? Or, I suppose, a select few could be tossed into the lib folder and included by anyone if their project actually needs it.

There's been lots of other things that I've wanted to include as well, but have put off for one reason or other. Like, win32 GUIs. Developing bindings for all of that and designing it in a decent way is a whole massive project all to itself. It just seems like something that I would never be able to finish. Plus, there's already Lua plugins for many different GUI libraries, which should be compatible with MicroMacro.

[Mizoki]

MicroMacro is generic for more than just avoiding legal issues (like WoW's glider bot had been hit with), but because its whole purpose is to just help automate anything. I use it quite often for all kinds of mundane tasks outside of botting games: parsing gigantic databases (for other projects), generating scripts from templates (for work), generating MIP maps (for game development), communicating with web servers (to automate daily tasks across multiple accounts), modding games (used it to edit another game's content files to add in new content), remapping gamepad input to keyboard input for games that don't support standard USB input devices, and lots more. I just find it very easy to prototype some ideas with MicroMacro as well.

Yes, I never thought out all the uses but I can see its usefulness in being generic. I completely understand.

With pathfinding, I have wanted to add it into MicroMacro, but then a new problem arises: there's thousands of different algorithms, all with their strengths and weaknesses. At this point, doesn't it make more sense to implement it in Lua as part of the user's project? Or, I suppose, a select few could be tossed into the lib folder and included by anyone if their project actually needs it.

Well, based on the first part of the comment I would see no real use for a path finding implementation. Pathfinding primarily would be for a game bot (though I am sure there are other uses as well), I have looked at a few existing lua libraries for A* Pathfinding that would work, what I was thinking was a fairly generic implementation of a pathfinding system (possibly configurable with different algorithms and huristics), Then the user could create a profile with go to this point or go to that point, and then the system would figure out the path it needs to take to get from current to the new location. Of course the challenge would then be creating the navigation meshes (walkable) for each game. So the user programmable side would involve generating the navigation meshes for a specific game, etc. The other side would to be finding a way to make a humanistic element so that the bot doesn't just "take the best path". Rather take some 'off' paths as well that are sort of in the right direction but more humanistic behavior. (most people walk on roads / pathways when walking) and on long flight paths change (adjust) direction but seldom hit the exact direct path to where they are headed.

So I am just saying that placing the actual navigation system into an MM core project, then the user side (ie Lua scripts), could say something like <quest id="..."><grindarea>some kind of area datatype</gindarea><collect item="2535" count=10></collect></quest> (or something to that effect). Then you wouldn't have to worry about 'restarting' because it wouldn't really matter where you left off rather just matters where you currently are.

I guess what I am saying is that I am interested in taking a generic platform and making it more strictly a gaming bot engine. I absolutely love where the project is at now with MM2, and the fact that it is so generic is great as it allows me to build on top of it with a more customized to a specific purpose, and do so with my own take on how to simplify an end usage for users. Who don't want to necessarily dive as deep into scripting.

There's been lots of other things that I've wanted to include as well, but have put off for one reason or other. Like, win32 GUIs. Developing bindings for all of that and designing it in a decent way is a whole massive project all to itself. It just seems like something that I would never be able to finish. Plus, there's already Lua plugins for many different GUI libraries, which should be compatible with MicroMacro.

[/quote]

Yes GUI would be an awesome idea. And there are many others as well.My discomfort with Lua scripting the bot in general is the event system. Lua while you can thread pieces, it still to me feels very awkward and hacked. I think some kind of event driven system (more specifically related to gaming) could quite easily enhance the ability to watch different aspects (ie watching spell cooldowns for combat systems), something that doesn't belong in MM itself, but would be great for a platform specifically built towards gaming bots thats built on top of the MM platform.

I hope I am making sense with what I am trying to explain here. MM is a fantastic platform and I think would be a great point to build a more specific implementation towards game bots.

[Mizoki]

Further notes I came across a project of interest that could possibly aid in the mesh/navigation pathfinding if you are interested (I am sure there is much more information I need to sift through as well)

http://cutler.io/2011/06/navigation-mes ... orpg-bots/

Shows some interesting tools that are available too.

[Administrator]

Nope, I get it Mizoki. And think it's very cool that you're taking this project up. I'd like to see what you come up with, and maybe we can toss some ideas at each other. BlubBlab also has forked MicroMacro to add in various features, such as OCR. As such, we end up incorporating each others' ideas and fixes. It's great for moving the project forward.

[BlubBlab]

Not OCR but object recognition and movement recognition but I can easily add OCR through OpenCV also I added some filters and function which helps easily to identify basics structure like lines and cycles and n-cornered objects.

What you can do with it is e.g making an alarm by feeding the input of surveillance cameras into it or activate certain actions letting MM2 going on your Skype and when seeing you in a video conference doing something per-programmed.

Originally I made it for ArcheAge when we couldn't go trough the protection but the key pressed were to easily found out to be artificial from Hack Shield but main reason was most of the people lost interest on AA .

What my version also have is some stuff which helps with threads when you use lua-lanes namely a yield method and a dictionary/map in which you can safe information thread-safe in the heap.

Open CV has also other stuff like neural networks and such stuff, the problem with is is the same like path finding a general interface is yeaks to many parameters and multiple versions of it.