You can send instructions to manipulate the client and have it do what you want almost as easily as you could if you knew their protocol. And that's without all the cat and mouse headaches.
You can send instructions to manipulate the client and have it do what you want almost as easily as you could if you knew their protocol. And that's without all the cat and mouse headaches.
The only time I've every bothered to write my own chat protocol client was for IRC in the late 90s (at which point I'd left college, was working full time so had turned my programming skills to good) and the only reason I bothered to write my own IRC client was because I was utterly fed up with the quality of Windows clients.
Back in the old days, Win32 APIs were so insecure that you could have all sorts of fun with them. I'm not sure how things stand these days though; my development these days are almost exclusively Linux and UNIX based.
I'm sure it's more complicated than that however, like client side rate limiting or something.
I bet they would put the rate limit in the client, since they did that with the banned word list, but rate limiting would make more sense at the server. Maybe they did both.
Now you could fire up a new VM for each client or use a botnet to do your bidding. Oh, how the Internet has advanced.
In the same way applications use the win API to create their UI, others could use it to manipulate and control the interface of other programs. It's powerful.
Event spoofing is pretty limited. While having a thread under your control gives you full power as you have full access to the process' memory and can call any function you want.
I have actually done a lot of this, putting old sourceless win32 and win16 programs run in the background on virtual machines on the server and building new web-based interfaces on top of them.