How Yahoo booters *REALLY* work.

[tim2679]

He means you set the Connection settings for Yahoo Messenger to Firewall with no Proxies.

[Torseq Tech.]

What Tim said, ned, is correct. It's called YMSG/HTTP because it's actually YMSG protocol over HTTP protocol (YMSG packets encapsulated inside of HTTP). I probably should have specified by naming the actual option in Messenger to use. In this case if you open Messenger and then go to preferences, then Connection and choose the radio/option button called "Firewall with no proxies" apply then ok you'll sign into the network with YMSG/HTTP. It's also important to mention that you should go to Messenger's preferences and then to the "Ignore List" section and apply the "Ignore anyone who is not on my Messenger List" so if you are being PM bombed or other the packets will be ignored locally. The only thing that can bother you in this case would be add buddy requests but those won't be all over your screen if you're attacked but instead isolated (overlapping one another) since the "Ignore anyone who is not on my Messenger List" option doesn't stop you from seeing those.

After you do this do not enter chat just leave it in "pager mode" signed into Messenger. After this is done the same ID you used to sign into YMSG/HTTP with use that ID to sign into Chat 2 protocol on either the browser DHTML chat (which uses Chat 2) or a separate 3rd party client. You could leave the YMSG/HTTP messenger session minimized but still active and just focus on your Chat 2 session inside the 3rd party client or DHTML browser page (whichever means you go about when using Chat 2).

This works because YMSG protocol (including YMSG/HTTP) has priority/precedence over Chat 2 protocol and it overrides all of the packet types that you can receive such as chat invites and PMs. There's a way to toggle this back and forth from the YMSG connection not getting priority and the chat 2 connection receiving the PMs and chat invites but then this will make your chat 2 connection "bootable" by means of flooding (back to square one). What could be done is to toggle it on when you're not under attack *so you can receive your PMs and chat invites on the Chat 2 connection normally* and when you are under attack shift the priority back to YMSG/HTTP receiving that traffic so your Chat 2 (room) connection is unaffected. Let me know if you're wanting to know how to change that up and I can share that information.

[ned kelly]

Thankyou, now i understand

[Soda]

Originally Posted by Torseq Tech.

For the server-side "boots" craig is describing what's called an amplification attack. It works by amplifying the traffic load while only having to send a small amount of traffic to make it happen. It's also called the snowball effect. These server-side d/c packets are basically a Yahoo!-specific SMURF attack using Yahoo!'s own protocol to abuse their server's traffic routing rules. I know of a couple ways to stop them from working but there's only a couple tricks you can use to stop one of these attacks if it uses chat invitations or PMs *deliverable in all scenarios regardless of whether you're using Chat 2 or YMSG, cloaked on YMSG or not*. If the packets can be delivered to you it's a potential avenue for flooding to boot you.

Cloaking in YMSG aids in preventing most of these attacks but can't cover all of them. To combat against strong PM bombing even if the PM bomb is using an amplified packet structure to force lots of traffic on you (booters call these "looped" packets) something can be done about it. What you can do is log your ID into YMSG/HTTP and then use a chat client to log that same ID into Chat 2 to join a room. You'll be able to chat regularly on the Chat 2 connection, use voice etc. while all of the chat invites that you receive as well as all of the PMs you'll receive will all be sent to your YMSG/HTTP connection. It's impossible to flood off a user that's signed into YMSG/HTTP even if they're on dial-up due to the nature of how HTTP operates and how the servers deal with the excess traffic that's buffered or built up. The excess is simply discarded while using this protocol. There are other "tricks" you can use but this is the cleanest and would truly make anyone regardless of their connection "unbootable" as far as the flooding goes unless that flood is generated inside the chat room (on the Chat 2 connection). Cookie exploits and other disconnect exploitation methods that don't involve flooding you would still be susceptible to.

Your 100% right on this subject how you finding out i have no clue i been using this method going on 5 months now i made a program called CGuard that does all that for you.And only reason this does work cuz 99% of the time YMSG HTTP doesn't get the packets it just floating on yahoo so call lose air.but yes and as you taken cerdit for the YMSG D.C why would a newblet like you go around and take cerdit for someone else ****? just a subjection not go around and take or release other idea such as this post ty not to mean any harm just think it lame

Here the download for it so stop taken cerdit newblet (download at bottom of this post)

Originally Posted by cjdelphi

After getting fed up with booters knocking me offline, i finally got the packet sniffers out, flexed my programming skills and decided to go in search of the truth..

Misconceptions

A chat client is more bootable than another one... (yes only if the client is very very badly written)

You need some kind of secret packet to send to boot a person in yahoo.. false.

Truths.

A Chat client with a good connection will help prevent most booters, yes, this is correct (with the exception of a couple of yahoo server explots..)


If you know nothing about booters and a little about yahoo, have a look at the article i wrote here

Ymlite


if not i'll try and explain that (which is 300 odd lines) into something a bit more technical now...


Yahoo Messenger
Yahoo Chat...

Yahoo messenger can get into yahoo chat, but in reality, it's a seperate service...

