Hostbots replace a normal client, so they dont work on top of a normal game instance but just use the battlenet protocols to communicate with battlenet as if they were normal wc3 clients
This is not entirely true.
Host robots replace the standard host that clients use if they create a game. This is a layer present even in singe player (yes you can crash it causing you to "you have been disconnected" when testing a WE map offline) that is responsible for synchronizing clients and managing commands.
You can run a host robot and join it with a client on the same system. This is done by simply publishing the game on local LAN as well and joining via that. When you join no battlenet data is transmitted, which is how you can spoof your name since your client is responsible for declaring what name it is when joining.
This is also why the idea of a "host player" is all fantasy since clients do not host. With standard hosting there is a forced relationship of 1 client always managing the host server as well but as robots show this need not be the case so all clients are actually identical to each other.
BattleNet is mostly used as an advertisement server for host lobbies. It keeps track of game names, map details and the host IP address so that the details can be forwarded to the client without creating a direct connection to the host. Basically it is a coordination server.
The exception is with melee games where BattleNet itself acts as the host server to prevent cheating. This is why melee players never ran into issues joining games through NATs.
In StarCraft II all games (arcade, custom and melee) are run with hosts managed by BattleNet. This has considerable advantages such as automatic replay and match logs, no NAT hosting issues, good QoS but also some problems such as limited bank synchronization rates and potential traffic problems with too many synchronized commands. Only campaign and map testing/offline play is done via a private host server in SC2.
Clearly this isn't how hosting bots work though--they somehow (magically?) have access to WC3's actual states and even the game state (they know if you left by defeat or just rage quit).
The host server keeps tracks of all in game commands and event messages and is responsible for making synchronization decisions. It does not have any idea of the deterministic state, it only knows what clients send it about the state. Since a replay file is nothing more than a dump of all this detail that runs through the host it can generate replay files. Also since none of the deterministic state is involved host servers are considerably more light weight than the game client so even an old computer should be able to manage several as long as network resources are sufficient (most of the limits with host robots are network resources).
The easiest way to force a client to send a chat command is to perform a man in the middle style hacking trick. The idea is that you have a packet insertion point (via proxy or anything that works) that allows you to insert custom packets that contain commands for your chat message (looks like a valid WC3 packet) along with the usual WC3 traffic. Since WC3 uses TCP a proxy would be easiest where the return pipe is directly connected but transmit pipe scans for command frames and then can queue chat command frames into the stream. From WC3 client point of view it will send and receive data as normal but the host server will receive additional command frames with chat messages and things that will then be synchronized between all clients.
It should be noted that this goes against the terms of use of WC3 as you are now manipulating its generated traffic. As such it is possible it will get your CD KEY banned from online use. Chances of this happening for custom games is probably quite slim (they are dominated by robots now) but it will certainly be a huge risk I recommend against for melee use.
