Beating Hack0rs With a Stick Part Deux!

I find it interesting how the "guardian mob" idea revolves around the explorable or other area being "physically real." It is as though those things have to be there a certain way to do the task because of how the bot is built.

Let's say for a minute a bot is detectable. Now the bot and henchies enter some area to go after the treasure boxes there, however, before they get to the first box the bot is detected. The mobs that are there just disappear and the henchies go into "statue" mode. Suddenly as at the end of the last BWE Gwen appears, talks to the bot in her unique affectionate way, "I don't like you!" and continues to inferno them with the words "Thank you for playing"--the detected bot Gwen's only target.

Its a computer game folks, nothing physical to the world at all, anything is possible because it is a generated world so if the programmers and the testers have done there jobs, even the scenario I just described is possible.

Let's not overestimate the power of the macro or it's user, they win by cheating or don't care to be good at the game in the first place, just something to do for them, or, who the heck knows why they do it. I don't really care as long as they receive a proper "reception" when discovered.

Anyway, my input of the day.

This is probably the stupidest idea ever and it won't work in a billion years because I have no idea what I am talking about, but here goes (note, I know absolutely noting about programming that is not web programming, and even then I'm pretty shoddy)

What if every movement you made required a random figure attached to the packet. Like say the number "5" or the letter "a." What I mean is what if the movement packet you send to the server to tell it you are going to move had one extra figure that the server would set using the streaming technology every say, 5 hours? I don't suspect it would cause a large increase in packet size, and if the streaming technology could simply change that number on the client and then recognize it on the server then it would work.

What I mean is say the packet was "I am going here" "7" (this is for visual purposes only). So when you click where you go you send the packet "I am going here" "7" Then later they changed the number to say, 9 so you sent the packet "I am going here" "9"

What I am getting at is that bots that send packets for movement would not be able to emulate this number because they would be sending the pre-programmed packet that is the same every time (execpt the movement coordinates). The only way the bot could compensate for this is to send a normal clicking packet, then sniff the packet and enter in the code. But I don't see how a bot could handle this. Furthermore, if ArenaNet hid the location on the client of this random number, it would be much harder to find.

This would not stop "macro bots" but I have rarely seen one that really works that well. E.g. any interference would totally throw it off. Even the smart bots that used cursor movement tech in D2 got hung up and had to exit because they were moving incorrectly like 1/10th of the time.

well, considering the bot is online when the streaming takes place and the command set interpreter, assuming there is one, is what you are suggesting gets changed, then...isn't the bot client being changed at the same time and obviously they won't change the commands you and i use every few hours, so in essence the bot continues to move unhindered because it remains a code corrected client.

Pretty good detail you got into there though. I mean, maybe there something to it. I am just a BWE player and don't know anything about the inner workings of the game. Maybe someone who does will see a way what you are saying could be used. Although now the other type of hacking to modify character stats and such might be vulnerable. Haven't a clue but figured would throw out something to help you brainstorm your idea Zfactor.

Good luck, and, was a good effort!

It really depends on what kind of bot it is. I only have a basic understanding of all the different kinds of bots. However, (if I did understand this correctly when it was explained to me) some of the more advanced bots used coordinates on the maps to navigate. As opposed to emulating a click on these coordinates, they sent the packet saying a click was made. The thing about this is that the packet type has to be programmed into the bot, so it would not be easy for them to program it to send the packet plus the random tagon.

For bots that navigate by having the cursor move and perform a click (physically), it would not matter (obv since it would be sending a regular packet). But if my random thought on putting these tagons was to work in practice (which I don't know if it would) then it would really only reduce a bot problem, not fix it.

But like I said I am not a programmer

That's rather elaborate. Rather than do all that, why not simply terminate the connection and don't allow a reconnect? Much more effective, and much easier, too.

Actually, it would be child's play to do exactly that. It's actually easier to do that than it is to send valid click/movement coordinates.

How would it be easier for the bot to guess the random tagon. Something I forgot to add in there would be like if you send the wrong tagon you get banned for like 30 mins or someting-but also this doesnt apply for 1 min before and after a change of addon to avoid carrover moves that cause banning. A perfected system would never ban a regular user but quickly ban a bot from playing for 30 mins every time it sends the wrong addon.

The bot would have to somehow detect the random figure, I suppose by using a built in packet sniffer and then clicking physically to get the code. But like I said it would not stop all bots. Little things like that would certainly cut down on them (if it could work, which again is up in the air)

How does the real client determine the "random" tagon?

Well like I said the streaming update would have to send that information to the user in an unconcealed location. Obv anybody with enough time would eventually find out where the data is held, but since a bot is seperate from the client, it would not be able to directly recieve that information.

There are workarounds around any anti-cheat measure as long as there is time and people willing to do it. I never said this was a failsafe solution or the only solution, just one that woud help cut down on the nubmer of bots. Its not like ArenaNet is going to reveal the information on how they are going to stop bots. Quite frankly I hope they never tell what anti-bot measures they take.

And yes, inherent flaws in the system are a person simply making a bot with an enterable variable that you get from sniffing a packet for that 5 hour time span or whatever, but bots that take that much trouble generally do not go public.

False. In fact, the bot can receive any information contained in a steaming update just as easily as the client program can.

Alas, it would do no such thing. The problems involved in actually making a bot send valid movement commands are larger than the ones involved in defeating the scenario you've proposed. Anyone who can make a bot at all would find defeating this method to be child's-play.

When thinking about anti-bot measures, understand that the bot sees everything the client program sees and knows everything the client program knows. There's no information that the client program can take advantage of that the bot can't do the same. If the client program can figure out how to construct a valid response packet, so can the bot. Both the client program and the bot have complete access to the data on the client-side computer, and both the client program and the bot see every bit of data that comes from the server. Any scheme for discouraging botting needs to take those facts into account.

[QUOTE=Dreamsmith]Um, huh?

If the mob has a different appearance than a normal monster, this again is more quickly recognized by a bot than a human.

Sorry I messed up the quote a lil

This is what concerned me.If there isn't anyway to fool a bot visually,then how can a bot be fooled?There has to be someway or somehow without adding a lot of security?

There is. Constantly change the protocol used for communication between the server and client. Constantly move things around in memory, change the order of things in data structures, etc. You'll notice that, for example, Diablo II botting programs like d2jsp or the like always work with a specific patch, then need to be updated when a new patch is released because they don't work anymore. If Blizzard released a new patch every day, botting would virtually come to an end. It's easier to the developer to rearrange things than it is for the bot writer to reverse-engineer the changes. Take advantage of that.

Streaming client updates, anyone? Believe it or not, ArenaNet is way ahead of a bunch of fans on a message board thread when it comes to thinking of anti-bot measures... whodathunk?