Yahoo Messenger's server has a Buffer, this buffer is actually 128k not the 512 the first tests indicated in the article above.

Why does a booter work?

When the attacker sends multiple packets to you, what you don't get from the server gets stored in a buffer, in comes a chat packet, the client grabs it, in comes 5 chat packets, you grab the first 3 packets, 2 are left behind on yahoo's server, you then grab the 2 packets and then the buffer is back to empty.

Right, this time the booter sends 1k's worth in 1 packet of PM (instant messaging packets) but instead of sending the 1 packet, the booter builds up 10 pm/im packets

(800bytes) + 800 + 800
impacket+impacket+impact

Then you send it to yahoo 10 loops packets of PMs @ 1k each = 80k in 1 load to yahoo then the booter sends it again, 160k.

Now if you can send 128k's worth of data, pm packets, chat packets, anything you like to the other user BEFORE the user can get the data out, yahoo will simply d/c them over 128k why?

Most Probably because the server is instructed to d/c idle users or users
who are no longer online, what's the point of Keeping someone in yahoo chat if they are not getting the data people are sending them, after 40 minutes of a client sending data yahoo goes, we've buffered 128k, the user aint there, kick him...

another theory is that, yahoo messenger would crash if it got anything more than 128k lol

So why do some clients take longer than others to boot them...

The faster the routines, better the coding of the chat client, those few seconds really build up.

Take YahEh a VB written client, to display "Hey there " in YahEh might take 80ms to perform...

the one in Say Y!mlite, typically can do it much faster say around 20 - 30ms

So Y!mLite can process the data, display the packet, get the next packet, it's going to get the packet 50ms faster, ok not much for 1 packet but let's say 100 packets = 5000ms = 5 seconds slower over a period of 100 packets...

This means the client gets less packets from yahoo, and in turn the booter sends more data than you can get (128k) and you get disconnected from the server.

Right so Yaheh might bet booted in 30 seconds, y!mlite because it can get that extra data from yahoo fast enough, it could last say 40 before it got booted...

but, most clients have CPU's good enough now so the chat client makes very little difference, most of the ability of being boot proof is put on to the bandwith...

56k User can download in theory at 8ks
but in reality it's about 4 - 5k

So here's a 1mbit connection, 1mbit / 8 = 128k a second upload.
Here's a 56k connection 5k/s download

by the time the booter puts up 128k of data, the 56k user was only able to get 6k, which leaves 122k of data buffered at yahoo...

in less than 2 seconds, the 1mbit connection booter would have taken out a 56k user.

2 56k users trying to boot each other.

1 56k user manages to upload at 6k/s
2 56k user manages to download at 5k/s

The booter will work.

Booter is sending 6k/s 1k more than what the other 56k user can download... in 128 seconds, the booter would be able to fill up the buffer..

2 minutes it would take to boot them....


if you're on a 2mbit connection and someone tries to boot you on a 3mbit connection, you'll be able to send out at 256k/ but the 3mbit user will be able to download 384k and you'll never be able to fill the buffer fast enough to boot them...

But there's one exception to the rule

A yahoo server exploit, send 128 packets at 1k/s and providing the messenger client does not get the data from the buffer, it will be booted in exactly 128 seconds, now this server exploit

Certain Packets (not specifying what for obvious reasons)

Allow you to send the ID of the person you wish to send the packet to, eg, will you come to my conference, in the packet you can put down 10 id's and yahoo will send out 1 packet to each of them 10 users, 1 packet from me, 10 packets out of yahoo....

Well these booters simply put in 1 person to invite, 10 times, and the packet gets magnified 10 times, so if you're on a 56k, you essentially have the bandwith of 56k * 10 = 560kbit connection, loop the data as i pointed out up there, and guess what happens, you get the equiv of a 1/2mb booter from a slow connection, yahoo sends so much data to the victim so quickly it fills up the buffer (128k) and you get booted from yahoo messenger...

What can be done?

Since i'm the one who writes y!mlite, i've done a few tricks to make it faster, for example if you're under attack, you want to get the data out fast, so as a result, y!mlite only processes the header of each packet, and if it's an IM packet / invite, whatever, it simply ignores it and gets the next packet, it will only process Chat Data since it's highly unlikely someone would try to boot you from chat.

As a result, when a client like yahelite spends 40 - 50ms processing the content of ?WERWE?R>$?@#$ it could waste valuable time, in effect y!mlite becomes unlaggable no matter how many bots are booting you..

(P.S if you have the bandwith, you could boot a person with 1 ID just sending them lots of pm messages faster than they can get out to fill 128k)

So in this type of boot, y!mlite might survive the d/c simply because it's faster at getting the data while yahelite processed it and got lagged and as a result it gets booted.

Y!mLite has Booter Detection, it talks to tell you it's happening, it measures the data throughput and calculates if it's an attack, Y!mLite's also in the proccess of getting an anti booter type routine in, the secret is to use 2 id's... but it's a new experimenental thing and it will quite effectively stop booters...

Y!mlite

p.s i've become quite an expert in this field, any questions feel free to ask, but if you're an absolute noob i suggest reading the article above, it explains everything in detail and precisly what point you get booted...

