Quote:
|
If you have Firefox browser and IE you can get a WML extension for firefox and login to wap at Yahoo! mobile which uses YMSGHTTP and open a Chat2 session in IE and you're making yourself very resistant to booters.
|
I've used this before for experimentation purposes (nothing more). While it's capable of sending and receiving IMs, Add buddy requests and friends status messages it isn't a substitute for YMSG/HTTP because WAP (WML/HTTP) is HTTP without the use of YMSG as far as both the authentication negotiation and the session data goes. With YMSG/HTTP (firewall with no proxies) it not only supports everything that YMSG does *the packet types which increase per version* but both the authentication and the whole session's packets are all YMSG packets just carried over HTTP (specifically designed by Yahoo! for getting around firewalls). It attempts to "fool" corporate firewalls, ones that might be used at a college campus or in a business environment, into thinking that all the traffic is standard "web" traffic. Some of the smarter firewalls with a technology called 'protocol anomaly detection' would instantly recognize that the traffic as not conforming to typical web traffic patterns (and data encapsulation) and it wouldn't be allowed to leave the network.
I haven't used this "CGuard" program and I don't plan to so I can't comment on whether or not it actually does do what has been suggested in terms of malintent.
When I talk about YMSG/HTTP I
only mean the firewall with no proxies option in Messenger since it's used there. I'm not a big fan of HTTP in general especially when used for IM
but when coupled with Chat 2 they coexist nicely in the Yahoo! IM environment. If you were to PM flood a user that's logged into both of these protocols (with the same ID) the PMs would go through the YMSG/HTTP session as would the chat invites which was discussed before. There's a way to reverse that traffic flow and have it all go down the Chat 2 connection and you could receive all of your PMs and chat invites instead of through YMSG/HTTP *default*. If this Soda guy can't figure it out I'll post the answer for anyone that would like to know how to do it and you can instantly see how going from "unbootable" to "bootable" can be changed so easily by simply knowing where to direct the packet types that are sent to you during your "dual" session.
I can say, however, that I don't find this anti-boot solution to be a very efficient one. You shouldn't have to have two simultaneous sessions taking place just to avoid being flooded eventually (or instantly depending on your connection & the boot method) leading to disconnection.