Forum Replies Created
-
AuthorPosts
-
Torseq Tech.Member
Mark> There’s no way to prevent them from mass ignoring you. Any program that’s out there that claims it can defeat them is fake and more than likely a trojan.
Torseq Tech.Membereztalker> It used to be called filter1.txt when the contents of the file weren’t encoded. Now the file is called filter1.enc, as you’ve noticed; the .enc filename extension indicating that it’s been encoded.
Years ago editing your filter1.txt with “boot code strings” could help to stop some of the chat room-specific crash codes (html, js). It never did anything to stop actual booters from booting you by any other means (PM bombing, cam invites, conf invites, add buddies etc) since all the filter1.txt/filter1.enc files govern is preventing text strings from being displayed in your chat room window.
If you really want to edit the filter1.enc file you’ll need to figure out how it’s been encoded first so you’re able to add your own strings to it. It’d be pretty pointless since this won’t prevent you from being booted nowadays even if you were to figure out how to edit it.
Torseq Tech.MemberYesterday, I created a thread on this board called “Scanning other user’s buddy lists for your Yahoo! IDs”. This technique could be used to check this person’s list to see if you were deleted from it or not. It’s up to any Yahoo! 3rd party software developers on here to make use of it if they choose to as I won’t be releasing any code to do this. If this was more complicated I probably would have but it’s not.
Torseq Tech.Memberwondered if anyone has ever seen it create a false positive for the webcam being online?
I’ve used this program before in the past and yes, I have, but only under one condition. The default (I believe?) cam server used to scan with is wc1.msg.vip.re2.yahoo.com in buddy spy. The other cam server selections that are available in the program I’ve had false positives with, mainly with reporting users as “offline” when their cams are infact online.
I’ve never looked at this program’s source code (I’m not really a big VB fan but am well-versed in the language) but since I’ve written programs that do cam status scanning and other similar things I’ve noticed in the past that depending on which cam server you connect to, you’ll get different responses back from some of them, the response for being online isn’t the exact same from server to server. This would explain why you might be seeing some false positives, but it would really only explain it if you’re using a cam server other than wc1.msg.vip.re2.yahoo.com, such as wc1.msg.vip.dcn.yahoo.com or possibly one of the others available in the program.
Torseq Tech.MemberIt has been impossible for me to enter chat room of recent.Each time I try to do so I get the message,”you have been signed out because you signed in another computer or device” and I get signed out.Sometimes also I get the message,””Signing into Chat took longer than expected.Please try again”.
I have the same problem with several of my accounts. What I did was instead of contacting Yahoo! to correct such an oddity (I wasn’t doing anything malicious to cause this to happen) I ‘transplanted’ the names I was trying to login to chat with to another account. By transplanted I’m saying that since the names I needed to get into chat with were infact aliases/sub-id’s I was able to delete them from the main account (the chat banned) and recreate them on another that wasn’t. This allowed me to use them to chat with immediately so this tells me that chat bans can be stepped around when pertaining to aliases. I don’t know of a way to do this so easily with the actual main account id.
Torseq Tech.MemberSet the alias to inactive AFTER you’re already in chat OR open the chat room list window first then set the alias to inactive — this way you’ll be able to access the id/alias from the listbox to enter chat with. You won’t have access to the id anymore to join rooms with after you’ve done this so if you need to join another room on the alias while still remaining inactive you’ll need to use the /join command from there on out to navigate the chat rooms.
I assume you’re doing this to protect against being booted? What you’re wanting to do/describing is what I refer to as ‘manual cloaking’ since you’re manually accomplishing the auto-cloak feature in Y!Tunnel — auto is much nicer since it saves you the trouble everytime, as you might’ve guessed.
Torseq Tech.MemberThis is a common issue that has plagued Yahoo! Chat for a while now. What’s happening is that when you go to remove a friend from your list OR, like you said you’ve done, add/remove them from your permanent ignore list you’re telling the chat server to process your request(s) BUT they don’t always do this and as a result when you “refresh” your buddy list or sign out and in again you’re sent the same configuration you had before. This is a chat server issue that I’ve noticed many times myself. The solution I’ve found is changing the YMSG server that Messenger connects to each time and trying the same operations again (removing friends and ignores). You could also try logging into the YMSG/HTTP option in Messenger “firewall with no proxies” and removing the buddies/ignores etc that way.
To switch up the chat server that Messenger is connecting to each time when you log in *Messenger sometimes likes to use the same one depending on it’s randomization from the DNS lookup results it gets* you could go into the registry using the ‘regedit’ tool that comes with Windows, go to ‘HKEY_CURRENT_USERSoftwareyahoopager’ and create a string value called ‘ConnServer’ with the hostname of the MSG server you’re wanting Messenger to connect to each time you log in. If you’re using Messenger 6 it will already have this created so all you would need to do is change the string value from scs.msg.yahoo.com to the one you’re wanting to use. The servers you could input as the string value are: cs1.msg.dcn.yahoo.com – cs60.msg.dcn.yahoo.com.
More than likely it’d be much easier on you to just go ahead with the YMSG/HTTP firewall with no proxies login since it’s nature is to connect to it’s own proprietary servers different than the typical YMSG servers. Try your luck with some of these ideas.. you’re bound to eventually find a server that’ll handle your buddy removals/ignores properly.
Torseq Tech.Membercan i see who has added my yahoo name to their buddy list???
There is a way that I discovered months ago to do this. It’s not something that everybody would be able to do (without creating a program for this which I won’t be doing) since it involves monitoring packet responses and sending a specially crafted YMSG packet to Yahoo! This tactic reveals the main id of the user(s) that have you added to their friends lists. If the person in question added you originally from an alias on their main account when you view the response it might not make sense to you since you’d only be seeing their main id and you may have no clue which person that might be tied to. You could very well know the person and have previously allowed them to add you to their list and mistakenly think that this main id is instantly somebody that added you without your knowledge when that might not be the case.
What you could still do, however, is deny-a-buddy this id and that person would lose you from their friends list (you wouldn’t need to know the id that they added you on, you’ve got their main id).
I can explain this a bit more. All I need to do is send a single specially crafted YMSG packet to Yahoo! In turn they take this packet and broadcast it to every user that has you on their friends list. When those people receive the packet they’re required to act on a dialog box that prompts them for a response. As long as it’s responded to they’ll unknowingly be informing you that they’ve got you added as a buddy. The requirements for you to collect the people who have you added are: 1.) They have to be on YMSG protocol at the time you send out the ‘probe’ packet 2.) They have to respond to the dialog prompting them to make a decision (an auto-reject or accept from their client/Y!Tunnel will work too). Since Yahoo! sends your single packet to everyone that’s added you as a buddy all that’s necessary for the sender to do is to wait and monitor the replies. I’m sure there’s probably other ways to do this, probably even ways that are passive that don’t even require user interaction (or client). I might look into other ways to do this when I get the time.
Torseq Tech.MemberPeople have figured out how to use raw voice chat sockets. That’s how they dodge being ignored on voice.
Raw voice is just a term that’s used to mean that the yacscom voice library isn’t needed to participate in voice chat in simplest terms. The reason raw voice exists is to allow for more control over voice packets than what is given with yacscom.dll, such as the ability to modify voice packet headers and payloads as they’re received or sent out. This doesn’t mean that it’s something malicious just that the concept can be used for things of that nature when you’re connected to the voice chat server.
Voice ignoring is a one way communication channel {unicast not broadcast} between you/the voice user and the rtp control voice server [remote TCP port 5001]. When you ignore a voice user you send a vc ignore packet with your sequence source id [SSRC id #] along with the person’s that you’re ignoring from voice. What happens is the control server receives the ignore and instantly stops sending you voice audio data from that person. They have no control over whether they’re ignored or not by you or by other voice users.
If there is a way to fool the server into not acknowledging other user’s ignores then I don’t know about it. Each time they join voice *by logging into the voice server with their cookie* they’re sent their own SSRC id and that id is known to anyone connected to voice in the room at that time. It’s main purpose is to identify the source of the audio broadcasts to the room. More than likely the voice server you were connected to in a room was acting strange and not acknowledging voice ignores. This would explain why you thought that there might be something out there since you couldn’t ignore this guy. Over the years some of Yahoo!’s voice servers have been known to act this way, it’s actually pretty common.
Torseq Tech.MemberScruffy, you’re getting logged off because at the moment the Firewall with no proxies functionality is pretty messed up stemming from Yahoo!’s recent move from YMSG12 -> YMSG13. It’s been this way for many months now and anybody using Messenger 7.0 that attempts to join a chat room will be disconnected, yes. If you were to try this using Messenger 6.0, last time I tried it, this didn’t occur (6.0 uses YMSG12). There’s also yet another problem with this – whether using it in Messenger 6.0 or 7.0 room text getting dropped in the room is occurring due to something strange that Yahoo! is adding to the chat room messages before they’re sent to you. All of these problems currently make it worthless when it comes to chat rooms but useful if you never go into chat rooms. PMs still work and everything else the problem at this time is just the whole chat room deal.
When I recommended this option, maybe I should’ve made this line a bit more clear:
Last I checked the YMSG/HTTP login — the “firewall with no proxies” option in Messenger’s preferences was immune to most/all of these known detection techniques. Since many Messenger users don’t use this alternative option (not to mention it’s currently pretty messed up at the moment thanks to the YMSG13 transition) they just use the default YMSG login from Messenger and are vulnerable to programs like Buddy Spy’s detection.
Notice what I said previously inside the parenthesis.
Torseq Tech.MemberAfter closing out Yahoo Messenger, I cannot usually log back in. Then when I go to shut my computer down, there is a message that comes up saying…waiting for YPager.exe to end. How do I fix this. I have uninstalled and reinstalled several times. Not fixing the problem.
When you’re done using Yahoo! Messenger make sure that it’s actually closing correctly *which it doesn’t appear to be doing*. You can check by performing a Ctrl+Alt+Del key combination and looking for YPager.exe. If you see it in the list it’s still running. To close it select YPager.exe in the process list and choose ‘End Process’ (assuing you’re using WinXP). After doing this you shouldn’t have any problems using it again after you’ve used it and shut it down.. and you shouldn’t have that problem if you do this before shutting down your computer.
Torseq Tech.MemberAlso, since I forgot to mention it, if you do infact decide to experiment with deleting your Alias to avoid that detection method I think it’s note-worthy to mention that when you do this ANYONE can then claim stake and create your Alias as one of their aliases or a main ID altogether. Every time you do that you risk losing your alias permanently to somebody else that may desire the alias. Although the time window may be small between deleting the alias and recreating it it’s still entirely possible to get robbed of it if somebody knows what you’re doing and decides to create the ID for themselves.
Torseq Tech.MemberHiding from online detection isn’t always easy as other alternative methods for ‘fingerprinting’ user’s online status are always out there, just takes some time and some playing around to find what works. If you’re able to come up with a packet that accurately and consistently has the Yahoo! server return a static/semi-static response when a user is ‘online’ that is different from the ‘offline’ response then you’ve got a ‘new’ way of detection. I’ve found a couple myself including a way to identify all Chat 2 users specifically as well as identifying online status of YCHT users. Last I checked the YMSG/HTTP login — the “firewall with no proxies” option in Messenger’s preferences was immune to most/all of these known detection techniques. Since many Messenger users don’t use this alternative option (not to mention it’s currently pretty messed up at the moment thanks to the YMSG13 transition) they just use the default YMSG login from Messenger and are vulnerable to programs like Buddy Spy’s detection.
Will ‘cloaking’ your alias defeat the P2P packet online status detection? No.
A way to beat some of the online detection that I looked into a while back, assuming that the ID to be ‘detected’ is an account alias/sub-account, is to log into a chat room and then delete your alias from the main account. When you do this you’re still able to chat, change rooms, have voice, view webcams, accept chat invitations and PMs etc UNTIL you close the main chat room window — which then you won’t be able to get back into chat with the alias (probably a way around this just haven’t looked yet) until after you’ve created the alias on the main account again. Deleting the alias from your main account and creating it again after your chat session takes maybe a minute at most. You could always automate this too through a program to do it for you. I still don’t consider this a feasible option to get around the detection but you technically could use it, I know it beats the P2P packet method for detection and I’m fairly sure all the others (not sure about the avatar though). The default and most accurate method of detection is the P2P packet method imo so defeating it would be the most important if it’s even worth the trouble at all.
Even if you were to go as far as deleting your alias I still know of a way that’ll tell you if a user is online, even regardless of the chat protocol they’re using. There may be a way to tell the servers that you’re offline when you’re really not, could be a login tweak or it could be a manipulation of another YMSG packet. Finding something like this to defeat the detection would be much more desirable than having to delete your alias and then having to recreate it again.
Torseq Tech.MemberYahoo is constantly patching, but people are constantly looking for new exploits.
Definitely.
Adding a hook firewall (Ytunnel) doesn’t automatically protect you.
Correct, it’s got to be written well and know beforehand what to look for (same with AV, IDS, IPS etc. even AV’s advanced real-time heuristics have to know what to look for ahead of time). I never said otherwise.
That last exploit you are referring to was patched just before Christmas, 2004. Ytunnel did not protect against it.
Yes, I remember this exploit pretty well (which was why I brought it up), however, Y!Tunnel did infact protect against it. It did and it didn’t to certain “variants”. Let me explain — since when I was originally hit with this within 2 minutes I had ‘self-patched’ it within Y!TunnelPro. YTP’s got a wildcarding option for auto-ignore. This wildcarding will auto-ignore voice IDs also. By wildcarding *<iframe or even *< generically YTP would auto-ignore the voice names when they joined the conference and as a result you would not get 'hit' by this exploit. Now the way to get by this was to use characters before the start of the tag so the wildcarding could be avoided entirely.. ieg: 'mikexyz<iframe' would have evaded the auto-ignoring wildcard rule. So, with this in mind it's not entirely accurate to say that YTP didn't defend against it, it did, but it's defense was limited due to the fact that wildcard rules in YTP only have the ability (at present) to check for names that start with a given character sequence. The rest of your post I do agree with.
Torseq Tech.MemberI prefer Msg just like Torseq, but it is also very vulnerable especially the next time a new “IFRAME” exploit comes out.
If you’ve got it locked down properly and are using a good ALG pretty much the only stuff you’ll see is the same old html code IFrame injections along with the standard packet flooding. The voice “freezes” are a problem with the voice library (this affects 3d party clients using yacscom too) and not Messenger itself. The last major IFrame injection was exploited through Yahoo!’s port 5001 RTCP voice server due to the cloning that was able to take place. As a result voice users could make up their own voice IDs and log them into voice. Eventually somebody found out that you could include html code/javascript as the voice ID. This has been patched for a while now.
There’s been some others involving the PM-only ‘search’ using the “s:” search handler and even the more recent find of the “msg:” handler. With the msg: handler .gif pictures can be loaded into chat, javascript executed and other annoyances. If you’ve got your PMs closed to friends only and/or safe listed users the search handler vulns won’t exist since they can only be exploited through PM.
Last year that exploit sent Ymsg/Ytunnel user not properly set up to websites of the booters choice. Many of these websites caused a buffer overflow with execution of malicious code and infected unprotected computers.
This first sentence is true but the last isn’t clear. All that was really done (since these guys seem to think that this is more than likely all that they can do) was annoying voice users by loading images into the chat room, popping up msg dialog’s through js, loading music/vid streams and taking them to websites.
Now, by taking them to websites containing streaming videos created to exploit vulnerabilities in products like Windows Media Player (as one example)… that’s when this last sentence could be true but this wouldn’t be a Messenger problem, the same could happen simply by visiting any site through your browser and streaming a WMP video. The “overflow” and execution of arbitrary code could very well effect WMP itself or another entity that’s vulnerable.
I don’t want people thinking I’m saying that Messenger is ideal security-wise because it’s not. I just find it laughable when others condone usage of 3rd party clients (without even mentioning a name!) to magically make users ‘unbootable’ and their chat sessions problem-free. When people say “Just use a 3rd party client, bro” I normally ignore them in chat. The reason why is because these people seem to think that ANY 3rd party client (just because it’s 3rd party) will automatically be “more secure” than Messenger… without even having to mention the client’s name, author or language that it was coded in, standards followed etc. There are no benefits imo to using a 3rd party client as like I said previously the clients are being coded to catch up to Messenger all the time while Messenger is just obtaining newer features and actually building onto what it already has. By enhancing this client with an ALG users can have access to all of it’s features while keeping them safer at the same time (assuming the ALG was coded properly and takes into account patching of Messenger-specific vulnerabilities).
-
AuthorPosts