Issues sending movement packets

[namreeb]

nope - it stays on until i screw a packet up and the server drops me :P which can be almost indefinitely. still working out the kinks in some of the packets, like movement for example. the server is very picky about movement packets, and if you screw up, bam.. disconnect.

So you DON'T ignore warden? You actually are able to emulate legitimate responses to its requests? Wow, that's impressive.

[BoogieManTM]

Many sleepless nights, obsessively looking deeper and deeper into the hole that is Warden. That is how you emulate it.

wait, wait.. you sleep?? Sissy! :P

[amadmonk]

Many sleepless nights, obsessively looking deeper and deeper into the hole that is Warden. That is how you emulate it.

The irony is that by not implementing Warden in a cryptographically-secure manner, they may have created its own Achilles' heel...

And... I can't speak for y'all, but personally I've already spent many sleepless nights looking into the movement packets, what's a few more for Warden?

[amadmonk]

Streaming is pretty slow in every implementation I've seen. you are better off extracting, or at least keeping what you need in memory once you've streamed it from the MPQ. I'm going with the shared resources route.. load everything once, and have all bots reference that shared memory. It's slow to load up initially, but it's quick as hell and saves ram in the long run (especially if you plan on running a few dozen+ bots)

Yeah, I think I'm gonna just extract the data. Hard drive space is cheap, and it's pretty much a once-per-patch (at most) process. The temptation of being able to just read (known fixed offset into DBC) is too great, and streaming the data out really sucks. 5 minutes just to start my bot for testing a two-line code change is really excessive...

[BoogieManTM]

I see many problems with a clientless bot:

- every warden update would take time to analyze it, a big warden revision could take down the bots for weeks
- false positive scans in warden against warden emulators (like they used in the beginning) will get you banned if you wont emulate them correctly
- client side detections like the ones against glider will get you banned if not responded correcty (when a response is expected)

- botting complex stuff like deathknight tutorial, soa bg or heoric bosses will take a clientless bot fast to its limits but the stuff is easily done in a normal bot
- optimizing wows resource managment and render interface allows to run upto 20+ clients on a single cheap computer with the optional possibility to activate something like normal mode for watching the bot when its get stucked
- running so many bots is a risk anyway since the ip is definitely a factor in the server side filter software

but this is just my opinion :

Absolutely. It's a pain in the ass. I've been working on my bot for _years_, and it's still not up to par with most injection/passive bots. But I'm not doing it for that. It's fun! Nobody else is doing it (or nobody else was doing it when I started, rather)

Even if it isn't up to par with other bots, it's been useful in other cases. Like a light-weight chat client. Can you turn off wow's rendering, and still keep the ability to use chat, while using only about 20mb of ram and 0% cpu? Or sit in front of a nice gui that gives a full breakdown of the current auction data, with the ability to buy, sell, etc..

IP's are not an issue for me. If I ever went full scale with this, it would be on a server infrastructure with it's own network at LEAST a /24 range. But it's never been like that. It's just a fun project to burn some time on now and then.

I would never recommend clientless as a viable route for someone else to take to make their bot from scratch. you literally have to implement everything yourself, and it's just not worth it in many cases.