lmao dude you have no clue has a booter really works do you? OKay here i'll explain in wannabe tearms okay you take your bandwith and take someone else bandwith if they have a higher bandwith then the user there trying to send.it's using yahoo protocol to boot that person witch this means BUFFER OVER FLOW okay good you with me now? good now to stop this there isn't a way to stop this, but one call your isp and have them to upgrade your cheapass ty Soda has said enough now

[tim2679]

Soda, where exactly in Torseq Tech post does he take credit for someone else's work ?
If you would actually read what he posted you will see he only gave information
on how to try and prevent from being booted. No where does he state he came
up with the methods that he posted. I am not being mean just hate seeing someone
being blamed for something to did not do.

[Soda]

Originally Posted by tim2679

Soda, where exactly in Torseq Tech post does he take credit for someone else's work ?
If you would actually read what he posted you will see he only gave information
on how to try and prevent from being booted. No where does he state he came
up with the methods that he posted. I am not being mean just hate seeing someone
being blamed for something to did not do.

Noteing that he telling the same **** i said on a fourm here a few day befor he post he just point the topic a little differnt in what i said,But this orignally was my idea been doing it for months and then he all of sutten posted this on this fourm.But yes you right i was kinda in a bad mood lastnite

[Torseq Tech.]

A bit confused here, Soda. You're one angry soft drink (must be too much carbonation?). What exactly have I used of "yours" again? You do realize that YMSG/HTTP has been known to be "unbootable" for years now, right? It doesn't take any knowledge of Yahoo! to know this either. Look at how HTTP works, how data is POSTed and GET requests are made and you'll see very quickly that HTTP connections are not single entity dedicated connections. Avoiding the flooding effects by using such a protocol that encapsulates your YMSG chat data would make sense to avoid being booted, wouldn't it? I figured this out on my own and I could elaborate on how it works and even alternate methods to prove that I didn't "steal" this idea from you or anybody else. I'm sure many others have at least had the thought of logging into YMSG/HTTP and then using Chat 2 at the same time (they were doing this with YCHT and YMSG - dual logins for YEARS). It's more or less common sense, Soda.

I have never heard of this "Cguard" application but if it uses exactly what I'm talking about here then this should prove to you that you're not the only one with such "knowledge" of this concept. I've also never heard of you nor have I ever spoken to you or downloaded any of your applications, I write my own. But, since you are claiming you are the original sole "founder" of such a marvelous discovery, elaborating on what I mentioned previously should be no problem for you:

This works because YMSG protocol (including YMSG/HTTP) has priority/precedence over Chat 2 protocol and it overrides all of the packet types that you can receive such as chat invites and PMs. There's a way to toggle this back and forth from the YMSG connection not getting priority and the chat 2 connection receiving the PMs and chat invites but then this will make your chat 2 connection "bootable" by means of flooding (back to square one). What could be done is to toggle it on when you're not under attack *so you can receive your PMs and chat invites on the Chat 2 connection normally* and when you are under attack shift the priority back to YMSG/HTTP receiving that traffic so your Chat 2 (room) connection is unaffected.

Shifting the traffic flow of PMs and chat invites, how would that be accomplished with "your" method or doesn't this Cguard have that ability 'yet'?

Soda wrote:

OKay here i'll explain in wannabe tearms okay you take your bandwith and take someone else bandwith if they have a higher bandwith then the user there trying to send.it's using yahoo protocol to boot that person witch this means BUFFER OVER FLOW okay good you with me now?

For one overflow is a single word and secondly you're using "buffer overflow/overrun" in the wrong context. Maybe before I post from here on out I'll check with you on whether or not I'm allowed to mention certain material as you may have *by chance* already privately discovered it, okay? I know the one thing I wouldn't check with you on is spelling.

[Dermot]

Hiya Torseq Tech,

You and i both know this has been out a long time and used by a few people for a long time, and i posted on another chat thread to "soda" about people using the YMSGHTTP and Chat2 already, he just responded calling me names...

I was reading about his "cguard" just the other day and about it "stealing id's" and the person had a picture of it doing so but i can't find it at the moment.

The mere fact that "soda" makes booters and applications to harm Yahoo!'s network and peoples chatting experience i will "never" use any of his applications.

The use of the YMSGHTTP and Chat is not a secret anymore and can be done very easily a couple of ways without the need for "cguard".

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.

You can also Sign into messenger under the Connection settings "Firewall with no proxies" and turn all pm's off to anybody not on your buddylist and open a chat session in IE or a Chat client you use to the same effect..

You can log into the Yahoo! web messenger in one tab in IE and open a chat session in Chat2 in another tab to also get the same required effect.

Of course all these require you to login to each with the Same id.

[Torseq Tech.]

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.

[Mr-DoS]

ok i would like to note one thing on behalf of Soda... His CGuard does not steal id's that image has a space after his name that proves it wouldnt send that pm .. also i have seen the source to this and it pm's a user with the username to show that they are using CGuard as a form of protection ..since he didnt impalement his good security